[BUG] Claude Code v2.1.212 asks approval for ALL bash commands in plan mode

Confirming this on a different setup, which suggests the scope is wider than claude agents on macOS.

• Claude Code 2.1.212, Linux, normal TUI (not claude agents)
• permissions.defaultMode: "auto" in ~/.claude/settings.json
• useAutoModeDuringPlan unset, so at its documented default of true
• sandbox.enabled: true with autoAllowBashIfSandboxed: true
• Auto mode is available on the account (claude auto-mode config returns a populated classifier config)

Two things worth adding.

Auto mode does not rescue it. Even with auto mode active and useAutoModeDuringPlan at its default, plan mode still prompts on plainly read-only Bash. The reason shown is the generic This command requires approval. So the classifier is not acting as a fallback here, which rules out "just use auto mode" as a workaround.

It bites hardest through Bash-heavy subagents. In my sessions the main agent in plan mode mostly uses the Read/Grep/Glob tools, which are unaffected, so it looks fine. The Plan subagent is about 62% Bash (sed, grep, cat, compound read-only exploration), so nearly every one of its calls prompts. Counting tool calls across my local subagent transcripts:

| agentType | Bash calls | share of tool calls |
|---|---|---|
| Plan (spawned in plan mode) | 115 | 62% |
| Explore (spawned in auto mode) | 1373 | 51% |

Explore uses Bash just as heavily and is not affected, which lines up with this being plan mode specific rather than a subagent issue. Subagents inherit the parent's permission mode by default per the 2.1.212 notes, so a Plan subagent inherits plan mode and inherits the regression with it.

Read-only commands that prompt for me include bare grep -rn ... | head, sed -n '1,40p' file, and python -c "import somemodule; print(...)". Nothing with side effects.

Agreed on the likely cause being the 2.1.212 note "Fixed plan mode auto-running file-modifying Bash commands (e.g. touch, rm) without a permission prompt or SDK canUseTool callback". The underlying fix is clearly right, but it looks like the new gate catches every Bash command rather than only file-modifying ones.

Additional issues with this 2.1.212 change (observed in a single session with no agents):

• Permission dialog offers "Always allow", which writes redundant .claude/settings.local.json allowlist entries that do not actually work for plan mode
• No apparent way to whitelist a command for plan mode
• No apparent way to not have any extra Bash checks in plan mode

Reproducible on macos + wezterm terminal

Additional datapoint: this also reproduces in the native TUI on Windows — so it does not appear to be limited to claude agents nor to platform:macos.

Environment:

• Claude Code v2.1.214, native install, Windows Terminal TUI
• Windows 11 Home 25H2 (build 26200.7462), ARM64 — Snapdragon X X1E80100, 64 GB RAM
• Shell tool: PowerShell (pwsh 7); WSL2 installed but not in use
• Started within the past week for me as well (autoUpdatesChannel: "latest")

In plan mode, every shell command now prompts, including cmdlets explicitly allow-listed in ~/.claude/settings.json:

"PowerShell(Get-ChildItem:*)",
"PowerShell(Test-Path:*)",
"PowerShell(Get-Content:*)",
"PowerShell(Get-ScheduledTask:*)",
"PowerShell(Write-Output:*)"

Identical calls issued by read-only (Explore) subagents prompt as well. Before ~v2.1.212, plan mode ran all of these without prompting.

🤖 Generated with Claude Code in the session with id d8e31d61

I am also encountering this in Claude Code CLI 2.1.214. During plan mode, workflow agents keep prompting for permissions. I temporarily downgraded claude to 2.1.211.

Additionally, I noticed that when connecting remotely (/remote-control), the permission mode is set to Manual. Is it possible that the permission modes conflict?

useAutoModeDuringPlan also does not work.

Looking at 2.1.212 change logs, i'm pretty sure this issue comes from here ?
Fixed plan mode auto-running file-modifying Bash commands (e.g. touch, rm) without a permission prompt or SDK canUseTool callback 

Update: Still occurs on v2.1.216 -- downgrading now to v2.1.211

Still reproduces on v2.1.217.

Environment: macOS (Darwin 25.5.0), Ghostty + tmux, native TUI, defaultMode: "auto" (useAutoModeDuringPlan unset)

Additional datapoints from a session transcript analysis (2026-07-22, an issue-handling workflow that enters plan mode right after creating a worktree):

• The prompts are strictly confined to plan mode. Between EnterPlanMode and ExitPlanMode, read-only Bash commands (grep, gh run list, gh api, for loops over gh issue view) required approval. After ExitPlanMode, the exact same session ran compound commands, sed -i, git commit, etc. with zero prompts — auto mode classification works fine outside plan mode.
• Subagent Bash calls are also gated. Read-only Explore-type subagents launched during plan mode had their Bash commands surface permission prompts to the parent. Measured tool_use → tool_result gaps in the transcript: one gh run list waited 12,340 s (~3.4 h) for approval, others waited 1,456–1,461 s.
• While one Bash approval is pending, the subagent's other parallel tool calls (including plain Read) queue behind it, so a single prompt stalls the whole investigation fan-out.

This makes plan mode effectively unattended-unusable: any workflow that researches during planning blocks on the first compound read-only command until a human returns.

As of v2.1.218 this is fixed by "Changed plan mode with auto to no longer prompt for Bash commands the static analyzer can't prove read-only; the auto-mode classifier judges them instead". Closing.