auto-mode classifier prompts/denies on routine Write of project files in 2.1.138 (regression)

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

1. 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).
2. 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\.
3. 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.