Desktop "Instructions for Claude" silently does not apply to Claude Code sessions — the text is never written to disk, so CC cannot read it

What happened

I wrote a ~2,500-character development SOP into Settings → General → "Claude 지침" / Instructions for Claude — code-preservation rules, a debugging report format, a secrets policy, and a mandate to consult a local docs directory. I assumed it governed my Claude Code work, because that is the only free-text instruction field in the Settings window and the same window has a Claude Code section a few rows below it.

It never applied to a single Claude Code session. I only found out weeks later, by accident, while auditing why those rules were not being followed.

Verification

Three independent checks, all negative:

1. Not in the session's instructions. A running Claude Code session receives ~/.claude/CLAUDE.md and the memory index. The Settings-field text is not among them.
2. Not anywhere on local disk. Byte-scanned the Desktop app's Electron stores — IndexedDB, Local Storage, Session Storage, WebStorage — for a distinctive phrase from the SOP, in both UTF-8 and UTF-16LE: 0 hits. The field is account-side state, not synced to a local file.
3. Not in any Claude Code config. ~/.claude/CLAUDE.md, ~/.claude/settings.json, ~/.claude.json, project CLAUDE.md: 0 hits.

So Claude Code could not read it even in principle — it does not exist on this machine.

Why this is worth fixing even if it is working as designed

The field's helper text does say "chat and Cowork", so the scope may well be intentional. The problem is that nothing about the placement communicates that, and the failure mode is silent in both directions:

• The user believes a set of engineering rules is in force. It is not. There is no warning, no badge, no diff.
• The longer and more code-specific the text, the more confident the user is that it applies to coding — and the more wrong they are.
• In my case the SOP had drifted: it contained a rule ("always output the complete source of any modified file") that would have been actively harmful in an agentic editor, and another that directly contradicted my CLAUDE.md. Because the field was inert, I got neither the benefit of the good rules nor the early failure that would have exposed the bad ones. A silent no-op hides its own staleness.

I suspect this is common. The field is the most discoverable place in the product to write instructions; CLAUDE.md requires knowing it exists.

Related but distinct

• #88354 — "Personal instructions should have one source of truth across local and cloud sessions." Same disease, different symptom, and the closest neighbour to this report. That issue argues from the documented carry-over table that ~/.claude/CLAUDE.md never reaches cloud sessions; this one is the measured case of the other gap — an account-side field that never reaches Claude Code at all. Its proposed fix #2 (a personal-instructions field in settings that loads in every Claude Code session) describes precisely the field discussed here, which today already exists and is inert. If maintainers prefer, this can be folded into #88354 as evidence rather than tracked separately.
• #88315 — GUI settings not reaching live sessions. Mine never reaches Claude Code at all, including in a session started fresh afterwards.
• #83061 — chat-authored rules leaking into Claude Code. This is the opposite direction: rules failing to arrive.
• #47885 (closed) — user-level custom instructions for claude.ai/code web sessions.

Suggested fixes, cheapest first

1. Label the scope in the UI. One line under the field: "Applies to chat and Cowork. For Claude Code, use CLAUDE.md." with a link. This alone would have saved me the entire misunderstanding.
2. Nudge on the common mistake. If the text is long and code-oriented (file paths, "do not delete code", build/deploy rules), surface a hint offering to copy it into ~/.claude/CLAUDE.md.
3. Make effective instructions inspectable from a session — a /status-style view listing which instruction sources are actually in force, and from where. This is the shared ask with #88315 and would make the whole class of problem self-diagnosing.
4. Or apply the field to Claude Code as a user-level layer, below CLAUDE.md in precedence. Higher effort, and arguably the wrong layering, but it is the behavior many users already assume.

Environment

• Claude Desktop, Microsoft Store / MSIX Claude_1.34493.1.0, engine 2.1.234
• Windows 11 Pro 26200
• Working language: Korean (field label renders as "Claude 지침")

Scale

I cannot prove how often this bites other people, and I am not going to pretend the number below is a measurement of this bug. But the shape of the tracker is suggestive: searches return roughly 761 issues about instructions not being followed, ~206 naming CLAUDE.md specifically, and ~51 about which instruction source takes precedence.

A silent no-op of this kind does not get reported as "my instructions were never delivered." It gets reported as "Claude ignores my rules." I filed this separately from #88354 mainly so that someone searching the second phrasing can find the mechanism behind it.