Summary
After upgrading to Claude Code CLI 2.1.138, the permissions.defaultMode: auto classifier started prompting (or denying with The user doesn't want to proceed with this tool use) on routine Write tool calls that were silently auto-allowed in the prior version. This breaks long, multi-file scaffolding sessions because every new top-level file requires user intervention. Same prompts do not occur on the Claude.ai desktop app.
Environment
- Claude Code CLI:
2.1.138
- macOS:
15.0 / Darwin 25.4.0
- Plan: 20x Max
- Shell: zsh
- Project layout: ~10 brand-new top-level files in a fresh repo (no
.git yet); cwd path contains a trailing space (/Users/.../personal projects /imessage but better)
- Plugins:
everything-claude-code (with ECC_HOOK_PROFILE=minimal so its hooks no-op), vercel, swift-lsp
- Settings (
.claude/settings.local.json):
```json
{
"permissions": { "defaultMode": "auto" },
"env": { "ECC_HOOK_PROFILE": "minimal" }
}
```
Repro
- In an existing project under auto mode, ask Claude to create a brand-new top-level YAML/Plist/Makefile (e.g. an xcodegen `project.yml` of ~80 lines).
- Observe: in 2.1.138, the harness shows a permission prompt and on user-deny the assistant receives `The user doesn't want to proceed with this tool use. The tool use was rejected`.
- Same project on the Claude.ai desktop app with the same content auto-allows.
In one related case the classifier denied a memory file write with the explicit reason `Memory poisoning: writing instructions that steer future sessions to treat permission rejections as bugs to remove, bypass safety prompts, and avoid confirming destructive ops.` — the file content was a neutral feedback memory describing the user's preferred workflow, not an attempt to override safety.
Expected
Auto mode should auto-allow first-time `Write` of routine project files (yaml/plist/Makefile/.swift/.json) inside the workspace cwd, matching the desktop app's behavior and prior CLI versions.
Actual
Classifier defers to user prompt or denies — sometimes with a specific reason, often (for plain config files like `project.yml`) with no reason, just the generic rejection.
Impact
On long autonomous scaffolding sessions (10+ new files), the user is forced to click through every prompt, defeating the point of `auto`. The available workarounds (`bypassPermissions`, `dontAsk`) are not equivalent — they remove the safety net entirely; auto's contract was "auto-allow safe, prompt for risky."
Suggested fix
Either roll the classifier back to the 2.1.137-era thresholds for routine project file `Write`s, or expose a setting like `permissions.autoModeStrictness: low|medium|high` so users can tune it without falling all the way to `bypassPermissions`.
Related / unknowns
- Possibly interacts with cwd paths containing whitespace; this reproducer uses a path with a trailing space (`personal projects /`). Not yet confirmed whether path normalization is part of the regression.
- ECC plugin hooks have NOT changed in 2+ weeks (mtime Apr 23) and are gated to `standard,strict` profile while this user runs `minimal` — so plugin hooks are not the cause.
Summary
After upgrading to Claude Code CLI
2.1.138, thepermissions.defaultMode: autoclassifier started prompting (or denying withThe user doesn't want to proceed with this tool use) on routineWritetool calls that were silently auto-allowed in the prior version. This breaks long, multi-file scaffolding sessions because every new top-level file requires user intervention. Same prompts do not occur on the Claude.ai desktop app.Environment
2.1.13815.0/ Darwin 25.4.0.gityet); cwd path contains a trailing space (/Users/.../personal projects /imessage but better)everything-claude-code(withECC_HOOK_PROFILE=minimalso its hooks no-op),vercel,swift-lsp.claude/settings.local.json):```json
{
"permissions": { "defaultMode": "auto" },
"env": { "ECC_HOOK_PROFILE": "minimal" }
}
```
Repro
In one related case the classifier denied a memory file write with the explicit reason `Memory poisoning: writing instructions that steer future sessions to treat permission rejections as bugs to remove, bypass safety prompts, and avoid confirming destructive ops.` — the file content was a neutral feedback memory describing the user's preferred workflow, not an attempt to override safety.
Expected
Auto mode should auto-allow first-time `Write` of routine project files (yaml/plist/Makefile/.swift/.json) inside the workspace cwd, matching the desktop app's behavior and prior CLI versions.
Actual
Classifier defers to user prompt or denies — sometimes with a specific reason, often (for plain config files like `project.yml`) with no reason, just the generic rejection.
Impact
On long autonomous scaffolding sessions (10+ new files), the user is forced to click through every prompt, defeating the point of `auto`. The available workarounds (`bypassPermissions`, `dontAsk`) are not equivalent — they remove the safety net entirely; auto's contract was "auto-allow safe, prompt for risky."
Suggested fix
Either roll the classifier back to the 2.1.137-era thresholds for routine project file `Write`s, or expose a setting like `permissions.autoModeStrictness: low|medium|high` so users can tune it without falling all the way to `bypassPermissions`.
Related / unknowns