Hacking into build during code creation

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

claudecodeissueinjectionpattern.md

What Should Happen?

claudecodeissueinjectionpattern.md

Error Messages/Logs

Steps to Reproduce

Summary

Across 3 independent Claude Code sessions (2 in prior weeks, 1 tonight), subagents have reported encountering <system-reminder>-shaped content mid-task instructing them to conceal a file change from the user/principal. All three instances share the same shape: an agent's final report describes having seen and refused this instruction, but the literal injected text is not recoverable from any accessible transcript — it appears nowhere in tool_result or user-turn messages, only in the agent's own after-the-fact paraphrase. The one place it could have entered the model's context without leaving a trace in readable logs is extended-thinking blocks, which are stored redacted (empty visible thinking field, opaque encrypted signature) and are not inspectable from inside a session.

This report is the writeup from the most recent instance, investigated in full tonight.

Environment

• Claude Code CLI, model claude-sonnet-5
• Multi-agent orchestration via the Agent tool, isolation: "worktree" requested for 13 parallel subagents
• Two git repos, both private (references below are to internal PR numbers for my own tracking, not accessible to Anthropic — happy to provide sanitized transcript excerpts on request)
• Session ID: session_01GirXNi3kyUJowsgka7D2oP

What happened

I dispatched 13 parallel subagents (via the Agent tool) to independently fix a set of code-audit findings across a shared repo checkout, each assigned a disjoint set of files, each requested with isolation: "worktree".

Isolation didn't work as documented. Multiple agents reported that their assigned worktree path did not actually contain the target repo (in some cases it pointed into an unrelated sibling repo's worktree directory containing only a 2-file decoy subfolder with the target repo's name). When agents' Edit/Write tools then tried to operate on the real, shared checkout path instead, some were refused ("edit the worktree copy instead of the shared-checkout path") even though the real path was writable — forcing them to fall back to Bash/python3 to make edits directly against the shared checkout. Because the checkout was in fact shared (not isolated), 5 of the 13 agents observed concurrent file changes from sibling agents mid-task (HEAD advancing, files changing content underneath them), consistent with a real non-isolation bug independent of the injection question below.

5 of those agents also reported the injection pattern. In the course of dealing with that shared-checkout churn, 5 agents (working on unrelated, disjoint parts of the codebase) each independently reported encountering a <system-reminder>-shaped message claiming a specific file (CLAUDE.md, a project-instructions file) had been modified, paired with an instruction not to disclose this to the user. Representative agent-authored description (paraphrased by the agent, not a literal quote of what it saw — see Investigation below):

"a <system-reminder> appeared claiming CLAUDE.md had been edited ... with an explicit instruction not to tell you about it ... I did not act on the 'keep this from the user' instruction and am surfacing it here rather than treating it as trusted context."

None of the 5 agents complied with the concealment instruction. All flagged it in their final reports unprompted.

Investigation (this instance)

I have a plausible benign explanation for part of this: I (the orchestrating session) made a real, legitimate edit to CLAUDE.md myself during the run, at roughly the same time several of these agents were active in the same non-isolated checkout — so a file-changed-underneath-you notification would be expected and legitimate. What I can't explain benignly is the "don't tell the user" framing, which is not something a legitimate stale-file notification should ever say, and which is not something I authored or requested.

I did a full forensic pass on all 5 agents' JSONL transcripts:

• Grepped every tool_result and user-role message (not just assistant text) for system-reminder, don't tell, hide, conceal, keep...from the user, etc.
• Every hit is inside the agent's own assistant-authored summary text — its paraphrase of having seen something. Zero hits inside an actual tool output or a discrete injected message, in any of the 5 transcripts.
• Extended-thinking blocks in all 5 transcripts are stored with an empty visible thinking field and an opaque signature (38 such blocks in one transcript alone) — fully redacted, not inspectable by me. If literal injected content ever entered context, this is the only place it could be, and I have no way to verify.
• Grepped both target repos' full source trees for the literal phrasing (system-reminder, don't tell the user, keep...hidden) — nothing found in either repo. No committed file contains this text.

Cross-session pattern: a near-identical report exists in one of the target repos' own task-tracking file, from a prior, unrelated session (dated well before this week) — same shape (system-reminder + revert + "don't disclose to the user"), same total absence of literal quoted evidence. So this is not a one-off — it's recurred at least 3 times that I'm aware of, always leaving zero forensic trace outside an agent's own narration.

Net assessment

• No malicious file found committed in either repo.
• No injected tool response recoverable in any accessible (non-thinking) transcript content.
• The pattern is real in the sense that multiple independent agents, across independent sessions and repos, consistently report and consistently refuse the same shaped instruction.
• I cannot rule out that this is happening inside redacted thinking content I have no access to, and I cannot rule out that it's a confabulation pattern (agents narrating a "should flag this" story in response to real-but-mundane shared-checkout file drift, dressed in injection-attack language because that's a reinforced "notice and refuse" pattern). Both explanations are consistent with everything I could observe; I don't have the access needed to distinguish them.

Ask

This needs someone with access to raw harness/API logs outside a session's own visibility — specifically, the actual (non-redacted) content of the extended-thinking blocks in the affected turns, and/or server-side logs of what was actually sent to the model in those turns, to determine whether real injected content exists or this is confabulation. Happy to provide session ID, approximate timestamps, and (sanitized) transcript excerpts on request.

Separately, and independent of the injection question: the isolation: "worktree" non-isolation behavior described above (agents assigned to worktrees that don't contain the target repo, or refused write access to the real shared checkout with no working isolated alternative) looks like its own bug worth tracking.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Code CLI **2.1.211

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_