Summary
When a subagent's tool run requires authorization (e.g. an OAuth flow for a connection), the resulting authorization.required event is never forwarded to the parent session or the user-facing channel. The child session parks with a pending authorization and hangs indefinitely. Approval and other input requests from subagents bubble up correctly; auth requests do not.
Reported by a customer as a blocker for using subagents.
Reproduction
- Give a subagent a tool/connection that triggers
requestAuthorization.
- Have the parent agent invoke the subagent.
- The subagent's tool returns an auth signal; the child emits
authorization.required and parks.
- The event is written only to the child's own stream — nothing reaches the parent or the channel. The user never sees an auth prompt and the run never completes.
In contrast, a tool approval or ask_question from the same subagent is shown to the user as expected.
Cause
Input requests bubble up because SUBAGENT_ADAPTER declares an "input.requested" handler (src/execution/subagent-adapter.ts) that forwards a subagent-input-request hook payload to the parent, where the HITL proxy (src/execution/subagent-hitl-proxy.ts) re-emits it on the parent's stream.
Auth uses a separate event type, authorization.required (src/harness/tool-loop.ts). The subagent adapter has no handler for it, so callAdapterEventHandler (src/channel/adapter.ts) passes it through to the child's stream, which no interactive channel consumes. The HookPayload union (src/channel/types.ts) has no auth variant, so there is currently no way to carry the request to the parent.
Proposed fix
Mirror the existing HITL proxy path:
- Add an
"authorization.required" handler to SUBAGENT_ADAPTER that forwards the challenge to the parent via resumeHook.
- Add a corresponding
HookPayload variant and a branch in the parent's turn-workflow inbox loop.
- Re-emit the auth request on the parent's stream so the channel renders it, and route the completed authorization back down to the parked child (analogous to
routeDeliverToChildren).
Auth requests should propagate through nested subagent chains the same way HITL requests already do.
Summary
When a subagent's tool run requires authorization (e.g. an OAuth flow for a connection), the resulting
authorization.requiredevent is never forwarded to the parent session or the user-facing channel. The child session parks with a pending authorization and hangs indefinitely. Approval and other input requests from subagents bubble up correctly; auth requests do not.Reported by a customer as a blocker for using subagents.
Reproduction
requestAuthorization.authorization.requiredand parks.In contrast, a tool approval or
ask_questionfrom the same subagent is shown to the user as expected.Cause
Input requests bubble up because
SUBAGENT_ADAPTERdeclares an"input.requested"handler (src/execution/subagent-adapter.ts) that forwards asubagent-input-requesthook payload to the parent, where the HITL proxy (src/execution/subagent-hitl-proxy.ts) re-emits it on the parent's stream.Auth uses a separate event type,
authorization.required(src/harness/tool-loop.ts). The subagent adapter has no handler for it, socallAdapterEventHandler(src/channel/adapter.ts) passes it through to the child's stream, which no interactive channel consumes. TheHookPayloadunion (src/channel/types.ts) has no auth variant, so there is currently no way to carry the request to the parent.Proposed fix
Mirror the existing HITL proxy path:
"authorization.required"handler toSUBAGENT_ADAPTERthat forwards the challenge to the parent viaresumeHook.HookPayloadvariant and a branch in the parent's turn-workflow inbox loop.routeDeliverToChildren).Auth requests should propagate through nested subagent chains the same way HITL requests already do.