Repository navigation
Conversation
…ut Auto
Restore the permission mode the CLI reported on its first init frame instead of the requested mode. Claude Code falls back from Auto on models that lack it (Haiku 4.5), so restoring the requested mode called setPermissionMode("auto") and the CLI rejected it.
Fixes pingdotgg#15650
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
github-actions
Bot
added
vouch:unvouched
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — This focused server bug fix records Claude’s effective initial permission mode so follow-ups do not retry an unsupported Auto mode. The behavior is covered by a regression test, with existing supported-model and plan-mode paths preserved. You can add or adjust custom eligibility rules. Learn more. |
|
Warning Review limit reachedOnly developers with an assigned seat can use this organization's usage-based review budget, and seats here are assigned manually. Ask an admin to assign a seat, or change the review continuation mode in Billing. Next included review available in 39 minutes. View limit details
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to This fixes the failed follow-up to a reused Claude process when the CLI starts in default mode instead of the requested auto mode. No merge-blocking risk remains. The full delegate_task parent-and-child flow was not checked end to end. Security Architecture Review
Pre-merge checks |
  |
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage |  |
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 2 files. | Write docstrings for the functions missing them to satisfy the coverage threshold. |
✅ Passed checks (4 passed)
-
-
Check name Status Explanation Linked Issues check Issue #15650requires a follow-up to work when a Claude process starts indefaultafter T3 requestedauto.ClaudeAdapterV2.tsrecords the first init frame’s permission mode and uses it as the mo…Out of Scope Changes check The source change and regression coverage in ClaudeAdapterV2.tsandClaudeAdapterV2.test.tsdirectly address issue#15650. The added init frames in the plan-mode test preserve coverage of the exis…Title check The title clearly and concisely describes the fix for Claude follow-ups in Auto mode when the model does not support Auto. Description check The description includes the problem, expected behavior, root cause, implementation details, scope and approval, focused verification results, manual validation, and untested areas. It is complete and…
-
✨ Finishing Touches
-
-
🧪 Generate unit tests (beta)
-
-
- Create a new PR
-
-
-
- Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
juliusmarminge
added
the
macroscope-review
ChatGPT Codex Connector
Dismissing prior approval to re-evaluate fcd3ad6
Dismissing prior approval to re-evaluate f929b71
This branch has not been deployed
2 participants
Problem
A Claude thread in Auto on a model that does not support Auto (Haiku 4.5, also Sonnet 4.5, Opus 4.5) fails on every follow-up that reuses the live CLI process with "The provider could not start this turn". This is how delegated Haiku children that inherit Auto break (#15650), and a Haiku thread set to Auto by hand fails the same way.
The CLI does not reject Auto at open. It silently starts in Manual and reports
permissionMode: "default"on its init frame, so the first turn works. Since #15224, a reused process is put back in the mode it was opened with when the reported mode differs, which here sendssetPermissionMode("auto"). The CLI rejects that withCannot set permission mode to auto: auto mode unavailable for this model.Change
The mode a reused process is restored to is now the mode the CLI reported on its first init frame, not the mode T3 requested. Later init and status frames still track Claude's own mode changes (EnterPlanMode), so the #15224 plan-mode restore is unchanged. Models that support Auto report
autoon init, so nothing changes for them.Scope and approval
Fixes #15650, a triaged bug confirmed on
mainby the maintainer triage comment. One underlying problem inClaudeAdapterV2.openQuery. The other directions from the triage comment (hiding Auto per model in the composer anddelegate_task, naming the rejected mode in the error) are separate changes and are not included.Verification
permissionMode: "auto":default, andsetPermissionMode("auto")fails withauto mode unavailable for this model.auto, andsetPermissionMode("auto")succeeds.ClaudeAdapterV2.test.ts: Auto falls back todefaulton init, and the follow-up must reuse the process without callingsetPermissionMode. Before the fix it failed withexpected [ 'auto' ] to deeply equal []. The plan-mode restore test now also sends the init frame, so it still covers restoring to the init mode after EnterPlanMode../node_modules/.bin/vp test run apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.test.ts: 232 passed. Server typecheck, scoped lint, and formatting pass. The conflict resolution keeps SDK message locking and updates the regression test for the new MCP service layer and namespaced runtime policy..t3state), Haiku 4.5 thread in Auto: the turn that opened the process reportedautorequested anddefaulton init. The next follow-up on the same process completed (THIRD WORKS) where it used to fail.Not checked: the full
delegate_taskparent and child flow end to end. It reaches the sameopenQueryreuse path covered above.Done with Claude Opus 5.5 in Claude Code (T3 Code). The implementation was delegated to GPT-6-Astra in Codex, and the Codex review found no issues.
Maintenance: GPT-6-Astra via the Codex harness in T3 Code.