Auto permission mode: classifier ignores explicit allow rules for file tools; un-rendered "ask" prompts time out after exactly 10 minutes to a misleading "user declined" error

Environment

• Claude Code 2.1.183 (desktop app session host)
• Windows 11 Home 10.0.26200 (win32)
• Auto permission mode active (auto-mode opt-in previously accepted; skipAutoPermissionPrompt: true)
• Model: claude-fable-5

Summary

With auto permission mode active, built-in file tools (Read / Write / Edit) are
intermittently denied even though unconditional allow rules for those tools exist at BOTH
user and project scope ("Read", "Write", "Edit" bare, plus path-scoped variants; no
deny rules; no hooks). The denials present as
"The user doesn't want to take this action right now. STOP what you are doing…" —
but the user took no action. Transcript timestamps show each denial resolves EXACTLY
600.0s after the tool call was issued, and queued calls resolve 10 minutes after the
previous denial, i.e. an invisible permission prompt queue draining by timeout.

Evidence

1. Exact 10-minute timeouts (from the session transcript)

| Tool call | Issued | Denied | Delta |
|---|---|---|---|
| Read (md file in cwd) | 08:46:48.008 | 08:56:48.026 | 10:00.018 |
| Read (package.json in cwd) | 08:58:56.648 | 09:08:56.660 | 10:00.012 |
| Read (md file in cwd) | 08:58:57.568 | 09:08:57.576 | 10:00.008 |
| Write (session scratchpad) | 08:58:59.338 | 09:18:57.592 | 10:00.016 after the PREVIOUS denial |

A Bash call batched with those three file calls also blocked ~20 minutes before
executing (successfully) — the whole batch serialized behind the invisible prompts.

2. The classifier is the denying layer (direct confirmation)

A later denial in the same session used a different, explicit message:

"Permission for this action was denied by the Claude Code auto mode classifier. Reason: …"

3. Allow rules ignored

User settings.json: permissions.allow includes bare "Read", "Glob", "Grep",
"Edit", "Write". Project settings.local.json additionally allows Read, and
path-scoped Write(...)/Edit(...) covering the working tree. No deny, no ask,
no hooks, no managed settings. The denied Reads were of ordinary text files INSIDE the
primary working directory — which shouldn't prompt in any mode, let alone with bare
Read allowed twice over.

4. Intermittency

In one session: three Reads at 08:05 returned instantly; a Read of a file in the same
directory at 08:46 hit the 10-minute-timeout denial. Overnight autonomous runs showed the
same pattern at scale: dozens of file-tool denials across supervisor + subagents (including
all image Reads, killing visual QA), while Bash never bounced. Verdicts appear stochastic
and context-sensitive.

Expected behavior

1. Explicit allow rules should short-circuit the auto-mode classifier (or at minimum,

in-cwd Reads should never route to a prompt).

1. If a classifier "ask" cannot be rendered to the user, that should surface as an error

naming the real cause ("permission prompt timed out / could not be displayed"), not as
an explicit user decline. Agents (and users reading logs) act on that message as if the
human deliberately refused seconds ago.

1. A 10-minute serial prompt queue silently stalls unattended/overnight sessions —

batches of 3+ file calls lose 20-30+ minutes each. Some visibility (log line, status)
would make this diagnosable; it took transcript-timestamp forensics to find.

Impact

• Unattended/long-running sessions stall for multi-10-minute stretches and subagents die

on denied file tools despite maximally-permissive user configuration.

• Image Reads have no shell fallback (vision), so classifier denials remove that

capability entirely.

• The misleading denial text sent both the agent and the user hunting for a nonexistent

manual rejection for days.

Workarounds found

• Shell tools (Bash/PowerShell) for file I/O — never denied.
• User hand-edits settings to defaultMode: "bypassPermissions" + `disableAutoMode:

"disable"` (project scope). Note the classifier hard-blocks the agent itself from
writing those settings even with explicit in-chat user authorization — presumably
intended self-modification protection, but it means there is no in-session recovery
path at all; combined with the invisible prompts, the user has to discover the fix and
apply it by hand.

Repro sketch

1. Windows desktop-app-hosted session with auto permission mode active and bare

Read/Write/Edit allow rules at user + project scope.

1. Run a long session with many file-tool calls (subagents help).
2. Observe intermittent denials with the "user doesn't want" message; check transcript

timestamps for the exact 600s deltas.