fix(server): Claude Auto mode asks before commands it escalates#15360

Review in Change Stack →

No actionable comments were generated in the recent review.

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — The production adapter changes Claude's shell-command authorization behavior by pausing Auto-mode escalations for approval and narrowing session-wide Bash/Monitor grants. Because this affects a security-sensitive execution boundary, human review is warranted.

^{You can add or adjust custom eligibility rules. Learn more.}

Thanks for picking this up. The approach looks right to me. runtimeMode !== "full-access" also means any mode added later will ask by default, which is the safe direction. A few notes from reading it against current main and the pinned Agent SDK (^0.3.276):

1. The rebase conflict is small. The source file merges cleanly. In the test file, main has since added applyFlagSettings: () => Effect.void to the stubbed query session, so openClaudePermissionTurn needs that line too. I'm happy to push the rebase if that helps.

2. A hook's reason doesn't reach the user. #15353 is about a PreToolUse hook returning ask. The request prompt is built as title ?? description ?? decisionReason ?? …. The SDK nearly always sets title ("Claude wants to run …"), so the hook's reason in decisionReason gets dropped. The user sees an approval request but not why it was raised. The SDK describes that field as the reason the ask escalated, meant "for the consent line of the host's dialog", and notes it may contain ANSI escapes, so sanitize it before rendering. Could the prompt show it alongside the title?

3. Suggested test for the hook path. The new Auto tests send a plain git push through the callback. That proves the callback asks, but nothing covers the hook case from the issue. A test that passes decisionReason in the callback options and checks it appears in the raised request would cover #15353 directly, and point 2 too if it's addressed.

4. "Accept for session" in Auto (could be a follow-up). After this change, the requests a user sees in Auto are the ones Claude declined to auto-approve. The SDK passes suppressAlwaysAllowRule and defaultToNo for these, but the adapter doesn't read either. Also, when there are no suggestions, toSessionPermissionUpdates falls back to a whole-tool rule ({ toolName }). So accepting one escalated Bash command for the session allows every Bash command after it. That isn't new, but this PR is what starts putting these requests in front of Auto users. If it's out of scope here, it deserves its own issue.

5. Unattended runs (worth a line in the description). An approval only ends when someone answers or the SDK aborts the call. Scheduled, webhook and delegated threads in Auto will now pause at escalations instead of running through them. Supervised mode already works this way, so I think that's correct, but it changes how Auto behaves. If you want a follow-up option: without a canUseTool callback the SDK simply denies asks, so "deny when nobody is attached" would be easy to build.

Thanks, this was useful.

1. Rebased onto current main, with applyFlagSettings added to the stubbed session.
2. Done in beb7427cc2. The prompt now shows decisionReason on its own line under the title, with ANSI escapes stripped. The web approval panel also wraps command prompts now, since it was hiding long reasons off to the right. I checked it on web with a PreToolUse hook returning ask with a reason.
3. Added a test that passes title and an ANSI-coloured decisionReason through the callback in Auto and checks the raised prompt.
4. Agreed it's real and predates this PR, but it's out of scope here. Could you open a separate issue for it?
5. Added a note to the description. Unattended Auto threads now pause at escalations, as Supervised does.

The prompt is still one string, though, so the panel can't tell Claude's label, the command and the reason apart. The command itself is also often missing, because the SDK's title is usually Claude's own label ("Commit the test edit"). Fixing that properly means separate fields on the approval item and changes on web and mobile, which is out of scope here. Feel free to take it on in a follow-up PR.

@coderabbitai resume

Taking over this one. I’ll merge current main into the original branch, reduce the tests to focused approval behavior, rebuild the adapter change, and run independent reviews plus headless verification. I’ll preserve the author’s commits and leave the PR unmerged.

Current-main revalidation for #15353: on defb7e6e6b, the adapter regression fails with the command ran without asking: expected 'decision' to equal 'request'; the Auto-accept edits control passes. Applying only this PR's callback-policy change locally makes both cases pass and all 208 Claude adapter tests pass. Scoped lint has no errors and one pre-existing unused-variable warning. These results validate the minimal policy change on current main, not this PR's older head.

Current main also retains the downgraded override and handles suppressAlwaysAllowRule in claudeApprovalPresentation; a refresh should preserve both. The local proof audit accepts the observable adapter regression; no render paths changed.

Real-provider/client verification remains incomplete: the isolated Linux web app encountered an 84.8-second event-loop stall, repeated disconnects, and a 60-second browser readiness timeout before the command was submitted. No end-to-end approval or runtime capture is claimed. The issue remains open; this PR is labeled bugfix and is not merged.

refreshed this pr in place at 59fa4a20667dd9828a21c041bdd67dd1b4c8143d, preserving @TonybynMp4's commits and merging github/main (cc0b86ddf12a).

• kept the auto escalation callback and the bash/monitor guard against suggestion-free blanket session grants. full access, the managed-policy downgrade, explicit approval-policy overrides, scoped sdk suggestions, and custom-tool fallback stay intact.
• reused main's claudeApprovalPresentation for the sanitized reason and restricted approval options. dropped the original inline reason concatenation because main now has a separate reason field.
• reused the existing adapter command test for auto accept/decline and the auto-accept-edits control, with two focused session-grant cases. compared the original diff against this refresh: no intended behavior was dropped. the diff against main is two files, 52 additions and 13 deletions.

verification: on unchanged current-main production, both auto cases failed with "the command ran without asking" and both shell-grant cases failed; the auto-accept-edits control passed. after the fix, all 240 adapter cases pass. blacksmith vp run check:changed passes format, lint (zero warnings/errors), both knip passes, graphql checks, affected server/scripts typechecks, and the adapter suite. two independent gpt-6.1-sol reviews approved this exact head with no findings.

unverified: the real claude/provider/client approval round trip and matching before/after captures. this vm's claude auth status reports loggedIn: false, so that path cannot run here. vp run dev reached readiness and was stopped. no ui rendering code changed. unattended auto work will wait for a human when claude escalates, as intended.

current-head ci: all 31 reported checks are green, including build/typecheck, lint, all eight server test shards, aggregate Check, and the macroscope checks. github reports mergeable. the two historical shell-grant bot threads are addressed by the retained guard and are resolved. coderabbit's current-head review was skipped because of its review limit; its green status is not a fresh review. no new bot findings were posted. the only verification blocker is the unauthenticated real-provider/client path described above.