bypassPermissions mode now prompts on `cd DIR && grep …` when a Read() deny rule is configured (regression in 2.1.259)

[TalkingMonkeyOz]

Environment

• Claude Code 2.1.259 (native install, ~/.local/bin/claude.exe), auto-updated from 2.1.258 on 2026-09-03 12:33 local time. 2.1.258 did not prompt on the same commands.
• Windows 11 Pro 10.0.26200, Git Bash / PowerShell.
• Auth: claude.ai subscription (Max 20x), not API key.
• User settings (~/.claude/settings.json): "permissions": { "defaultMode": "bypassPermissions", "allow": [], "deny": [], "ask": [] }, "skipDangerousModePermissionPrompt": true.
• Project settings (<repo>/.claude/settings.local.json): 24 deny rules protecting secrets, e.g. Read(**/.env), Read(**/.env.*), Read(**/credentials*), Read(**/*.pem), Read(**/*.key), Read(**/id_rsa*), Read(**/.ssh/id_*), plus the matching Edit(...) rules. No defaultMode at project level.
• Remote Control / desktop-app companion was connected to the session.

What happened

A background sub-agent (spawned with the Agent tool, general-purpose, model sonnet) ran:

cd C:/Projects/claude-family && grep -rl "psycopg2\|DATABASE_URI\|DATABASE_URL" scripts/*.py 2>/dev/null | head -5
echo "---"
grep -n "psycopg2\|DATABASE_URI\|DATABASE_URL\|def get_conn\|def connect" scripts/config.py 2>/dev/null | head -20
echo "--- sample usage in another script ---"
grep -n "import psycopg2\|psycopg2.connect\|DATABASE_URI" scripts/nightly_cleanup_orchestrator.py scripts/task_worker.py 2>/dev/null | head -20

The terminal showed a permission dialog:

Bash command · from the usage-history-analyst agent
...
grep on 'scripts/*.py' after a cd would search a directory that cannot be
determined here, and a Read() deny rule is configured; only you can approve
running it anyway.

Do you want to proceed?
❯ 1. Yes
  2. No

The session's own transcript records permissionMode: bypassPermissions on every permission-mode entry before, during and after this prompt. The mode never changed.

None of the files the command touches match any deny rule. scripts/*.py contains no .env, credentials, key or PEM files.

What I expected

In bypassPermissions mode the tool never asks. If the new deny-rule coverage cannot resolve the target directory, it should either (a) run the command, since bypass mode has already accepted that risk, or (b) refuse it with a tool error the model can react to. Presenting a modal yes/no to a human who has explicitly turned prompting off defeats the mode, and for sub-agents and unattended sessions it is a silent stall.

Why I think this is the cause

2.1.259 changelog:

Fixed Bash Read() deny rules not covering files given as option values (--ignore-revs-file=.env, -f.env, @file), git diff/git grep file operands, or cd DIR && cat FILE compounds; grep -r/cp -r over a directory holding a denied file now asks

The hardening is welcome. The problem is that "now asks" is applied regardless of permission mode, and it fires on any cd DIR && grep … compound where the directory "cannot be determined", even when no denied file is involved. The cd is to the session's own working directory.

Steps to reproduce

1. Put "defaultMode": "bypassPermissions" in ~/.claude/settings.json.
2. In a project, add Read(**/.env) (or any Read() deny rule) to .claude/settings.local.json permissions.deny.
3. Start claude in that project; confirm the footer shows bypass mode.
4. Ask it to run: cd <absolute path of the project> && grep -rl "import" scripts/*.py | head -3 (any directory with no denied files).
5. Observe the "Do you want to proceed?" dialog. Repeat on 2.1.258: no dialog.

Sub-agents make it worse: they habitually prefix commands with cd <repo> &&, so a single analysis task produces a stream of prompts.

Secondary observations (same session)

• The prompt appeared only in the terminal. The desktop app view of the same session did not surface it, so a user watching from the app sees the session hang with no explanation.
• The harness injected a "You have exited auto mode" system notice mid-session although the transcript shows the mode was bypassPermissions throughout and auto mode was never entered.

Workaround

Tell agents not to use cd DIR && prefixes or recursive grep over directories (use explicit file lists or a file-search tool). That removes the prompts but means the deny-rule coverage fix is effectively being routed around, which is not what anyone wants.

---

[goofansu]

This is really a problem, in a rails project with the .claude/settings.json:

{
  "permissions": {
    "deny": [
      "Read(/config/master.key)"
    ]
  }
}

Prompting claude grep config and it'll ask user to confirm:

grep on 'config' would read '<project_name>/config/master.key' which the deny rule Read(/config/master.key) covers; only you can approve running it anyway.

Do you want to proceed? 
› 1. Yes 
  2. No

It breaks the autonomous workflow a lot.

Expect: claude should deny the access automatically according to deny rules instead of asking user to confirm.

[Swift42]

See also #91650

[ArtemShaban]

Confirming this on macOS (Darwin 25.6, arm64), headless tmux session launched with --dangerously-skip-permissions, driven by background subagents. Same regression, plus a few data points that may help pin it down:

Version bisection (byte-scan of the three installed bundles under ~/.local/share/claude/versions/):

string	2.1.257	2.1.258	2.1.259
cannot be determined here	0	0	2
only you can approve running it anyway	0	0	4
deniedPathInsideDirectory	0	0	3
cd-compound-read	2	2	2

So the cd + relative read miss-kind itself is older, but in 257/258 it carried decisionReason:{type:"other", bashMissKind:"cd-compound-read"} and bypass mode swallowed it. 2.1.259 adds a second branch that emits decisionReason:{type:"safetyCheck", classifierApprovable:false, circuitBreaker:"deniedPathInsideDirectory"}, and that breaker is registered as bypassImmune:true, classifierRouted:false — hence the card even in bypass, and no allow rule / hook allow / classifier can answer it (a hook allow is re-evaluated and still cards).

Trigger set as read from the bundle: precondition = at least one deny rule equal to Read or starting with Read( (the check keys on the mere presence of such a rule, not on whether the glob could match); cwd-change detector = any subcommand whose first token is cd, pushd, popd, chdir — computed over the whole command, so a trailing && cd X or a cd on an earlier line of a multi-line command arms it too; bypass-immune readers = grep, egrep, fgrep, rg, diff, git grep, git diff, cp, mv; operand must be non-absolute, not ~-prefixed, not a command substitution.

Impact in an automated setup: three cards in ~2 hours from subagents (cd <dir> && grep … file, and a 4-line command with cd on line 1 and grep … tools/x.json on line 3). Each one blocks the agent until a human presses a key in the parent TUI.

Workaround that works: a PreToolUse hook on Bash that denies the shape with a rewrite recipe (absolute path, no cd) — the hook deny path returns before the safety check runs, so the agent self-corrects and the card never appears. A hook allow does not work (re-evaluated).

Ask: in bypassPermissions this breaker should either be suppressed, or be answerable by a permission rule (e.g. an allow for a directory prefix), or at least be classifier-routable — a bypass-immune ask that no configuration can pre-approve breaks every unattended session.

[jimweller]

This reproduces on macOS. This issue and #91776, #91650, #91837 all carry platform:windows, so the label may be sending triage in the wrong direction.

Environment

• Darwin 24.6.0 (macOS), arm64, native install

• Claude Code 2.1.259

• permissionMode: bypassPermissions

• Deny rules in user settings:

  "deny": [
    "Read(~/.config/sops/age/keys.txt)",
    "Read(**/keys.txt)",
    "Read(**/*.age)"
  ]

