[Bug]: Claude Auto mode on orchestrator v2 runs ask-rule commands without prompting #15353

Activity

1. juliusmarminge commented on Oct 3, 2026

   

   juliusmarminge

   on Oct 3, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the precise report, @TonybynMp4! This reproduces on current main. A Claude thread in Auto auto-approves the tool calls Claude has already decided to ask about, including a permissions.ask match. It's the same gap that merged #13786 closed for Auto-accept edits, still open for Auto.

   What happens

   claudeRuntimeQueryPolicyForRuntimePolicy in apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts maps runtimeMode: "auto" to Claude's permissionMode: "auto" with installPermissionCallback: false. The query always gets canUseTool anyway, and requiresClaudeApproval is that same flag. So after the AskUserQuestion and ExitPlanMode special cases, the callback returns allow right away. The test maps Auto runtime mode to Claude's AI-reviewed permission mode pins the flag at false.

   Claude checks content-scoped ask rules before its auto-mode classifier, and it sends a match to canUseTool instead of letting the classifier approve it. Bash(git push:*) is the trailing-wildcard form of Bash(git push *), so your repro rule is a real ask. The query leaves settingSources unset, which means user settings load and a rule in ~/.claude/settings.json applies. The permission modes guide says Auto approves routine actions and asks about others, but today those asks never reach the thread.

   Routine classifier approvals never call canUseTool, so routing asks to the user wouldn't turn Auto into Supervised. A one-off classifier block isn't a prompt either and stays inside Claude. The callback does see the later fallback, when repeated blocks make Claude start prompting again. It also sees anything else Claude routes as an ask, such as org connector tools set to ask or MCP tools marked requiresUserInteraction.

   Likely fix area

   • One option is to treat auto like auto-accept-edits when approvalPolicy is unset, so the callback raises a normal approval request instead of allowing. An explicit approvalPolicy: "never" could stay non-prompting.
   • A test like the Auto-accept edits one, repeated for runtimeMode: "auto", would cover it. It would call canUseTool for a Bash command and require a command runtime request before any decision. The policy-mapping assertion would change along with it.
   • Full access (bypassPermissions) has the same auto-allow, and Claude would still send ask rules to the callback there. The guide says that mode doesn't prompt, so whether it should honor ask rules is a separate question.

   Until then, Supervised or a PreToolUse hook that denies the command are good workarounds. A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 3, 2026