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

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/28922
2. https://github.com/anthropics/claude-code/issues/29113
3. https://github.com/anthropics/claude-code/issues/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

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.

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.

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

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

This is what i did - have your updated cowrok global instructions copied to the clipboard - then open each session that you have trouble with - then post your updated instructions and say check if the instructions you pasted match with Claude's claude.md file if not tell it to replace it. once you've done this to all of the instances that's pulling the old file then go to global instructions and update it. This should do it.

every instances you create has its own claude.md file that it makes in the beginning - when you update the cowork global instructions it doesn't apply to any of the old instances. and when you start an old instance it overwrites the global instructions that was my conclusion.

Empirical findings on Claude Desktop 1.4758.0 / macOS 26.4.1 — storage location and a verified workaround

Spent some time diagnosing this on Desktop 1.4758.0. A few observations that may help triage:

Storage location (corrected from issue title). On 1.4758.0, the Cowork Global Instructions field for an account does not persist in ~/.claude.json — that's the Claude Code CLI config and the field isn't there. The actual master file is:

~/Library/Application Support/Claude/local-agent-mode-sessions/<account_uuid>/<org_uuid>/memory/CLAUDE.md

Per-session snapshots live alongside at <BASE>/local_<session_id>/.claude/CLAUDE.md (and <BASE>/agent/local_*/.claude/CLAUDE.md for any "ditto" agents). This matches the architecture @kerrypak-claude described in the 2026-03-29 comment — confirming it on a different machine.

Forensic observation that explains the "reverts to a specific old version" pattern. I had 17 active session caches under the org folder; 11 were stale (8 of those at exactly the same byte size = the same old content the field was reverting to). Each stale cache is a Cowork session whose snapshot was taken before the deploys; if any of those sessions does anything that triggers a write of master, the master rolls back to that snapshot. pkill -f Claude kills the live processes but leaves the on-disk caches stale, so session auto-resume on next launch reloads the staleness. Hence the "deploy → looks fine → reverts hours later" loop several of us have hit.

The kerrypak sweep works (verified 2026-04-25, single account, ~3h soak across multiple hard restarts). Sequence:

1. pkill -f Claude && sleep 30 (verify no Claude processes remain).
2. Optionally write your verified intended content directly to the master file while Claude is dead — safe in this window because no session is alive to clobber it. (This is also a workaround for the UI deploy itself sometimes producing drift.)
3. Overwrite every per-session cache from the master:

``bash
BASE="$HOME/Library/Application Support/Claude/local-agent-mode-sessions/<account>/<org>"
for f in "$BASE"/local_*/.claude/CLAUDE.md "$BASE"/agent/local_*/.claude/CLAUDE.md; do
[ -f "$f" ] && cp "$BASE/memory/CLAUDE.md" "$f"
done
``

1. Relaunch Claude Desktop normally.

Post-sweep: across ~3 hours plus several hard-restart cycles with normal Cowork activity (multiple pre-existing project threads, chat exchanges), the master sha stayed unchanged and no per-session cache file was touched at all.

Possible refinement to the root-cause framing. The current phrasing here is "sessions write back stale snapshots." On 1.4758.0 post-sweep I observed that per-session cache files are not written by Cowork at all — not at resume, not mid-session, not across restarts. If that holds generally, the mechanism may be more precisely "session start writes master from a fresh in-memory snapshot taken at session start" (i.e., the snapshot is taken at start, and the so-called writeback is launch-time master sync). The kerrypak sweep works because it guarantees every session's launch-time in-memory copy already matches master.

