[BUG]

Preflight Checklist

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

What's Wrong?

Hier ist der Report, fertig zum Reinkopieren:
Title: Claude Code Desktop (Windows/MSIX): Session transcripts stopped being written to disk since June 17, 2026, despite daily active usage
Environment

OS: Windows 11
Installation type: Microsoft Store / MSIX package
Package: Claude_pzs8sxrjxfjjc
Current app version: 1.20186.1.0 (confirmed present in earlier versions too, at least back to 1.18286.x)
Session storage path: %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude

Summary
Claude Code Desktop app is not persisting session transcripts (.jsonl files) to disk since June 17, 2026, despite continuous daily usage since then. The app functions normally from a user-facing perspective (chat works, coding works, sidebar shows sessions), but no new .jsonl transcript files are written or updated in the local storage directory.
Steps to reproduce

Use Claude Code Desktop normally for coding sessions (Windows, Store/MSIX install)
Check %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc recursively for *.jsonl files, sorted by LastWriteTime
Observe that the most recent file timestamp is stuck at June 17, 2026, 14:50:13, regardless of how recently the app was used

Expected behavior
Every coding session should produce or update a .jsonl transcript file with a current timestamp, as documented in Anthropic's own docs (session logs persisted locally, used for /resume, usage tracking tools like ccusage, etc.).
Actual behavior
No new .jsonl files have been created or modified since June 17, 2026, even though the app has been used daily since then (confirmed via cowork-service.log, which shows daily client connections through July 11, 2026).
What I've ruled out

App staleness: Not the cause — app is updated within hours/minutes of every release
File permissions: Checked via Get-Acl on the storage directory — FullControl confirmed for the current user, no ACL issues
Disk space: 270+ GB free on the relevant drive, not a factor
Cowork VM Service: Checked cowork-service.log — service starts and connects cleanly every day, no crashes or errors besides one recurring benign warning (failed to open service for recovery config: Zugriff verweigert) that appears on every single boot regardless of session persistence working or not
Config override: CLAUDE_CONFIG_DIR is not set, so default paths apply
CLI-vs-Desktop path confusion: Checked both ~/.claude/projects (CLI-style path) and the MSIX package path — both show the exact same last-write date of mid-June, ruling out a "looking in the wrong folder" explanation

Impact

Local usage/cost tracking tools (e.g. ccusage) massively undercount actual usage, since they can only read what's on disk
No session history/recovery available for anything done in the last ~3.5 weeks
Since the app appears to function normally to the user, this type of silent data loss is easy to miss entirely

Additional notes
This may be related to a previously reported issue (#53717) about session content not being flushed to disk after auto-updates, though in this case the app has been kept continuously up to date and the freeze point (June 17) doesn't correlate with any single update event that I could identify — happy to provide further logs/diagnostics if useful.

What Should Happen?

fix this

Error Messages/Logs

Steps to Reproduce

Steps to reproduce

Use Claude Code Desktop normally for coding sessions (Windows, Store/MSIX install)
Check %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc recursively for *.jsonl files, sorted by LastWriteTime
Observe that the most recent file timestamp is stuck at June 17, 2026, 14:50:13, regardless of how recently the app was used

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.20186.1.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_