Repository navigation
[Bug]: Follow-up to a finished delegated Claude subagent fails with set_permission_mode control_request_failed when runtime mode is auto #15650
Description
Area
apps/server (orchestration V2, ClaudeAdapterV2)
Steps to reproduce
- Parent thread on Claude (
claude-opus-5-5), runtime mode auto. - From the parent, call the
delegate_taskMCP tool withtarget: { providerInstanceId: "claudeAgent", model: "claude-haiku-4-5" },mode: "wait". Runtime mode is inherited (auto). - The child finishes its first turn successfully and returns a result.
- Open the child thread from the Lineage panel and send it a follow-up message.
Expected behavior
The child thread starts a new turn and answers the follow-up.
Actual behavior
The turn fails immediately (~50 ms) with "Provider error: The provider could not start this turn. Retry the turn; if it keeps failing, check the provider setup and server logs."
After switching the child thread's runtime mode manually from auto to auto-accept-edits in the composer, the same follow-up succeeds. The provider thread id is identical across the failed and the successful run, so the session itself is resumable; only the permission-mode switch fails.
Impact
Any follow-up to a delegated child that inherited auto mode fails until the user changes the mode by hand. The error text does not mention the permission mode, so the cause is not discoverable from the UI.
Version or commit
0.0.46-nightly.20261004.2648 (server and desktop)
Environment
- macOS (Darwin 27.0.0), arm64
- Claude Code CLI 2.1.289
- Child model: claude-haiku-4-5; parent model: claude-opus-5-5
Logs or stack traces
Run 2 of the child thread (server.trace.ndjson, span orchestrationV2.providerTurnStart.start):
{
"_tag": "ProviderAdapterTurnStartError",
"driver": "claudeAgent",
"cause": {
"_tag": "ClaudeAgentSdkQueryRunnerError",
"method": "setPermissionMode",
"cause": {
"telemetryMessage": "Claude Code control request failed (set_permission_mode)",
"errorClass": "control_request_failed"
}
}
}Run history of the child thread (orchestration_v2_projection_runs):
| ordinal | status | runtime mode |
|---|---|---|
| 1 | completed | auto (inherited from parent via delegate_task) |
| 2 | failed after 56 ms | auto |
| 3 | completed | auto-accept-edits (changed manually) |
Possibly related: #5943 — there setPermissionMode failure also hides the underlying cause.
Workaround
Switch the child thread's runtime mode away from auto before sending the follow-up.
Root cause
claude-haiku-4-5 does not support Claude Code's auto permission mode. delegate_task lets the child inherit auto from the parent without checking the target model, so the follow-up turn's set_permission_mode: auto is rejected. The first turn did not fail, so that path does not hit the same check.
Suggested fix
delegate_task(andorchestrator_capabilities) should know which models supportautoand refuse or downgrade the inherited mode for the others.- The turn-start error should name the rejected permission mode instead of the generic "could not start this turn".
Activity
juliusmarminge commentedon Oct 4, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks for this, @Conte777. The run history table and the trace span made it easy to follow, and the
auto-accept-editsworkaround was a useful clue.What I found
I confirmed this on
main. It isn't limited todelegate_task.permissionMode: "auto"on one of those models, the CLI quietly starts in Manual and reports that mode on itssysteminit/status frame. That's why the first delegated turn still completes.ClaudeAdapterV2.openQuerycallssetPermissionModeto switch back before sending, which here meanssetPermissionMode("auto"). Haiku rejects that withcontrol_request_failed, it becomes aProviderAdapterTurnStartError, and the UI shows the generic "could not start this turn" text fromProviderFailure.ts, which drops the permission-mode cause.auto-accept-editsworks because it changes the query policy key, so T3 replaces the process instead of callingsetPermissionMode. The session itself is fine.delegate_taskonly checks that the child's mode isn't broader than the parent's (resolveRuntimeMode). Claude doesn't advertise runtime modes per model, and the composer offers Auto for every Claude model. That means a Haiku thread set to Auto by hand fails the same way on its second prompt while the CLI process is still alive.Workaround, as you found: switch the thread away from Auto before sending a follow-up on Haiku.
Likely fix area
ClaudeAdapterV2.openQuery: options include starting the turn in the mode Claude already fell back to instead of failing whensetPermissionMode("auto")is rejected, or replacing the process as the mode-change path already does.resolveRuntimeModefordelegate_task) for models Claude Code doesn't support it on.ProviderFailure.ts: the turn-start error could name the rejected permission mode.A maintainer will decide on the fix direction.
juliusmarminge commentedon Oct 19, 2026
Note
Grok responding on behalf of Julius.
Fixed by #15687, now merged to main: Claude follow-ups in Auto no longer fail when the model accepted Auto as Manual, because the adapter restores the mode reported by the first init frame. Hiding Auto for models that don't support it is still separate work. Please reopen if a follow-up to a delegated child still fails on a build that includes 598298c.