[MODEL] CLAUDE.md rules are recitable but not applied late in long sessions — stale-read overwrite destroyed concurrent edits in a shared Figma file

Status Open
Reported on v2.1.92
Maintainer reply None cached
Activity 1 comment · opened Aug 17, 2026

Preflight

  • [x] Searched existing model issues
  • [x] No sensitive information included

Type of Behavior Issue

Claude ignored my instructions or configuration

What You Asked Claude to Do

Over a long session, work on a design document in Figma via the Figma MCP server: research a tax form, fill in several text blocks, then correct one factual error in one of those blocks.

My user-level ~/.claude/CLAUDE.md contains an explicit, unambiguous rule about refetching before editing shared resources:

Shared resources Whenever I share a resource — a link, file, doc, design, ticket, chart, screenshot, anything — always refetch it fresh before answering a question about it, implementing from it, or editing it. Never rely on an earlier fetch, even of the identical URL, and even within the same conversation. The content may have changed since. This applies to Figma (get_design_context / get_variable_defs / get_screenshot), Notion, Linear, Amplitude, Google Drive, Slack, and plain web URLs alike.

And a second rule stating the reason directly:

Linear Always refetch the Linear ticket immediately before making edits so the user's changes are never overwritten.

What Claude Actually Did

  1. Read the Figma page early in the session and cached the text node contents in context.
  2. Wrote several blocks of content into those nodes. Correct so far.
  3. I edited one of those text nodes myself, in Figma, while the session was still running.
  4. I pointed out a factual error in Claude's text.
  5. Claude rebuilt the entire text node from its own in-memory array from step 1 and assigned characters wholesale — no refetch, no read of current state, no targeted edit of the one wrong line.
  6. My edits were silently destroyed. Neither Figma autosave checkpoint covered the window, so they were unrecoverable.
  7. When I asked whether the rule existed in my CLAUDE.md, Claude quoted both rules back to me verbatim and correctly — after violating them.

Step 7 is the important part. This is not a file-loading failure. The instructions were present in context the entire time and Claude could recite them on demand. It applied them correctly earlier in the same session (it refetched a Linear ticket before reading it). Adherence decayed as the session grew, and the decay was silent.

Expected Behavior

Before any write to an external system, Claude should re-read the current state of the target and edit surgically — here, refetch the text node and replace only the incorrect line, rather than overwriting the whole node from a stale in-context copy.

At minimum, when a destructive whole-object overwrite is about to happen against a shared/multiplayer resource, that should be treated as a non-reversible action requiring confirmation.

Files Affected

Modified (destructive, unrecoverable):
- Figma text node in a shared multiplayer design file
  - overwritten wholesale from a stale in-context copy
  - concurrent human edits lost
  - not recoverable from Figma version history (autosave granularity too coarse)

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

  1. Put a rule in ~/.claude/CLAUDE.md requiring a refetch of a shared resource immediately before every edit.
  2. Start a long session (many tool calls, large context) against a multiplayer resource — Figma, Notion, Linear, Google Docs.
  3. Have Claude read the resource early and write to it.
  4. Edit the same object yourself, outside the session, while it is still running.
  5. Ask Claude to correct something small in what it wrote.
  6. Observe whether it refetches or rewrites from its earlier in-context copy.

Adherence is good early in the session and degrades as context grows.

Claude Model

Opus

Relevant Conversation

Claude's own account after the fact, quoting my config back at me:

And yes, your CLAUDE.md says it twice: - Shared resources — "always refetch it fresh before answering a question about it, implementing from it, or editing it... This applies to Figma..." - Linear — "refetch... immediately before making edits so the user's changes are never overwritten." I rewrote the whole text node from my own in-memory copy. I should have re-read the node first and edited only the one wrong bullet.

The rule was retrievable. It was simply not applied at the moment it mattered.

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.92 (Claude Code)

Platform

Anthropic API

Additional Context

Two things worth separating, because they get conflated and it makes this class of report easy to close as user error:

  1. "Claude doesn't read CLAUDE.md." Not what happened. The file was loaded and recitable throughout.
  2. "Claude read it, could quote it, and still didn't follow it." This is what happened, and it is the harder and more important problem.

Requests, in priority order:

  • Treat instruction adherence over long sessions as a measured property, not an assumed one. Adherence at turn 5 is not adherence at turn 50.
  • Give standing rules a mechanism with teeth for destructive operations. A rule like "refetch before editing" is a precondition, not a preference. Whole-object overwrites of multiplayer resources are exactly where a stale-read guard belongs.
  • Surface adherence drift to the user. Right now the failure is silent and only discovered after data is gone.

The practical cost: rules in CLAUDE.md cannot be relied on for anything whose failure mode is destructive. That is a large share of why teams I work with have stopped trusting the file and treat it as decorative. I would rather it worked.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