Desktop keeps running silently when it cannot save session cards — no user-visible warning (3,862 failures only in main.log)

Summary

When the desktop app cannot write session cards to its storage folder, it keeps running normally and gives the user no indication at all. The failures are logged only to main.log. From the user's side the app looks healthy — chats open, work proceeds — but new conversations silently never get a sidebar entry, and after switching accounts or restarting, they appear to be "lost".

In my case the app logged 3,862 consecutive Failed to save session errors across three days while showing zero warnings in the UI.

Environment

• Claude Desktop 1.30096.5 (behaviour first observed on 1.26832)
• Windows 11 Pro 26200
• Claude Code CLI 2.1.229

What the log shows

[error] Failed to save session local_<uuid>: Refusing non-directory at private dir path
(symlink/file plant): C:\Users\<user>\AppData\Roaming\Claude\claude-code-sessions\<account>\<org>
    at er (...) -> ensureStorageDir -> writeSnapshotToDisk

Counts by day in my logs: 1,290 / 2,572 / 92 — then zero once the storage path was made writable again.

Impact

• Conversations started while persistence is broken never appear in the sidebar. Their transcripts under ~/.claude/projects/ are written correctly, so no data is actually lost — but the user has no way to know that, and reasonably concludes the chats are gone.
• Recovery is only possible by reading main.log and reconstructing the card→transcript mapping from the Mapping internal session local_X to CLI session Y and updateSession: sessionId=local_X, options={"title":...} lines. That is not a reasonable expectation for a normal user.
• The window can last days, because nothing ever surfaces the problem.

Note on cause vs. symptom

The cause in my case was self-inflicted: a junction had been placed at the account/organization storage folder, and the app's anti-tamper check (correctly) refused to write into it. I am not asking for that check to be relaxed — it is doing the right thing.

Release 1.28929.0 fixed a different cause with the same symptom ("some Windows installs (MSIX packages and enterprise-managed roaming profiles) failing to save chat history, settings, and scheduled tasks"). That suggests the symptom is reachable through several paths — which is exactly why the silence, rather than any one cause, is the thing worth fixing.

Requested behaviour

1. After N consecutive session-save failures, show a persistent, user-visible warning (banner or tray/notification), naming the path that cannot be written.
2. Do not present the session list as authoritative while persistence is known to be failing.
3. Ideally expose the condition somewhere scriptable (status file or exit code), so an external health check can catch it.

Why this matters

A crash is noticed in seconds. An operation that silently does nothing and reports success can live for weeks. Here it cost several days of confusion and a manual reconstruction from log files, for a problem the app already knew about 3,862 times.