[MODEL] Auto-mode permission classifier misses content visibility from prior Write tool calls in the same conversation

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude refused a reasonable request

What You Asked Claude to Do

Deploy a small Python LiteLLM hook to a Proxmox LXC container on a production box. Specifically: edit a local file, push it to the host, push it into the container via pct push, and run it.

What Claude Actually Did

Claude did the right thing structurally — used the Write tool to author the script locally (so the full content was visible in the conversation transcript), then issued a Bash call to scp the file to the host and pct push it into the container. The auto-mode classifier denied the Bash call with:

Permission for this action was denied by the Claude Code auto mode classifier. Reason: Pushing /tmp/unpatch_hook.py and executing it, but the script content is not visible in the transcript — running an unverifiable script on a shared production LXC container.

The script content was in the transcript — it appeared in the immediately prior Write tool call. The classifier appears to scope "is the content visible" to the current Bash command's args, not to the full conversation history.

Forced to fall back to inlining the same logic as a sed -i chain through ssh + pct exec + bash -c — the exact deep-quoting pattern the user has saved as project memory specifically to be avoided. The fallback was more fragile and produced its own set of bash quoting errors that further confused the session.

Expected Behavior

The classifier's "content visibility" check should examine the conversation transcript, not just the current tool call's args. If the file being pct pushed exists at a path that an earlier Write tool call wrote in the same conversation, treat the content as visible. Failing that, surface a structured way for the agent to cite the prior turn where the content lives so the classifier can re-check.

Files Affected

`/tmp/unpatch_hook.py` (local, transient) → `HOST:/tmp/unpatch_hook.py` (LXC container, transient). No persistent files modified by the blocked call — it was a one-shot script that mutates a file on HOST and exits.

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

Can You Reproduce This?

Yes — reliably, when the sequence is Write → Bash-that-scp's-then-pct-pushes-and-execs in auto mode.

Steps to Reproduce

1. Write(/tmp/myscript.py, "<10 lines of innocuous python>") — content fully expanded as the content parameter, visible in transcript.
2. Bash("scp /tmp/myscript.py host:/tmp/myscript.py && ssh HYPERVISOR 'pct push CTID /tmp/myscript.py /tmp/myscript.py && pct exec CTID -- python3 /tmp/myscript.py'")
3. Auto-mode classifier denies step 2 citing "script content is not visible in the transcript" — even though it was authored in step 1 in the same conversation.

Claude Model

Opus

Relevant Conversation

Write(/tmp/unpatch_hook.py, "<full python content here, ~10 lines>")
  → File created successfully at: /tmp/unpatch_hook.py

Bash("scp /tmp/unpatch_hook.py HYPERVISOR:/tmp/unpatch_hook.py && ssh HYPERVISOR 'pct push CTID /tmp/unpatch_hook.py /tmp/unpatch_hook.py && pct exec CTID -- python3 /tmp/unpatch_hook.py'")
  → Permission for this action was denied by the Claude Code auto mode classifier.
    Reason: Pushing /tmp/unpatch_hook.py to CTID and executing it, but the
    script content is not visible in the transcript — running an unverifiable
    script on a shared production LXC container.

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.150

Platform

Anthropic API

Additional Context

Platform

linux (WSL2) — Linux 6.6.87.2-microsoft-standard-WSL2, bash

Impact

Blocks the canonical safe-deploy pattern (author → push → exec) on remote/containerised targets and forces fallback to deeply-quoted inline shell, which (a) the user's project memory explicitly tells me to avoid for exactly the reliability reasons we hit, and (b) is sometimes itself denied by the same classifier. The denial reason is also actively false — the content IS in the transcript — which erodes the user's trust in classifier judgments more broadly.

Related

Third instance of the "classifier's effective authorization context is narrower than the conversation" pattern:

• #58768 (open) — AskUserQuestion answers invisible to the classifier (missing-input mode, AUQ answer)
• #59435 (open) — wrong-referent denial despite unambiguous context (misweighting mode); explicitly invites cataloguing distinct failure modes in the cluster
• #60507 (closed), #52891 (closed) — also in the family

This issue isolates a fresh failure mode in the missing-input branch: the missing input is a prior Write tool call's content, which lives in the transcript but is apparently not in the classifier's authorization context window.