[BUG] Asked permission to run `cd /x/y/z && rm -rf *` in "bypass permissions" mode.

wow! maybe I'm mistaken, but it seems to me you are asking for a yolo mode where absolutely nothing is disallowed. instead of allowing random cli commands, you might consider having a script that does exactly what you want, that you offer to the llm for that specific task.

Or maybe have a whitelist list of commands YOU, specific user, have decided to live with, on that specific environment instance...

Opening up a mode that casual user have been using up until now with little worry, seems a bit reckless to me.

Even in --dangerously-skip-permissions, it may still be worth separating two concepts that are currently coupled:

1. permission prompts: should never block in bypass mode
2. destructive-command classification: should still be recorded as telemetry/audit context

The bug is that classification appears to be taking the blocking path. The safer behavior would be: classify rm -rf as high-risk, log the resolved working directory and command, but auto-allow because the user explicitly selected bypass.

The cd /x/y/z && rm -rf * shape is also a good parser test. The risk classifier should evaluate the command after shell-context normalization, not just pattern-match rm -rf * as if it runs from the original cwd. If the normalized cwd is known and inside the allowed project/sandbox root, bypass mode should proceed without a prompt.

That keeps the audit receipt without breaking the contract of bypass mode.

Bypass mode can suppress prompts without suppressing classification. The runtime should still parse, normalize, and log the command envelope, then apply the configured prompt policy separately. For this case, safety depends on understanding the cd and rm as two AST nodes with the second cwd derived from the first; string matching rm -rf without execution context will create false positives. A regression should cover logical chains, failed cd, subshells, quoted paths, and newlines while asserting zero prompts only in the explicit bypass mode.

Confirming this on v2.1.214 with a slightly different command shape — same root pain.

I run Claude Code inside my own Docker container (kernel-isolated from the host Mac via Docker Desktop's Linux VM). --dangerously-skip-permissions is the whole point of that setup: I've taken responsibility for isolation myself, and I need the agent to actually finish work unattended.

The pattern that reliably triggers the prompt is any build-check chain that refreshes a cache before a typecheck, e.g.:

cd <worktree> && make lint > log && make format >> log && rm -rf .mypy_cache/* && make typecheck >> log

The rm -rf .mypy_cache/* is mandatory here because mypy's incremental cache silently misses new/changed files — the pre-PR typecheck has to run fresh. The cd is unavoidable (per-tool cwd), the glob is unavoidable (cache contents are dynamic), and chaining into one Bash call is the only sane way to keep logs coherent. Every leg is intentional, and bypass mode still stops on it.

Strongly agreeing with @0xbrainkid and @BGMLAI: the coupling of "destructive-command classification" and "permission prompt" is the actual issue. Classification should be recorded (telemetry/audit — great), but it must not escalate to an interactive prompt under a mode whose entire purpose is "no interactive prompts." Decoupling them keeps the audit signal without triggering prompts under bypass.

What I'd specifically ask for: an opt-out for the dangerous-rm safety check under bypassPermissions mode. Not a removal — a flag/setting, so users who made an informed choice (container isolation, throwaway VM, CI, etc.) can let bypass mean bypass.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)