Repro

cd ~/.local/share/claude/versions && rg -a -o 'bypassPermissions' 2.1.259

rg on '2.1.259' after a cd would search a directory that cannot be determined
here, and a Read() deny rule is configured; only you can approve running it anyway.

Both operands are literals. 2.1.259 is a regular file rather than a directory, and it matches neither **/keys.txt nor **/*.age. Re-running the same search against an absolute path with no cd runs without a prompt.

Version attribution

This issue and #91776 both attribute the change to 2.1.259. The gate code is byte-identical in 2.1.257, 2.1.258 and 2.1.259. Grepping the installed binaries for the message string and for the bashMissKind value:

Version	deny rule is configured	cd-compound-read
2.1.251	absent	absent
2.1.252	absent	absent
2.1.257	present	present
2.1.258	present	present
2.1.259	present	present

2.1.253 through 2.1.256 were not installed on this machine, so the introduction point sits somewhere in that range. I have not ruled out a server-side flag holding the check inert before 2.1.259, so the reports of 2.1.258 behaving differently may still be accurate. #91650 does report it on 2.1.257.

Trigger condition

From the 2.1.259 bundle, with names inferred since it is minified:

if (hasCd && kind === "read"
    && paths.some(p => !isAbsolute(normalize(p)))
    && (I || cmd !== "cd" && hasReadDenyRule(ctx))) { ... }

The some predicate tests the read targets, not the cd operand. That lines up with the request in #91776: resolving a literal cd operand against the relative target would clear the first three cases listed there and leave the fourth prompting, which is the correct split.

Docs

The behavior is undocumented. /docs/en/permissions states that two combinations prompt when each part is read-only, cd with git and cd with an output redirect. This is a third. The "Actions no mode auto-approves" list at /docs/en/permission-modes has five bullets and none of them cover it. A third bullet on the first list would make this self-service.