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

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.

---