[Bug] Auto mode fails closed on Edit/Write in working dir (2.1.299/2.1.300, Windows)

Bug Description
Auto mode regression 2.1.299/2.1.300 (Windows, Git Bash): every Edit/Write inside the working dir (M:\0xPLC_Projects\..., local exFAT drive) fails with "server-side auto mode classifier gave no verdict (it skipped this action)", toolDenialKind automode-unavailable. Server returns "skipped" for these calls and the CLI no longer applies the acceptEdits fast path, so it fails closed. 2.1.296 works (reasonType "mode"). Headless repro: claude -p "<write one file>" --permission-mode auto --debug-file: 2.1.300 logs "Auto mode classifier unavailable ... (fail closed)", 2.1.296 writes the file. C: paths and M:\ root are classified normally. Team org, cc-plugin-sec-default seated. Full report incl. session/request IDs follows on GitHub.

Environment Info

• Platform: win32
• Terminal: windows-terminal
• Version: 2.1.300
• Feedback ID: cb6e5d24-0e96-431a-b467-ebf95b83540d

Auto mode: Edit/Write inside the working directory fail with "server-side auto mode classifier gave no verdict (it skipped this action)" since 2.1.299 (regression from 2.1.296)

Summary

Since Claude Code 2.1.299 (still present in 2.1.300), every Edit/Write in auto mode to a file inside the
working directory fails with:

The server-side auto mode classifier gave no verdict (it skipped this action), so auto mode cannot determine the safety
of Edit. This is a hard failure, not a transient one: ...

Transcript entry: toolDenialKind: "automode-unavailable",
permissionDecision: {"decision":"reject","source":"config","reasonType":"classifier"}.

Up to 2.1.296 the same edits were allowed by the acceptEdits fast path
(permissionDecision.reasonType: "mode"), without needing a classifier verdict. In 2.1.299+ the local fast path no
longer allows them. The server classifier returns skipped for these calls (it leaves them to the CLI). The CLI then
has no verdict and fails closed. The net result is that auto mode cannot edit any file in the project.

Downgrading to 2.1.296 (claude install 2.1.296) fixes it immediately, with the same project, settings, account and model.

Environment

• Claude Code native build, Windows 11 Pro 10.0.26200
• Shell: Git Bash (the transcript cwd / classifier live_cwd is recorded in MSYS form, /m/0xPLC_Projects/<project>)
• Project on drive M:. This is a local fixed exFAT volume, not a network drive. Working dir: M:\0xPLC_Projects\<project>
• Git repo (Bitbucket remote, visibility "unknown")
• Team organization: the debug log shows cc-plugin-sec-default@builtin seated outermost: the organization is team
• permissions.defaultMode: "auto", model claude-opus-5-5[1m]
• Broken: 2.1.299, 2.1.300 · Working: 2.1.295, 2.1.296

Reproduction (headless, deterministic)

From the project root on the M: drive:

claude -p "Use the Write tool exactly once to create the file _automode_debug_probe.txt in the current working directory with the content: probe." \
  --permission-mode auto --debug-file debug.txt --max-turns 3

• 2.1.300: Write denied with the "gave no verdict (it skipped this action)" message. Debug log:

``
[DEBUG] hooks module cc-plugin-sec-default@builtin tool.check settled in 22.3ms (native link, next() included)
[WARN] Auto mode classifier unavailable, denying with retry guidance (fail closed)
[DEBUG] Write tool permission denied
``
There is no "Skipping auto mode classifier for Write: would be allowed in acceptEdits mode" line.

• 2.1.296 (~/.local/share/claude/versions/2.1.296 -p ..., same command): the file is created.

permissionDecisionMs=21, outcome=ok.

Path matrix (2.1.300, same session, auto mode)

| Target | Result |
|---|---|
| M:\0xPLC_Projects\<project>\_test.txt (inside cwd) | no verdict (server skipped) |
| M:\0xPLC_Projects\<project>\documentation\<file>.md (existing file, inside cwd) | no verdict |
| M:\0xPLC_Projects\_test.txt (same drive, parent of cwd, outside cwd) | no verdict |
| M:\_test.txt (same drive, root) | classifier evaluated, accepted (then the write failed with EPERM: operation not permitted, mkdir 'M:\', a separate minor issue: mkdir of an existing drive root) |
| C:\Users\<user>\_test.txt | classifier evaluated, accepted |
| C:\Users\<user>\0probe_test.txt | classifier evaluated, accepted |
| session scratchpad on C: | allowed (reasonType: "other") |

Reads on the same M: paths are still allowed by the mode (reasonType: "mode"). Bash commands are classified and
accepted normally.

Transcript history (same project, auto mode, Edit/Write on M:)

| Date | Version | Decision |
|---|---|---|
| 2026-10-09 | 2.1.294 | accept / config / mode |
| 2026-10-13 | 2.1.295 | accept / config / mode (55 edits/writes) |
| 2026-10-14 | 2.1.296 | accept / config / mode |
| 2026-10-15 | 2.1.299 | reject / classifier / automode-unavailable |
| 2026-10-15 | 2.1.300 | reject / classifier / automode-unavailable |

Analysis (from the client code, 2.1.300)

• dFt: when the per-call server status is {type:"skipped"}, the CLI calls its local fallback. That fallback returns

nothing in this session (server "arbiter" mode), so the result is unavailable → "Classifier unavailable - blocking for safety"
→ toolDenialKind: "automode-unavailable", with the errorKind server_call_skipped ("it skipped this action").

• The intended path for in-cwd edits is the acceptEdits simulation. When that check allows and the server skipped,

the CLI logs "Server classifier skipped Write or left it to this CLI: the tool's own allow stands" and allows with
decisionReason {type:"mode", mode:"auto"}. In 2.1.299+ this path is not taken for these files. Either the local
acceptEdits check no longer returns allow for them, or it throws: the fast path is wrapped in a try/catch that logs
tengu_auto_mode_decision { decision: "fastpath_error" } and silently falls through to the classifier.

• So the server and the CLI each leave the decision to the other, and the call fails closed. The error text says

"retrying will get the same answer", which is accurate, so the user is stuck in auto mode for every file edit.

Possibly relevant specifics of this setup: Git Bash as shell (MSYS-form live_cwd /m/... sent to the server while
tool paths are M:\...), an exFAT project volume, and a Team org with cc-plugin-sec-default@builtin seated outermost
(its tool.check runs right before the denial).

Identifiers

• Session (2.1.300, interactive): f24cf042-f3b7-4403-abd0-78b7929b0772. Failing edits in request req_011Cg3jf8evVKBF8ojSpLrcw (2026-10-15 08:50:52Z)
• Session (2.1.299, interactive): 44287fde-e6d6-4dc2-94d5-2053ee512048. First failures at 2026-10-15 07:48:55Z
• Headless repro (2.1.300): x-client-request-id f278678d-b580-4169-870b-3f6f8562705c, 2026-10-15 09:11:12Z
• Headless control (2.1.296): 2026-10-15 09:12:08Z, success

Expected

Edits to files inside the working directory are allowed in auto mode, as in 2.1.296. At minimum, a call that the
server skipped should fall back to a permission prompt instead of a hard failure.

Workaround

claude install 2.1.296 plus DISABLE_AUTOUPDATER=1, or switch to acceptEdits mode (shift+tab).