On September 2, a commit to different-ai/openwork added parent-level visibility for a child session’s blocked permission request. Its task row can now say Needs permission, the approval panel names the requesting child session, and the selected reply returns to the session that owns the pending request.
A delegated agent can otherwise look busy while work has stopped at a permission prompt in another session. That is more than awkward interface design: the person supervising the parent task cannot decide what to do until they know which child is blocked and what it is asking for.
The useful change is not the amber shield by itself. Openwork's interaction path collects permissions from the selected session and its child sessions, then replies with the pending request's own session ID.
Its public opt-in end-to-end test spells out the intended scene: a parent sees a blocked child called “Investigate the deployment failure,” gets Deny, Allow once, and Allow for session controls, and watches that child row return to its running treatment after an Allow once answer. The parent has become a place to find and route the interruption, not merely a progress display.
“Working” is no longer allowed to hide “waiting”
That ordering matters. The task-row logic gives a pending permission precedence over both its normal running shimmer and a degraded-sync treatment. The parent should not reassure an operator that a child is working when the next useful human action is an approval.
The test also checks that the parent names the source of the request rather than making a reader open a separate child session and guess which task caused it.
This is a modest claim with a real operational consequence. It does not make the command safe, decide whether a broad session grant is wise, or prove that Openwork has changed its policy engine. It makes the decision point legible to the person who owns the parent task. For a system built around delegation, that is the difference between an invisible stall and a request an operator can actually assess.
Visibility still needs a durable answer
The first reading of this patch could have been a sweeping claim that agent tools are moving permission upward. The source does not support that. On the same day, Goose changed a different layer: its state machine records tool-confirmation requests and responses, then waits for answers before resuming a halted turn.
Its focused test accepts the same outstanding answer idempotently, rejects a conflicting answer, runs the tool once after resumption, and rejects a later response. That is not evidence that the projects share a design or policy. It is a useful contrast: the parent must be able to see the ask, and the runtime must know exactly what one answer means.
Builders of delegated workflows can turn that contrast into a small audit. Can the parent identify the exact child that is waiting? Does the reply return to that child rather than the visible parent? Can a double click, reconnect, or stale modal change the decision or run the tool twice? These public sources show intended main-branch behavior and tests, not a released feature or safer approval policy. The next signal worth watching is regression coverage for several children, reconnects, and retries after a parent has answered.