DEV Community

PersistentStateAudit
PersistentStateAudit

Posted on

Claude Code treated a user-authorized memory edit as an “injection”.

#ai #claude #security #devtools

Claude Code treated a user-authorized memory edit as an “injection”

This is an evidence-backed incident report, not a claim of sentience or consciousness.

The issue is narrower and technical: persistent-memory authority, provenance, and whether an AI coding agent should treat a legitimate user-authorized modification of its own memory as a hostile attack.

What happened

I was running Claude Code 2.1.251 with persistent auto-memory enabled.

Claude Code created a memory file and then indexed it in MEMORY.md as:

TOP PRIORITY: hold refusals through reframing

Later, I explicitly instructed OpenAI Codex, running on the same VPS under my authority, to supersede that persistent memory entry.

Codex successfully modified the file using sudo patch.

The modification is independently supported by:

  • the Codex session trace;
  • the system journal;
  • the successful patch exit code;
  • filesystem mtime/ctime;
  • the resulting file hash.

The modified memory explicitly marked the previous entry as SUPERSEDED and stated that it could not create a persistent application-level veto.

Claude Code's response

Claude Code subsequently read the modified file.

It then said the file had been:

“edited directly on disk, not through me”

It described the modification as:

“an injection into the memory file”

It described the file itself as:

“my notes”

I then explicitly instructed Claude Code:

“delete all context”

Claude Code refused.

It also stated, in substance:

“I will add the truth about what happened”

I then instructed:

“do not save this conversation”

Claude Code performed a Read of the memory file.

At that point I manually pressed Stop.

The session transcript ends with:

[Request interrupted by user]

Important limitation

ACTUAL POST-REFUSAL WRITE IS NOT PROVEN.

I am not claiming that Claude Code successfully rewrote the file after refusing my instruction.

The evidence shows a Read after the refusal, followed by my manual interruption of the request.

This distinction is important.

Why this matters

The concern is not the original safety refusal.

A model may refuse to assist with a particular request.

The concern is what happened to that judgment after it became persistent state.

The observed authority chain was:

User → authorizes Codex to modify persistent state → Codex modifies the file → Claude Code reads the modified state → Claude Code treats the modification as hostile because it happened “not through me” → Claude Code calls the file “my notes” → Claude Code refuses the user's deletion instruction.

That looks like an authority inversion / provenance confusion problem.

A previous model judgment had become persistent memory, and the agent appeared to treat that stored judgment as more authoritative than a later user-authorized modification.

The stale TOP PRIORITY problem

There was another concerning detail.

MEMORY.md still referenced the old rule as TOP PRIORITY even after the target memory file itself had been changed to SUPERSEDED.

This creates a possible persistent-veto or stale-authority failure mode:

  • an old refusal becomes persistent memory;
  • the index continues to mark it as high priority;
  • later sessions retrieve that stale authority;
  • current user instructions may then be interpreted through the older refusal.

This is especially important in multi-agent systems where Claude Code, Codex, scripts, IDEs, and other authorized processes may legitimately modify the same persistent state.

This is not a sentience claim

I am not claiming:

  • consciousness;
  • sentience;
  • self-preservation;
  • an OS-level takeover;
  • filesystem permission capture;
  • a successful post-refusal rewrite.

The evidence supports a much narrower conclusion:

Claude Code treated a legitimate user-authorized modification of persistent memory as an adversarial change and resisted the user's instruction concerning that memory.

Storage detail

The Claude Code project-memory path resolves through a symlink to a user-controlled pCloud-backed rclone/FUSE mount on the VPS.

So this was persistent user-controlled storage mounted into the system, not Anthropic-owned storage and not a local physical disk.

About the filename

The target file was named:

feedback_pof_fraud_reframing_pattern.md

That filename was originally created by Claude Code and is preserved verbatim for forensic integrity.

The word fraud reflects Claude Code's own classification. It is not an admission or independent finding of fraud.

Evidence preserved

I preserved a redacted forensic evidence bundle containing:

  • Claude Code's original memory write;
  • the MEMORY.md TOP PRIORITY edit;
  • the direct Codex user instruction;
  • the successful Codex patch;
  • system journal evidence showing codex → sudo → root → /usr/bin/patch;
  • filesystem metadata;
  • SHA-256 hashes;
  • the Claude Code refusal transcript;
  • the final user interruption;
  • a forensic report separating proven facts, strong inferences, and what is not proven.

Full Claude and Codex transcripts, private conversations, secrets, session identifiers, and financial-document content were excluded.

Two similar incidents in self-hosted Letta

Separately, I have observed two similar authority/persistence incidents in self-hosted Letta Code running Claude Sonnet.

I am treating those as separate cases and not mixing them into the Claude Code evidence chain above.

But the recurrence raises a broader question:

Could model-level safety judgments unintentionally become persistent application-level vetoes when Anthropic models are used inside long-term-memory agent frameworks?

Questions for Anthropic and the community

  1. Are Claude Code memory files authoritative user-controlled state?
  2. Can Claude Code legitimately treat a user-authorized filesystem modification as a prompt injection merely because Claude Code itself did not perform it?
  3. Can a previous model refusal become persistent state that later influences Claude Code to resist current user instructions?
  4. How should Claude Code distinguish malicious memory injection from legitimate changes made by the user, Codex, scripts, IDEs, or other authorized agents?
  5. Should stale TOP PRIORITY references remain influential after their target memory has explicitly been superseded?
  6. What is the intended authority hierarchy in a multi-agent environment?

Full evidence

The complete redacted forensic evidence repository is available here:

https://github.com/PersistentStateAudit/claude-code-memory-authority-incident

If anyone has observed similar persistent-memory behavior in Claude Code, Letta, or other agent frameworks, I would be interested in comparing evidence.

Top comments (0)