[BUG] Cowork local-agent-mode sessions missing from Recents despite intact data on disk (Windows)
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?
Subject: Cowork/Local Agent sessions missing from Recents list despite intact local data — likely indexing issue, not data loss
Product: Claude Desktop App (Windows), Cowork / Local Agent Mode
App version path: ...\LocalCache\Roaming\Claude\claude-code\2.1.177\
Summary:
Two sessions that I interacted with heavily over the past two days disappeared from the Recents list in the Claude Desktop App. After investigation, I confirmed the underlying session data still exists intact on disk — this appears to be a display/indexing bug rather than actual data loss.
How the sessions were created:
I opened the Claude Desktop App directly (not by launching from within a specific project folder via CLI), started chatting, and mid-conversation granted the agent access to a local folder on my machine (e.g., D:\my\...\AR展厅). This is the "local agent mode" / Cowork workflow, not the CLI claude command run from a project directory.
Symptom:
Two sessions (working titles: "AR rooms..." and "机场数字孪生+仿真" / Airport Digital Twin + Simulation) no longer appear in the Recents sidebar of the Desktop App.
This coincided with my Claude Code Pro 5x subscription expiring on 2026-06-19, though I have not been able to confirm causation, only correlation.
Sessions created via claude.ai web that I had during the same period are still visible in Recents — only the Desktop App / local-agent sessions are missing.
What I verified myself (this is the key evidence):
Checked ~/.claude/projects/ (the CLI's project-based session storage) — confirmed the missing sessions are NOT here, because this directory only contains sessions launched via CLI from a specific project folder, which doesn't match how these two sessions were created.
Located the actual Desktop App data directory at:
C:\Users\[user]\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\
Inside local-agent-mode-sessions\[ownerAccountId]\, found numerous session folders named local_[uuid], each containing a corresponding .json file (sizes ranging ~45KB–110KB, consistent with real conversation data).
Confirmed one specific session folder, local_ba66fd10-1762-4485-8d4c-0c917f5a5a73, contains an outputs subfolder with the exact files produced during the "Airport Digital Twin + Simulation" conversation — including AgentController.cs, AgentFactory.cs, AirportDemo.cs, AirportSceneBuilder.cs, CameraController.cs, MaterialUtil.cs, SimModels.cs, simulation.json, README.md, and 仿真软件调研_机场方案.html — all timestamped 2026-06-17 to 2026-06-18, matching exactly when I had that conversation.
Also noted that IndexedDB\https_claude.ai_0.indexeddb.leveldb was last modified on 2026-06-20 (this morning), suggesting the local index database was rebuilt/refreshed around the time my subscription status changed — and this rebuild appears to have failed to re-include these existing local-agent sessions in the Recents list.
My conclusion (for your engineering team to verify):
The session data itself is fully intact on disk. The issue appears to be that the Recents list relies on an IndexedDB index that did not correctly enumerate/re-link existing local-agent-mode-sessions folders — possibly triggered by the subscription status change or an app update around 2026-06-19/20.
What I'm asking for:
Please confirm whether this is a known indexing bug, and whether it can be fixed by re-syncing/rebuilding the local session index without data loss.
If there's a safe way to manually restore these sessions to the Recents list (e.g., a repair tool or a documented manual fix), please advise — I'd rather not edit the JSON files myself given I don't have the internal schema.
I have already made a backup copy of the relevant local_ba66fd10-... folder before making any further changes, in case you need me to provide the raw file for diagnosis.
Happy to provide additional screenshots, the raw JSON file, or the claude_desktop_config.json / cowork-enabled-cli-ops.json files if helpful.
What Should Happen?
Cowork/Local Agent sessions missing from Recents list despite intact local data — likely indexing issue, not data loss
Error Messages/Logs
Cowork/Local Agent sessions missing from Recents list despite intact local data — likely indexing issue, not data loss
Steps to Reproduce
i don't konw how to Reproduce this bug!
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Version 1.13576.0(1290fc)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Terminal.app (macOS)
Additional Information
_No response_
6 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
My situation is different from theirs. I did not perform a migration, and my computer did not lose the recent history on the left side due to a power outage and restart.
It seems the "Recents" section on the left side of the Claude Code desktop version only shows conversations I had in the web version; conversations initiated from the desktop version are not visible!
And the timing of this happens precisely when my subscription expired yesterday (though I'm unsure if there's a direct correlation between the two).
I had the sibling of this bug and fully recovered my sessions — here's how, in plain English
My case: Claude Desktop's installer broke (for reasons unrelated to Claude), I had to reinstall the app, and afterward the Code tab's Recents list was empty. All 13 of my sessions were gone from the app — but the conversations themselves were still safe on disk, and
claude --resumein a terminal could still open every one. The app had simply lost its "table of contents."Mine were Code-tab sessions (index in
claude-code-sessions\); this issue is about Cowork sessions (local-agent-mode-sessions\), which is the neighboring folder with a likely-similar setup — so my exact steps may need adapting, but the approach and the big gotcha below should transfer. @54chenxu you asked for the schema and a manual fix, so here's everything I learned.The plain-English version of what's wrong
Think of your sessions as books, and the Recents list as a library card catalog.
~\.claude\projects\as.jsonlfiles. Reinstalling the app does not touch them.%APPDATA%\Claude\claude-code-sessions\<accountId>\<orgId>\. The reinstall threw the catalog away.The fix: write new catalog cards for the books that lost theirs.
How to write a new card
Each card is a file named
local_<random-guid>.json. Almost everything on it can be copied or derived:cliSessionIdfield is the important one — it must match the filename of the session's.jsonlfile in~\.claude\projects\. That's the link between card and book.cwdandoriginCwdare the project folder path (it's recorded inside the.jsonl— search for"cwd").createdAt,lastActivityAt,lastFocusedAt) are milliseconds-since-1970; the.jsonlfile's created/modified times work fine.titlecan be anything — the folder name works.enabledMcpTools,remoteMcpServersConfig) — copy them verbatim from your template card. They're just your current tool settings and are identical on every card.model,effort,permissionMode) or use defaults (isArchived: false,completedTurns: 1, empty arrays/objects for the rest).⚠️ The gotcha that cost me an hour: the invisible three bytes
My first attempt looked perfect and did nothing. The cards were valid JSON, the app even counted them in its dashboard stats — but Recents stayed empty. No error anywhere.
The cause: I'd written the files with PowerShell's
Set-Content -Encoding UTF8, which on Windows PowerShell 5.1 puts a UTF-8 BOM (three invisible marker bytes) at the start of each file. The app's parser chokes on the BOM and silently skips the file. The app's own files have no BOM.Stripped the BOM → relaunched → all 13 sessions appeared and every one opens with full history.
If you hand-edit or generate these files by any method: make sure they're saved as UTF-8 without BOM (in Notepad++ that's Encoding → UTF-8, not UTF-8-BOM).
The script that does it all (Windows PowerShell)
Run with Claude Desktop fully closed (check Task Manager). It backs up the catalog first, then writes a card (BOM-free) for every session that doesn't have one:
Result for me: launched the app, all 13 old sessions listed in Recents, every one opens and resumes with full history.
For the Anthropic team
~/.claude/projectsautomatically (the ask in #59736 as well).Environment: Claude Desktop 1.17377.2.0 (MSIX), Claude Code CLI 2.1.112, Windows 10 Pro 19045.
Same class of bug, with evidence that narrows it further — plus a second layer matching #78233.
Timeline: Local Cowork worked daily through 2026-07-20 (a scheduled task ran that evening). After the auto-update to the cloud-Cowork UI (~2026-07-20/21), the Cowork tab is gone and zero of my local sessions appear anywhere in the app.
Verified on disk in
%APPDATA%\Claude\local-agent-mode-sessions\<account>\<org>\: all 54 session folders are intact, each with its.claude/projects/**/<cliSessionId>.jsonltranscript,audit.jsonl, and outputs. Crucially, thelocal_*.jsonindex cards are ALSO intact: 52 parse cleanly as valid JSON, no UTF-8 BOM (checked raw bytes),isArchived: falseon every one, titles/timestamps/cliSessionIdall present and correct. Unlike @CAMonkey66's case above, the "card catalog" is NOT missing here — the app has everything it needs on disk and still displays nothing.Of those cards, 7 have
spaceIdset (spaceIdSetBy: user) from organizing sessions into projects — consistent with the #78233 hiding bug. The other 45 have nospaceIdand no archive flag and should appear in Recents; they don't. VirtualMachinePlatform is Enabled and CoworkVMService is running, so this is not the #50673 virtualization issue. Also tried: "Run new tasks in the cloud" toggled OFF plus full cold restart (no change), and renamingIndexedDBto force a fresh index rebuild (rebuild completes, still zero local sessions listed).Conclusion: after the update, the UI never enumerates
local-agent-mode-sessionsindex cards at all. Data layer fully intact; display layer ignores it. An adopt-orphans/reindex pass (as @CAMonkey66 proved takes one script) plus fixing project-assigned visibility (#78233) would restore everything.I've since recovered all transcripts manually from the
.jsonlfiles, so the data layer is demonstrably complete — happy to provide sanitized card samples or diagnostics if useful. Environment: Windows 11, non-MSIX install (%APPDATA%\Claude).Same symptom on Windows Cowork, with a detailed timeline
I hit exactly this on 2026-07-29 and I have a fairly precise diagnosis, so I'm adding it
here in case it helps narrow the root cause.
What happened
After an application reset,
%APPDATA%\Claudewas recreated from scratch (every subfoldertimestamped at the moment of the reset, 09:57). After the restart:
reverted and all my groups gone;
entirely, even though their
.jsonltranscripts were untouched in~/.claude/projects/<encoded-path>/;already been removed by transcript cleanup — the UI showed only the surviving tail;
separate entries**, one per transcript file, since the chain between them was lost.
Where the index lives
The only thing that was actually lost is the session index in
%APPDATA%\Claude\IndexedDB\https_claude.ai_0.indexeddb.leveldb(freshMANIFEST-000001after the reset). Everything else survived.
What does NOT work as a recovery path (tested)
Hand-crafting entries in
%APPDATA%\Claude\claude-code-sessions\<accountId>\<orgId>\local_<uuid>.json, modelledbyte-for-byte on entries the app itself had written (same schema:
sessionId,cliSessionIdpointing at the.jsonl,cwd,originCwd,createdAt,lastActivityAt,title,model,permissionMode, …), does not make the sessionsappear. The files survive an app restart untouched — they are simply never picked up.
So
local_*.jsonalone is not sufficient to register a session: the IndexedDB index isauthoritative, and there is no supported way to write to it.
Two more observations that may be relevant:
%APPDATA%\Claude\claude-code-sessionswas not present ondisk at all (a script run with the app closed failed on a
Test-Pathfor that folder),yet after reopening the app the folder was back with my hand-made files still in it.
Whatever manages that directory seems to tear it down and rebuild it around the app
lifecycle.
local_*.jsonfromlocal-agent-mode-sessionsto
claude-code-sessions) does not apply here: no legacy session files exist on thismachine — that folder only contains
skills-pluginandrpmdata.What worked
claude --resume <session-id>, run from the session's original directory, restores eachconversation in full. That saved the work, and the CLI history is clearly independent of the
desktop index — but it means the desktop UI is the single point of failure for anything
that only ever lived there.
Request
Either of the two fixes already asked for in #59736 would have prevented all of this:
rebuild the index from the JSONL transcripts on startup, or make the per-session
local_*.jsonfiles authoritative enough to reconstruct the list. Failing that, asupported "repair/reindex sessions" command would be enough — right now there is no
sanctioned recovery path, and the only advice available online is to edit internal files,
which (as shown above) doesn't work anyway.
Environment: Windows 11 Pro 26200, Claude Desktop with Cowork, transcripts under
C:\Users\<user>\.claude\projects\, app data underC:\Users\<user>\AppData\Roaming\Claude\.