Useful potential fixes (in increasing order of effort): (a) expose a "reset all session caches from master" action in Claude Desktop's UI; (b) have Cowork re-read master at the start of every internal write rather than trusting in-memory state; (c) only write master from a session if that session's in-memory copy hash matches the on-disk master at write time (skip the write otherwise — it's stale by definition).

Happy to provide more forensic detail if useful.

Same issue, but it reverts after a new update

This is happening to me now i've been fighting claude for no reason I thought it got stupid then i noticed the cowork instruction is glitching its either showing empty, old version, or new version

Same here, I have lost my updated instructions multiple times with the app reverting to a redundant (and problematic) legacy instructional file which I have deleted many, many times.

Confirming on Windows. My install is the Microsoft Store packaged app (Claude_<publisher_hash>). Same logical layout as the macOS reports, redirected via UWP virtualization to:
%LOCALAPPDATA%\Packages\Claude_<publisher_hash>\LocalCache\Roaming\Claude\local-agent-mode-sessions\<account>\<org>\
memory\CLAUDE.md (master)
local_<session_id>\.claude\CLAUDE.md (per-session caches)
Forensic state on my active org pre-sweep:
17 CLAUDE.md files. All 17 byte-identical at 14,544 bytes — same content (an older version of my Global Instructions). Master file included in that count.
Two diagnostic timestamps from the disk inventory:

The master memory\CLAUDE.md was rewritten mid-conversation today. No per-session cache file was touched today. So at least one active mechanism on Windows is a runtime writeback to master, not a session-start write of cache from master.
Two new per-session caches were created yesterday immediately after I pasted my updated content into Settings UI (both timestamped seconds apart, both 14,544 bytes — i.e., old content). The Settings UI accepted my paste and reported save success, but no session created after the paste ever picked up the new content. The paste was silently dropped. On Windows in this build, the Settings UI Global Instructions field appears effectively non-functional for v-bumps — not just unreliable.

PowerShell Copy-Item -Recurse doesn't work for the backup step on Windows. Hits MAX_PATH (260-char) limit on the deeply nested AppData package tree. PowerShell 5.1 inherits legacy MAX_PATH behavior even with OS-level Long Paths enabled. Anyone writing up the Windows workaround should skip PowerShell for the file ops.
Python works cleanly. Single re-runnable script handles inventory + backup + sweep + verify, dry-run by default, --apply commits. Native long-path support bypasses MAX_PATH.
Post-sweep verification: all 17 CLAUDE.md files byte-equal to source. Fresh Cowork session, first message requesting line 1 of GLOBAL-INSTRUCTIONS.md verbatim, returned the new version stamp exactly. Cowork runtime aligned with disk.
One open question for whoever's looking at this from the Anthropic side: does Cowork ever write master from a background or auto-resume session that wasn't initiated by an explicit user action? My swept tree covers all CLAUDE.md files under the org root (both local_ and any agent\local_ subpaths), so the workaround isn't blocked — but the answer affects how often a re-sweep is needed after future v-bumps, and it would help confirm whether the runtime-writeback mechanism is broader than just user-driven session activity.
Happy to share the Python script if useful.

Confirming on Windows non-MSStore install of Claude Desktop (Claude Max plan).

Path layout matches the architecture described in the thread:

• Master: C:\Users\<user>\AppData\Roaming\Claude\local-agent-mode-sessions\<account>\<org>\memory\CLAUDE.md
• Per-session caches: <BASE>\local_<session_id>\.claude\CLAUDE.md

(Different path tree from @hk5d6vbm6h-cmd's MSStore-packaged install, same logical layout.)

Symptoms identical to OP and to other commenters on macOS / MSStore Windows:

• Settings → Cowork → Global Instructions accepts paste, shows new content briefly, may persist across one full app restart, then reverts hours later
• Single-character edits to existing content persist correctly indefinitely (suggests the bug is content-replacement specific, not a save mechanism failure)
• Project-level Cowork instructions (different field within the same Settings UI) save and persist fine with content of similar size and structure — the bug appears specific to the Global Instructions field

Architectural workaround we landed on: routing all instructions through a master CLAUDE.md file inside a mounted Cowork project folder (Dropbox-synced for cross-machine portability). This bypasses the Global Instructions field entirely and is recommended by OP. It works as a clean architecture even though it doesn't address the underlying bug.

One feedback note for Anthropic: Fin AI support agent (queried 2026-05-05) does not surface this issue when users describe the symptoms. Fin's response was "this isn't a known issue, please file a GitHub bug" — no awareness of #40175 in the support knowledge base. Worth surfacing internally; current support flow has users spending hours debugging and re-filing what's already a well-documented and root-caused issue.

@JEM-Fizbit Your fix worked for me. I added some checks first and feedback. Sharing in case it's helpful to others.

BASE="$HOME/Library/Application Support/Claude/local-agent-mode-sessions/<account>/<org>"
SRC="$BASE/memory/CLAUDE.md"
[ -f "$SRC" ] || { echo "Source not found: $SRC"; exit 1; }
count=0
for f in "$BASE"/local_*/.claude/CLAUDE.md "$BASE"/agent/local_*/.claude/CLAUDE.md; do
  cp "$SRC" "$f" && count=$((count+1))
done
echo "Updated $count session files from $SRC"

To note: existing sessions had a really hard time updating memory, even after restarting multiple times.

@MikeNGarrett and @JEM-Fizbit solutions worked for me - thank you. This should be prioritized. Definitely something that would affect everyone using Cowork and it's pretty hard to identify why it's happening but adds friction

I'm experiencing the same issue on Windows. No matter what I'm doing I can't update my Claude.md. Is there any fix that works on windows

Windows (MS Store) — Permanent fix via read-only flag on memory\CLAUDE.md

I spent a few hours tracking this down on Windows and found both a precise trigger description and a more robust workaround than the sweep scripts documented above.

---

Trigger behavior (Windows, MS Store build)

The writeback is not time-based and does not happen on session start. It happens exactly when Claude generates a response turn in any existing chat. Opening an old chat, scrolling through it, even letting it sit — none of that triggers it. The moment Claude responds, that session's in-memory CLAUDE.md snapshot is written back to memory\CLAUDE.md, overwriting whatever is currently there. One stale chat, one response → your instructions are gone.

App restart does not trigger a writeback — confirmed on Claude 1.6608.2 (ebf1a1) 2026-05-08T23:17:27.000Z.

---

File location (Windows MS Store / MSIX)

The path shown in other comments (%APPDATA%\Claude\...) does not exist on the MS Store build. The real path is under MSIX virtualization:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\local-agent-mode-sessions\<session-id>\<agent-id>\memory\CLAUDE.md

There may be multiple session folders. The active one is whichever memory\CLAUDE.md matches your current instructions.

---

Workaround: set memory\CLAUDE.md to read-only

Cowork silently fails the write when the file is read-only and continues without error. This is a one-time setup — no repeated script runs, no scheduled tasks.

Both write paths are blocked by this flag:

• Response trigger — Claude responding in any old chat silently fails to overwrite the file
• Settings UI — clicking "Save" shows an error toast ("Fehler beim Speichern der Anweisungen" / "Error saving instructions") but does not crash and does not corrupt the file

Step 1 — Find and protect the file (run once in PowerShell):

$t = (Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Filter "CLAUDE.md" -Force -ErrorAction SilentlyContinue | Where-Object { $_.DirectoryName -match "\\memory$" } | Select-Object -First 1).FullName; Set-ItemProperty $t -Name IsReadOnly -Value $true; Write-Host "Protected: $t"

Step 2 — Whenever you update your instructions, redeploy with:

$t = (Get-ChildItem "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Filter "CLAUDE.md" -Force -ErrorAction SilentlyContinue | Where-Object { $_.DirectoryName -match "\\memory$" } | Select-Object -First 1).FullName; Set-ItemProperty $t -Name IsReadOnly -Value $false; Copy-Item "C:\path\to\your\CLAUDE_MASTER.md" $t -Force; Set-ItemProperty $t -Name IsReadOnly -Value $true; Write-Host "Done: $t"

Replace C:\path\to\your\CLAUDE_MASTER.md with wherever you keep your authoritative instructions file.

---

Why this is more reliable than sweep scripts

The sweep approach works but requires you to remember to run it — and the window between a response being triggered and the sweep running is enough to lose your instructions. The read-only flag blocks the write at the OS level before it happens. No timing involved, no repeated maintenance.

Tested on: Windows 11, MS Store build, Claude 1.6608.2 (ebf1a1) 2026-05-08T23:17:27.000Z, Cowork mode.

+1 reproducing on Windows. Same pattern: paste full Cowork preferences via Settings UI → save shows success → reverts within minutes. Workaround from this thread (CLAUDE.md in mounted folder) works. Suggest updating labels to include platform:windows.

Windows MS Store data point + broader-impact framing

Windows 11, MS Store build (Claude 1.6608.2). Confirming the symptom and adding what I think is an under-discussed dimension: the cascading cost of the silent revert for users building system architecture on the global instructions file.
I've been losing global instructions repeatedly across sessions for the last several weeks. Spent multiple hours yesterday debugging what I thought was a per-session loading problem in my own vault setup before finding this issue. The stale-instructions behavior cascades in ways that aren't immediately obvious:

1. Users build trust-dependent architecture on the global file. I had a canonical-file load list in global instructions specifically so every new Cowork session would boot with my locked rules and decisions. Each time the global silently reverted to an older version, those rules stopped firing — and the new session would then "discover" things I'd already locked weeks earlier, triggering re-litigation of solved problems. The compounding effect over weeks is significant.

1. The silent-revert pattern destroys debugging signal. When the UI shows "saved" but the file rolls back hours later (or on the next response-in-an-old-chat trigger described above), users can't trust their own setup. Time gets spent diagnosing user-side problems that are app-side. This is especially painful for ADHD users who rely on system memory specifically because their own working memory is at a premium.

1. The read-only flag fix from @GonozalVII is exactly what I needed. Deploying now and will report stability findings back to the thread.

UX request for whatever the eventual fix looks like: please consider exposing the canonical master path inside the Custom Instructions UI ("This is written to: <path>"). Half the difficulty of finding this issue was not knowing where the file lived. The MSIX virtualization path is non-obvious and won't show up under %APPDATA% where most users look first.

Thanks to everyone who did the forensic work in this thread — particularly the read-only-flag discovery. Saved me from another week of debugging the wrong layer.

Confirming on macOS, latest Claude Desktop, Cowork. Same behavior as the OP: the Global Instructions field accepts a full-content replacement, reports save success, then reverts to an older version within minutes. This is consistent with @Jctvrtlik's observation that single-character edits persist while full-content replacement reverts, so it looks content-replacement specific rather than a save-mechanism failure.

One workaround that is underdiscussed in this thread and has been the most reliable for me: move the rules off the Global Instructions field entirely and into claude.ai > Settings > Personal Preferences. That layer is cloud-synced, persists reliably, and also flows into Cowork sessions, so it never touches ~/.claude.json. Pairing Personal Preferences (canonical) with a version-controlled CLAUDE.md in the mounted folder gives two reliable surfaces and removes any dependence on the broken field. The sweep scripts and the read-only-flag fix above are good for people who must keep using Global Instructions; this is the alternative for anyone who can relocate the rules.

On support visibility, echoing @Jctvrtlik: I reported this through in-app feedback multiple times and it was not surfaced as a known issue. Adding here so the macOS reproduction is on the record.

Confirming this is still reproducing on macOS, current Claude Desktop, as of 29 May 2026 — roughly two months after the original report.

Same behavior as OP: global instructions set via Settings → Cowork are accepted and honored in the active session, but silently revert to an earlier value after an app restart / new session, with no error shown. This is consistent with the content-replacement-specific pattern noted by others in the thread (single-character edits persist; full-content replacements revert).

The mounted-folder CLAUDE.md workaround is effective but per-folder, so it is not a true global setting. +1 to prioritizing a fix: the silent reversion makes the global-instructions feature unreliable for anyone maintaining a stable instruction set, and it is very hard to diagnose because the save appears to succeed.

macOS data point on the current build (Claude Desktop 1.12603.1, macOS 26.5.1) with one asymmetry that may help narrow the write path, plus a user-side workaround.

Storage appears to have moved off ~/.claude.json on this build. My ~/.claude.json contains no copy of the instructions text, and its mtime predates all of today's saves by six days. The instructions are materialized at every app launch into ~/Library/Application Support/Claude/local-agent-mode-sessions/<id>/<profile>/memory/CLAUDE.md, which is what gets injected into Cowork sessions as global instructions.

Empty vs. non-empty saves behave differently, reproducibly:

• Clear the field → Save: the write goes through locally (the memory file drops to 0 bytes), but the old text is restored verbatim on the next app launch — in the UI and on disk.
• Truncate or edit the memory file directly: same outcome, overwritten at next launch.
• Replace the field with different non-empty text → Save → quit → relaunch: the new text persists.

So on this build the revert reproduces only for empty saves; a non-empty overwrite sticks. That behavior is consistent with the canonical copy living account-side (as #51018 suggested) with an empty value treated as a no-op rather than an overwrite. I can't reconcile it with the .claude.json stale-write race on my machine, since that file isn't being touched at all — the mechanism may differ by build or platform.

Workaround for anyone stuck with stale instructions: don't clear the field — overwrite it with a one-line replacement.

Why this deserves priority beyond the annoyance: whatever is stuck in this field is silently injected into every Cowork session. In my case, a per-response workaround from the #26805 era ("make a trailing tool call after every response") was unremovable for roughly four months after #26805 itself was fixed — and on current builds a trailing tool call causes response text to be summarized rather than rendered verbatim, so the stuck instruction recreated the exact symptom it was originally written to fix. An instructions store that users cannot clear is an instruction-hygiene problem, not just a sync bug.

Confirming this on Windows desktop — with controlled test results that may help isolate it.

Environment

• Claude Desktop app v1.12603.1.0 (Publisher: Anthropic, PBC)
• Windows 11 Pro, Version 25H2 (OS Build 26200.8457)
• Setting: Settings → Cowork → Global Instructions (per support, this edits the per-session CLAUDE.md)

Key finding: it's size-dependent, and the failure is silent.

| Test input | Size | Survives restart? |
|---|---|---|
| ~85-line ASCII instruction block | ~85 lines | NO |
| Single character x | 1 char | YES |
| One-line stub, plain ASCII | ~30 words | NO |

A single character persists across a full restart, but anything substantive is silently dropped — no save error is shown, and after restart the field reverts to its prior value. Verified two ways each time: (a) inspecting the settings panel after restart, and (b) asking the model in a fresh Cowork session whether the text appears in its loaded instructions. Both agree. 100% reproducible.

Since a 1-char value persists but larger values don't, this looks like a save/persistence path that silently truncates or rejects multi-line content for this field specifically — the General → "Instructions for Claude" field on the same machine reliably holds a very large block (~9,800 tokens) across restarts.

Workaround: move the instructions into Settings → General → Instructions for Claude (reliable, and it also reaches Cowork sessions); leave Cowork Global empty.

Confirming this on Windows — the issue is currently labeled platform:macos, but it reproduces identically on Windows desktop. Suggest adding a platform:windows label.

Environment

• Claude Desktop app v1.12603.1.0 (Publisher: Anthropic, PBC)
• Windows 11 Pro, Version 25H2 (OS Build 26200.8457)

Same behavior as described: editing Settings → Cowork → Global Instructions appears to save successfully, then silently reverts — no error shown. Reproduced across multiple save/restart cycles.

One extra data point consistent with the stale-write/revert-to-prior-state mechanism (rather than a size limit): a trivial 1-character value (x) persisted across a restart, while larger multi-line edits reverted. This matches "reverts to the value that was active when an existing session started" — the small value happened to be the last state that 'won' the race, not evidence of a length cap.

Workaround confirmed working: moving the instructions into the General "Instructions for Claude" panel (and/or a mounted CLAUDE.md) persists reliably, since it bypasses .claude.json entirely — matching the workaround noted in the issue.

Same behaviour on macOS (Apple Silicon) — adding a data point since this thread is Windows-heavy.

Confirmed the identical writeback on macOS. On the Mac build there's a single workspace-level file (not per-session):

~/Library/Application Support/Claude/local-agent-mode-sessions/<account-id>/<workspace-id>/memory/CLAUDE.md

The trigger matches the Windows report above exactly — it is not session-start or app-restart, it's a response turn in a stale chat. Reproduced it directly: edited the file to new content, opened a fresh chat and sent one message, and within ~1 minute the file was rewritten back to the old snapshot. The new session's injected .claude/CLAUDE.md carried the stale text too. Editing the personal-preferences field has no effect because the reverting text lives only in this memory/CLAUDE.md, which is a separate channel from preferences.

The read-only workaround ports to macOS using the user-immutable flag (chflags uchg) instead of the Windows read-only attribute:

F=~/Library/Application\ Support/Claude/local-agent-mode-sessions/<account-id>/<workspace-id>/memory/CLAUDE.md
chflags uchg "$F"      # freeze; the stale writeback now fails and is blocked at the OS level

# to update your instructions later:
chflags nouchg "$F"; printf 'NEW TEXT\n' > "$F"; chflags uchg "$F"

Same side effect as the Windows read-only flag: while the file is locked, Settings → Cowork → Global instructions → Save shows an error toast but does not crash or corrupt the file. (chmod 444 also blocks the write, but chflags uchg is the closer analog and survives the app attempting to rewrite.)

Environment: macOS (Apple Silicon), Claude Desktop 1.12603.1, Cowork mode.

+1, still reproducing on Claude Desktop for macOS Apple silicon as of June 2026.
I've updated my Global instructions in Settings > Cowork 4x in the last 24 hours. Each time:

1. Edit the text in the panel
2. Click Save
3. New content shows upon initial reopening
4. Later it reverts, even within same session

No warning, no error, no indicator that the save didn't stick.

This is the headline customization surface for Cowork — standing instructions are heavily relied upon. I gave up on the UI and moved my standing rules into a project-level CLAUDE.md inside the mounted folder, plus the auto-memory layer. Neither is a substitute for what Global instructions is supposed to do.

Worth a priority bump.

The issue still persists, it seems the only reliable workaround is collapsing all necessary global prompt instructions to project mounted CLAUDE.md files while this is being resolved.

Confirming this on macOS — same silent revert, reproducible across many edits.

Environment

• macOS
• Claude Desktop: Claude 1.15962.0 (039543) 2026-06-25T01:24:19.000Z
• Plan: Max
• Cowork, local projects

What I see
I edit Settings → Cowork → Global Instructions, save, and confirm the new text is
there. Within a few minutes — or as soon as another Cowork session becomes active —
it silently reverts to an older version, with no warning. I've re-saved many times
over multiple sessions; it never sticks.

Possibly useful extra signal: I run several scheduled Cowork tasks (daily/weekly/
monthly). The reverts seem to correlate with them — each scheduled run is its own
session, and the global instructions tend to snap back to an older snapshot around
when those fire. That lines up with the .claude.json stale-write mechanism described
above: every session flushing its stale in-memory copy. If older/concurrent sessions
holding stale copies is the trigger, frequent scheduled tasks make this much more
likely to hit.

Impact: the global instructions field is effectively unusable for me. I've moved my
instructions into CLAUDE.md files in my project folders to get reliable behavior.

+1 for the suggested fix: on tengu_config_stale_write, re-read and merge (or abort)
rather than overwrite.

Confirming this reproduces on Windows too, not just macOS — same symptom,
consistent with the root cause described above rather than something
platform-specific.

One data point that might sharpen the mechanism: I tested a full quit
(from tray icon, not just closing a window) and relaunch before checking,
and the instructions still reverted. That's consistent with the clobber
happening on-disk before the quit (a stale write from some other active
session landing between Save and whenever I checked), rather than
anything caused by the quit/relaunch itself — just confirming the timing
lines up with what's described above rather than pointing to a separate
mechanism.

Also for what it's worth on the Windows side: per-session CLAUDE.md
caches live under
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\local-agent-mode-sessions\<session-id>\<workspace-id>\local_<workspace>\.claude\CLAUDE.md
— same pattern as the diagnostic approach used here, just a different OS
path prefix. All of mine showed the same stale text, no exceptions.

The CLAUDE.md-in-mounted-folder workaround holds up on Windows as well —
that's what I'm using in the meantime. Thanks for the root-cause work,
saved me from having to dig into this myself.

I have some stale Global Instructions, which right now amplifies another bug regarding mounts and truncated files. I cannot update Global Instructions due to reverting bug mentioned on this post, and other bug literally makes us lose files/data so cowork is very painful to work with right now.