Approved tool-use prompts (Write/Edit/Bash) are sometimes silently rejected — no error, indistinguishable from a genuine decline; combined/multi-argument commands fail more than split single-argument ones

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Body:

Environment

• OS: Windows 11 Home Single Language 10.0.26200
• Claude Code CLI: C:\Users\clint\.local\bin\claude.exe (native build, not npm)
• Working directory: C:\Blue\platform
• Single CLI process confirmed running (checked via Get-CimInstance; ~14 other claude.exe processes present were unrelated Electron desktop-app helpers, not duplicate CLI instances)
• No project-level .claude/settings.json hooks configured
• No mid-session client auto-update occurred

Core symptom
A tool-use permission prompt is shown, the user explicitly approves it (typed/clicked "yes"), and the tool call still returns as rejected — "The user doesn't want to proceed with this tool use." — identical to a genuine decline. There is no distinguishing signal in the tool result between "you actually said no" and this failure mode, which makes it unsafe/confusing: an agent (or a user skimming output) cannot tell the two apart.

Affected command types (confirmed across two sessions)

• Write (new file creation) — 3 consecutive failures on one file (null-storage.ts) before workaround
• Bash heredoc file writes (cat > path << 'EOF') — failed on first attempt for a different new file, despite working as a same-session workaround moments earlier for the first file
• Edit — both a large combined edit and a deliberately isolated single-line edit on eslint.config.js, both rejected on first attempt (ruling out edit size/complexity as the sole factor)
• Bash — pnpm install/package-add operations
• git add — specifically the combined multi-path form: git add pathA pathB pathC && git status failed twice; three separate single-path git add path calls each succeeded on the first attempt immediately after
• git commit — required a retry cycle before landing

Key finding: combined vs. split commands
The clearest, most actionable signal from this investigation: a single Bash call combining multiple paths/commands failed repeatedly, while functionally identical calls split into one path/command per invocation succeeded on the first try, every time. This reproduced cleanly for git add (3-path combined form failed twice; 3 single-path calls succeeded 3/3). It did not reproduce as cleanly for Edit (an isolated single-line edit still failed), so this is a lead, not a fully confirmed mechanism — but it's specific and testable.

What Should Happen?

Here's text for both fields:
What Should Happen?
When a tool-use permission prompt is shown and the user explicitly approves it (clicks/types "yes"), the tool call should execute. If it doesn't execute for any reason, the failure should be distinguishable from a genuine user decline — e.g. a distinct error like "approval succeeded but execution failed" rather than the same generic "The user doesn't want to proceed with this tool use" message that's returned on an actual decline. An approved action should never silently fail with no way to tell it apart from a rejection the user never gave.

Error Messages/Logs

**Root-cause lead: `tengu_rc_permission_nudge`**
`~/.claude.json` → `cachedGrowthBookFeatures` contains:

"tengu_rc_permission_nudge": { "afterPromptCount": 2, "probability": 0.5, "maxImpressions": 3 }
This client-side GrowthBook A/B experiment is correlated with, but not conclusively proven as, the cause. The initial pattern (3 failures on one file, matching maxImpressions: 3) was suggestive, but a 4th identical retry on the same file also failed — either the impression counter isn't scoped the way the number implies, or a second mechanism is involved. A disposable probe Write to an unrelated new path succeeded immediately right after, ruling out a full session-wide stall — the failure narrows to something tied to live approval-dialog handling specifically (every successful Bash call all session matched an allowlisted pattern in settings.local.json or was read-only; every call that needed a real interactive approval dialog was where failures occurred, across all tool types).

What was ruled out
- Stale/duplicate CLI processes (single process confirmed)
- Project-level hooks (none configured)
- Mid-session client version change (none occurred)

Workarounds used (inconsistent reliability — none is a durable fix)
- Switching Write → Bash heredoc for one file (worked that one time; failed on first attempt for a different file later the same session)
- Splitting a combined git add pathA pathB pathC into three single-path calls (worked 3/3)
- Temporary "allow all edits" mode for one file
- Manual hand-edit in the editor for eslint.config.js after repeated Edit rejections (both large and minimal single-line edits failed)

Prior art checked (not duplicates, but related — worth cross-linking for triage)
- #62205 — different tengu_* GrowthBook flags (tengu_permission_friction, tengu_quill_harbor) silently locking sessions out of Bypass Permissions mode entirely, macOS Desktop only. Same "silent GrowthBook flag interference with the permission system" theme, but a distinct symptom (mode-lock, not per-call false rejection), no maintainer response, open+stale.
- #65910 — permission prompt silently replaced by a newer pending approval (LIFO stack) causing the wrong command to get approved, Linux, manual-approve mode. Different symptom (wrong command approved vs. approved command rejected) but conceivably related if combined/queued approval requests are involved.
- #30519 — meta-issue: "Permissions matching is fundamentally broken — 30+ open issues, no staff engagement." Useful context that this general area is under-resourced; not a specific match.

None of the above names tengu_rc_permission_nudge specifically or describes the split-vs-combined-command data point. Flagging #62205 and #65910 here in case a maintainer triaging either wants to link this one too — same GrowthBook/tengu permission-flag family, different specific symptoms.

Reproducibility note: intermittent — not reliably reproducible on demand from a fresh session; observed across two separate sessions on one machine. If a maintainer wants a minimal repro script, the most promising lead to script is the combined-vs-split git add comparison.

Ask: Does this match a known root cause? Is tengu_rc_permission_nudge a real, current experiment on your side, and if so, can it be disabled for this account? Is there a supported way (env var, settings flag) to opt out of permission-flow experiments generally, separate from --dangerously-skip-permissions?

Suggested label if the web UI offers one you can self-apply: `bug`.

Steps to Reproduce

This is intermittent and doesn't reproduce reliably on demand, but here is the pattern observed across two sessions:

1. Start a Claude Code session on Windows 11, using the native CLI build (not npm install).
2. Work through a normal multi-step coding task involving several tool-use approval prompts in a row (Write, Edit, Bash).
3. At some point (not on a fixed prompt count), approve a tool-use prompt normally.
4. Observe the tool result return as rejected — "The user doesn't want to proceed with this tool use." — identical to what a genuine decline produces, despite having approved.
5. Confirm independently that the approval was real and the action did not happen (e.g. read the target file directly — it is unchanged from before the "approved" write).
6. Retry the identical call. It may fail again 1-3 more times before succeeding, or succeed immediately — inconsistent.

The clearest reproducible sub-pattern found: a single Bash call combining multiple arguments/paths (e.g. git add pathA pathB pathC) fails on approval repeatedly, while the identical operation split into multiple single-argument calls (three separate git add path calls) succeeds on the first attempt every time. This was reproduced 2/2 combined-failures and 3/3 split-successes in one session.

Also relevant: ~/.claude.json → cachedGrowthBookFeatures on the affected account contains a tengu_rc_permission_nudge entry ({"afterPromptCount": 2, "probability": 0.5, "maxImpressions": 3}) — a client-side GrowthBook experiment whose config is suggestively similar to the failure pattern, though not conclusively proven as the cause (a 4th consecutive failure on one file didn't match the maxImpressions: 3 cap cleanly). Checking this cached flag value is the fastest way for a maintainer to confirm whether this experiment is active on a given account.

No minimal reproducible file/code example is included since this isn't triggered by specific file content — it reproduces across trivial new files, existing config files, and plain shell commands alike. Happy to provide a fuller session transcript if useful.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Code v2.1.212

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_