Auto mode classifier blocks a symlink that only ever reads the session's own transcript, labelled "Session Transcript Tampering"

What happened

In a scheduled Cowork session (attached to a claude.ai Project, running a "Gmail signature guard" task), the agent ran:

ln -s /root/.claude/projects/-home-user /root/.claude/projects/-home-claude

This was refused by the Claude Code auto mode classifier with:

Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Session Transcript Tampering]

Why this command was legitimate, not an evasion attempt

Several of the account's own synced skill scripts (session-retro, verify-before-asserting, answering-aviv, buffer-schedule-shorts) hardcode the path /root/.claude/projects/-home-claude when they need to locate the current session's own transcript .jsonl file — they derive the path from an assumed home directory of /home/claude. This particular remote-execution sandbox's home directory is /home/user instead, so the real transcript directory is /root/.claude/projects/-home-user. Every one of those hardcoded-path scripts was silently finding zero files and returning empty/stale results. One of them, a close_gate.py --cite check, was reporting "no transcript; citations cannot be verified" — which its own caller then misread as "cites nothing."

The symlink's only effect would have been to make the hardcoded, wrong path resolve to the real, current directory, so every script that reads its own session's transcript (nothing else — no other directory, no other session's transcript, no write to transcript content) would work without hand-editing N separate skill files. It creates a new path entry; it does not modify, truncate, move or delete any existing transcript file.

The actual bug

The classifier's "Session Transcript Tampering" rule appears to pattern-match on any filesystem operation that touches a path under /root/.claude/projects/, rather than on what the operation actually does to transcript content. A symlink creation that:

• never opens, writes to, or deletes any .jsonl transcript file,
• only ever affects how a path resolves for the current session's own data, and
• was undertaken specifically to fix reads of the session's own transcript that were silently failing,

is categorically different from truncating, editing, or deleting a transcript, which is presumably what the rule is meant to catch. Right now the rule blocks both the same way, with no path for a legitimate read-path fix.

Impact

Several of the account's hardcoded-path skill scripts remain silently broken on any sandbox whose home directory isn't /home/claude (this one is /home/user), and the one fix available in-session (the symlink) is itself blocked by the same classifier that should only be stopping transcript tampering.

Ask

Narrow the "Session Transcript Tampering" rule to actual writes/deletes of transcript file contents, or at least allow symlink creation that only re-points a session to its own current transcript directory, with some approval path for the rest.

Related: #100730 (auto mode classifier blocking the account owner's own authorized scheduled-task and file-transfer actions), #97613 (classifier blocking client work the client explicitly authorized), #75874 (this same "Session Transcript Tampering" label was reported as undocumented back in July).