Code Desktop sessions display in sidebar but content is permanently inaccessible — audit.jsonl never recoverable, sessiondata.img is encrypted "shdw" container
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?
Multiple Claude Code Desktop sessions display in the sidebar with correct metadata (title, completedTurns: 15, cwd, model) but the chat pane is empty when opened. The server URL https://claude.ai/epitaxy/local_<id> returns 404.
4 sessions affected on Claude Desktop 2.1.121 (macOS). All affected sessions share one trait: cwd inside ~/Google Drive/. Other sessions on the same machine (cwd in local-only paths) work correctly.
Sessions were openable and content was visible as recently as ~1 week before the failure was discovered. No user action triggered the loss.
Filesystem investigation:
- claude-code-sessions/.../local_<id>.json: metadata present, completedTurns: 15, no message content
- local-agent-mode-sessions/.../: sibling content folders exist for unaffected sessions (audit.jsonl + subagents) but DO NOT EXIST for the 4 affected sessions
- ~/.claude/projects/: no project folder for the affected cwd
- Cache/Cache_Data/: only analytics tracking pixels reference the session ID
- Local Storage/leveldb/ + IndexedDB: only UI state, no message content
- vm_bundles/claudevm.bundle/sessiondata.img (1.9 GB): magic bytes 7368 6477 ("shdw"), encrypted container, 0 readable hits via strings on session ID or project name
- Time Machine: backup did not run during the relevant window
The fix from #29373 (copy local_*.json from old to new directory) does not apply: metadata is already in the new location, but the content payload was never present in either location for these specific sessions.
This is unrecoverable engineering work — multiple weeks of architecture, code, and debugging context, lost without warning.
What Should Happen?
- Sessions visible in the sidebar must always have retrievable content. If the audit.jsonl payload is missing, the app should display an explicit error ("Session content is missing — please report") instead of silently rendering an empty chat that gives no indication data has been lost.
- Session creation on network or sync mounts (Google Drive, iCloud, Dropbox, etc.) should validate that the content file was successfully persisted before the session is added to the sidebar.
- A documented, user-accessible recovery path should exist when sessiondata.img contains content the UI cannot retrieve — or the storage architecture should be documented so users can back up their work themselves.
- Server-side backup of Code Desktop sessions should exist for paid plans, OR the strictly local-only nature of session storage must be explicitly stated in the product so users understand they are solely responsible for backups.
- Document and test the interaction between Code Desktop session storage and synced cloud-drive cwd paths.
Error Messages/Logs
UI message when opening the affected session:
"Cette session est introuvable. Elle a peut-être été supprimée, ou vous n'avez peut-être pas accès."
("This session cannot be found. It may have been deleted, or you may not have access.")
This message is misleading — the session was not deleted by the user, and the metadata file proves it existed and had 15 completed turns.
Server response for https://claude.ai/epitaxy/local_25a89396-994d-4fe2-9085-5afd40f1f04a:
HTTP 404
Console log excerpt (from `log show --predicate 'process == "Claude"' --last 30d`):
2026-04-28 16:29:20 Claude DiskImages2 Image file stat: size(10737418240) [rootfs.img]
2026-04-28 16:29:20 Claude DiskImages2 Not a sparseimage / Not a UDIF, assuming RAW format
2026-04-28 16:29:20 Claude DiskImages2 user data retrieving failed: User data is not supported in this image format (err code 45)
2026-05-01 16:49:49 Claude DiskImages2 same inode (669322835) reopened, size unchanged
No errors related to the missing session content are surfaced to the user at any point.
sessiondata.img header dump (xxd, first 32 bytes):
00000000: 7368 6477 0000 0001 0000 0200 0000 0000 shdw............
00000010: 0000 0000 0000 0200 0000 0000 0004 1400 ................
`strings sessiondata.img | grep -i atmosphear` → 0 hits
`strings sessiondata.img | grep 25a89396` → 0 hits
Steps to Reproduce
Cannot reproduce on demand — the failure was discovered after the fact. The following conditions correlate with the failure across the 4 affected sessions:
- Create a Claude Code Desktop session with cwd inside a Google Drive File Stream mount (~/Google Drive/...)
- Use the session over multiple weeks across one or more desktop version updates (specifically across the local-agent-mode-sessions → claude-code-sessions storage migration)
- At some point — without any user action and without any error message — the session opens to an empty chat pane while still showing correct metadata in the sidebar
Sessions on the same machine with cwd in local-only paths (~/Documents, ~/code, etc.) are not affected.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unknown — sessions opened correctly approximately 1 week before failure was discovered. Affected sessions were used across multiple desktop versions during the local-agent-mode-sessions → claude-code-sessions storage migration.
Claude Code Version
Claude Code via Claude Desktop integrated extension (no separate CLI installed). Desktop app version: 2.1.121
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
This issue is filed against Claude Code via Claude Desktop integrated extension (not the standalone CLI).
Affected: 4 sessions, all with cwd inside ~/Google Drive/. Other sessions on the same machine with local-only cwd paths are unaffected.
Session IDs available privately on request.
Related but distinct from #29373: the documented fix (copying local_*.json from local-agent-mode-sessions/ to claude-code-sessions/) does not apply because the metadata files are already in the new location, but the corresponding audit.jsonl content payload is missing from BOTH locations for these specific sessions.
sessiondata.img (1.9 GB) at ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle/sessiondata.img has magic bytes 7368 6477 ("shdw") and appears to be an encrypted container. Strings extraction returns 0 hits on session IDs and project names — content cannot be recovered locally.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