Auto mode: subagent inheritance of parent classifier trust is unreliable (intermittent, destination-keyed denials)

Bug report draft — Auto Mode classifier: subagent trust inheritance unreliable

Claude Code version: 2.1.228
OS: Windows 10 (native, not WSL2)
Permission mode: Auto mode

Summary

Subagents spawned via the Agent/Task tool intermittently receive "Blocked by
classifier" denials for writes to destinations the parent session is already
trusted for — including the agent's own designated scratchpad/temp directory,
which the parent session writes to without issue. Per the docs
(sub-agents.md), a subagent is supposed to inherit the parent session's Auto
Mode rules verbatim ("the classifier evaluates the subagent's tool calls with
the same block and allow rules as the parent session"). That inheritance does
not reliably hold in practice.

Reproduction pattern (from a real session)

One subagent (Sonnet-high, working on an Unreal Engine delivery task),
mid-afternoon window, ~35 minutes:

1. Bash file-write copying stamped PNGs into the project tree

(U:\dev\CVUI\Training_Delivery\) — DENIED, "Blocked by classifier."

1. Identical operation, redirected to the agent's scratchpad directory

instead — SUCCEEDED. This pair establishes the block as
destination-keyed, not operation-keyed.

1. Later, via a remote-exec channel driving an already-running Unreal Editor

process: a read-only verification call succeeded; a call that makes the
editor process create/save .uasset files under Content/ —
DENIED twice, identical message both times. Notably, the agent's own
tool call did not perform the disk write directly — the long-running
editor process did, after being instructed via IPC. The denial still
fired, meaning the classifier is scoring the instruction/destination
rather than only the literal disk-write syscall.

1. Budget/quota was ruled out as a cause (write-unlock-cli.py status

showed 676/999 remaining on our separate local write-approval hook at the
time — unrelated system, but confirms it wasn't a budget exhaustion
coincidence).

Contrast set — same day, same project, NOT blocked

Five other subagent sessions performing equivalent or more sensitive writes
(direct Edit/Write to Source/CVUI/, hundreds of edits under
Python/CommandPanel/, new files + p4 add under Python/TestSuite/,
editor-driven asset/map saves and Blueprint creation) all completed without
any classifier denial, before and after the blocked session's time window.

Separate, known-shape issue for comparison (not this bug)

A different agent's narrative report file (findings.md) written into a
Documentation/Research/ folder was also blocked, while script and CSV
files in the same folder landed fine. This matches a previously-observed
"subagent report-file writes get blocked" pattern and may or may not share
a root cause with the above — flagging for completeness, not conflating.

Other characteristics reported by the user across multiple sessions

• Not tied to one specific path — happens across different sessions and

different target directories.

• Intermittent and retry-sensitive: sometimes simply retrying the same

subagent tool call succeeds after an initial denial, with no config
change in between.

• Sometimes fixed by the user typing an explicit permission statement into

the parent conversation (e.g. "you and your agents have permission to
run bash") — after which subsequent subagent calls succeed. Per Auto Mode
docs, a sufficiently specific conversational statement of intent is a
real documented input to the classifier (can override a soft_deny), but
it's unclear whether that mechanism explains fixes to plain destination
trust, or whether the "fix" is coincidental with an unrelated retry.

• The specific recurring pain point in daily use: subagents get blocked

writing their own progress-journal / final-report files into the
scratchpad temp directory the harness itself designates for them
(c:\Temp\claude\<project>\<session-guid>\scratchpad). The Claude Code
system prompt tells agents this directory "can generally be used without
permission prompts," but the classifier does not appear to honor that
reliably. Because the path includes a per-session GUID segment, no static
autoMode.environment entry can pin the exact literal path across
sessions — we worked around this by adding a prose entry describing the
parent directory tree (C:\Temp\claude\) as trusted, but this is a
mitigation, not a guaranteed fix, since autoMode.environment entries
are natural-language hints to a model-based classifier, not literal path
rules.

What we've ruled out

• Not our own custom write-approval hook (separately verified via its own

audit log/status — unrelated system, already had budget).

• Not the filesystem sandbox (dangerouslyDisableSandbox) — that feature

doesn't run on native Windows at all per docs.

• Not the known v2.1.217 "stale cache on parallel/pending permission

checks" bug — we're on 2.1.228, well past that fix.

• Not simple misconfiguration — autoMode.environment was previously

empty/default, and the denial pattern (parent fine, child blocked, same
destination) points at inheritance, not scope.

Ask

Is subagent trust inheritance from the parent session's Auto Mode state
expected to be instantaneous/synchronous, or is there a known propagation
delay or caching layer that could explain intermittent denials shortly
after a parent session establishes trust (e.g. via conversation, via a
prior successful action, or via settings load)? Is there a supported way to
make a directory tree containing a variable (session-GUID) path segment
reliably trusted, rather than relying on the classifier's prose
interpretation of a parent-directory description?