[BUG] Cowork: Global instructions silently revert to older version after saving

[kerrypak-claude]

Preflight Checklist

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

What's Wrong?

Cowork global instructions silently revert to an older version after being saved through the Claude Desktop settings UI.

When editing global instructions via Settings → Cowork → Edit Global Instructions → Save, the new instructions appear to save successfully. However, within minutes they silently revert to an older version — typically the version that was active when an existing Cowork session was started.

This has been reproduced 20+ times over 2 weeks with consistent behavior. The save always appears to succeed in the UI, but the instructions always revert.

Mechanism (traced to root cause)

This is the Cowork-specific manifestation of the .claude.json stale-write race condition documented in #27941 (now closed as stale). The root cause, confirmed via deobfuscated source analysis in that issue:

1. Global instructions are stored in ~/.claude.json alongside internal app state (tipsHistory, cachedStatsigGates, OAuth tokens, migration flags, etc.)
2. Each active Cowork session holds an in-memory copy of the config at session start time
3. Claude Desktop writes to .claude.json continuously during normal operation for internal state updates
4. Each write follows a read-modify-write cycle using the session's stale in-memory copy
5. The saveConfigWithLock function detects external modification (mtime/size change from the user's save) and logs tengu_config_stale_write telemetry — but does not abort the write
6. The fallback path uses a 1-second in-memory cache, further ensuring fresh disk changes are lost

Result: Any active Cowork session writing any internal state back to .claude.json silently overwrites the user's freshly saved global instructions with its stale copy. Old sessions don't need to be doing anything visible — even background state writes trigger the overwrite.

What Should Happen?

Saving global instructions via the UI should persist reliably regardless of how many Cowork sessions are active. The save should never be silently reverted.

Why This Is Not a Duplicate

• [BUG] Config file (.claude.json) silently reverts user changes — stale write detection logs telemetry but does not prevent overwrite #27941 (closed as stale) — Scoped to Claude Code CLI and .claude.json broadly, focused on MCP server env vars. This issue is specifically about the Cowork Desktop UI for global instructions, which is a different user surface and a different team's domain.
• [BUG] Race condition when multiple VS Code windows write to ~/.claude.json simultaneously #20637 — Race condition between multiple VS Code windows. This issue requires only a single Cowork session to reproduce.
• "Enable Remote Control for all sessions" resets to false despite persisted config #29929 — "Enable Remote Control" config resetting. Same root cause but different config key. This issue affects the most user-facing setting in Cowork (global instructions).

Error Messages/Logs

No error messages are displayed — the save appears to succeed. The revert is completely silent. The only trace is the tengu_config_stale_write telemetry event logged internally, which is invisible to the user.

Steps to Reproduce

1. Open Claude Desktop → Cowork tab
2. Start a Cowork session (or have one already running)
3. Go to Settings → Cowork → Edit Global Instructions
4. Make a visible change to the instructions text
5. Click Save
6. Wait 1–5 minutes (or start a new Cowork session)
7. Return to Settings → Cowork → Global Instructions
8. Result: Instructions have reverted to the version that was active when the existing session started

More reliably reproduced when multiple Cowork threads/sessions exist, as each holds its own stale copy.

Suggested Fix

Short-term: When tengu_config_stale_write is detected, re-read from disk and merge (or at minimum abort the write) instead of overwriting.

Long-term (as proposed in #27941 and #30329): Separate internal state (~/.claude/state.json) from user-editable config (~/.claude/config.json) so internal writes can never touch user settings.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

Latest Claude Desktop (March 2026)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

N/A (Cowork Desktop UI)

Additional Information

Impact: This bug makes Cowork's global instructions feature effectively unusable for power users who maintain detailed instruction sets. The only reliable workaround is to put all instructions in a CLAUDE.md file in the mounted folder, which bypasses .claude.json entirely.

Related issues: #27941, #20637, #24578, #29929, #30329, PR #29077 (unmerged community fix for the race condition)

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] .claude.json race condition — reported 8 times since June 2025, all closed without resolution #28922
2. Windows: ~/.claude.json corruption from concurrent sessions (race condition in config writes) #29113
3. Race condition: .claude.json corruption when running multiple instances concurrently #28847

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[kerrypak-claude]

This is not a duplicate of any of the three referenced issues. Here's why:

#28922 — .claude.json race condition from concurrent Claude Code CLI sessions causing JSON corruption (truncated/invalid JSON). My issue is not about file corruption. The JSON stays valid — the content silently reverts. Different failure mode, different user surface (Cowork Desktop UI, not CLI).

#29113 — Windows-specific .claude.json corruption from concurrent CLI sessions, traced to writeFileAtomic fallback on NTFS. Again: file corruption from concurrent CLI writes on Windows. My issue is macOS, Cowork Desktop, and the file never corrupts — it silently reverts user-edited global instructions to a stale in-memory copy.

#28847 — Another concurrent CLI instance corruption report (5+ terminals, truncated JSON, backup file spam). Same pattern as above — JSON parse errors from partial writes. Not what's happening here.

The distinction matters:

	Referenced issues (#28922, #29113, #28847)	This issue (#40175)
Surface	Claude Code CLI (terminal)	Cowork Desktop UI (Settings → Global Instructions)
Failure mode	JSON file corruption (truncated, parse errors)	Silent content reversion (valid JSON, wrong values)
Root cause	Non-atomic writes / missing file locks	saveConfigWithLock detects stale write but doesn't abort — overwrites with stale in-memory copy
Trigger	Multiple concurrent CLI sessions	A single Cowork session writing internal state after user saves instructions via UI
Platform	Primarily Windows (NTFS rename failures)	macOS
User impact	Visible error messages + recovery prompts	Completely silent — user discovers reversion only by checking settings later

The root cause is specifically documented in #27941: the tengu_config_stale_write telemetry fires on external modification detection but does not prevent the overwrite. This is a logic bug in the stale-write handler, not a file-locking or atomic-write issue.

This issue affects the most user-facing configuration in Cowork (global instructions) and has no error message, no recovery path, and no user visibility. Please keep it open.

[kerrypak-claude]

Temp workaround: hash-based sweep for stale global instructions

The bug: each Cowork session caches your global instructions at launch. When a session writes state back to disk, it can silently overwrite your saved edits with its stale copy.

Where the files live

Find your session tree root:

find ~/Library/Application\ Support/Claude/local-agent-mode-sessions \
  -path "*/memory/CLAUDE.md" -type f 2>/dev/null | head -1

Strip /memory/CLAUDE.md from the result — that's <BASE>. Inside it:

• <BASE>/memory/CLAUDE.md — master copy (new sessions read from here)
• <BASE>/local_<session-id>/.claude/CLAUDE.md — per-session caches (can go stale)

The fix

1. Keep a backup of your global instructions outside the session tree.
2. Hash-compare every local_*/.claude/CLAUDE.md against memory/CLAUDE.md. Overwrite mismatches from the master.
3. If the master itself got overwritten (newer mtime, older content), restore from your backup first.

Also check for stragglers

• <BASE>/spaces/ — shouldn't contain any CLAUDE.md, but monitor it
• CLAUDE.md files outside the known <org-id>/<account-id>/ tree (other orgs/accounts on the same machine)
• Case variants (claude.md) and backup artifacts (.md.bak, .md.old)
• ~/.claude.json — verify no globalInstructions or userInstructions keys leaked in

Gotcha: don't trust mtime — the stale write-back sets a fresh timestamp when it overwrites. Hash comparison is the only reliable detection method.

I automated this as a Cowork skill that runs the full sweep on command. Happy to share if useful.

[phillmorgan28]

Also experiencing this issue. After interacting with an session with a previous global instruction, the setting is reset.

[ed-ovando]

This is a real problem I have a skill that specifically update the cowork instructions and this is pulling back to a version from two weeks ago. It is 4/14 and it is pulling from 4/2 that's two weeks of wasted learning that arent even being loaded . I only work from cowork now. Not being able to know how cowork is processing is a real problem for such a simple caching issue . which shouldn't even be prevalent these are critical files that instruct coworkers how to work - seem like this is a high priority and definitely erodes trust. It is also recently introduced and I dont know why a cache would overwrite a defined setting . Now I have to ask cowork from what timestamp it is processing from and adding to the rest of the instructions this is really bad and I only found it because I dumped a timestamp seems like the code can look at timestamps as well. Also you dont instruct on what files what would be read into cowork and in what order so I dont know what file I can write to disk as a workaround. Also the change in behavior is apparent and costing me tokens to fix things that I had already fixed and spending hours on Claude fixing something a simple top loaded instruction set would fix and had been working

If you are going to have thing write an instruction manual for how to use Claude cowork because everything I have seen just tells to prompt Claude and that is broken