[BUG] Windows Desktop Code session opens blank, appears under wrong project after failed update followed by reinstall, although CLI can resume it

## Update: session recovered, but the underlying Desktop bug remains

I recovered the conversation after inspecting the transcript, Desktop session wrapper, and Desktop logs. 

### Root causes found

There were two related problems.

#### 1. Desktop associated the session with the wrong project

The transcript was correctly stored at:

`~/.claude/projects/C--Users-<user>-Prosculpt/<session-id>.jsonl`

Its records consistently identified the working directory as:

`C:\Users\<user>\Prosculpt`

However, Desktop’s corresponding `local_<session-id>.json` wrapper contained:

```json
"cwd": "C:\\Users\\<user>\\BoltzGen",
"originCwd": "C:\\Users\\<user>\\BoltzGen"

Desktop therefore displayed the conversation under BoltzGen. When it attempted to resume the session, it searched from that wrong project and logged:

No conversation found with session ID: <session-id>
clearStaleResumeHandle ... reason=cli_resume_not_found_result dropping cliSessionId=<session-id>

After cliSessionId was removed, Desktop displayed the conversation as empty or showed:

Session history unavailable This session’s conversation history is no longer on disk.

The transcript was actually still present under Prosculpt.

2. Desktop recovery/import fragmented the JSONL message graph

During recovery, Desktop logged:

Stripped thinking blocks from ...\<session-id>.jsonl
(844 lines, 114 empty-after-strip dropped)

The resulting JSONL was valid JSON, but the removed records were still referenced by later records through parentUuid.

Inspection found:

• 114 missing parent references
• Approximately 120 disconnected leaves/fragments
• No malformed JSON lines
• No duplicate UUIDs

This explains why claude --resume, /export, and /branch initially recovered only the final portion of the conversation even though the JSONL was approximately 1.5 MB.

The count is notable: Desktop reported dropping exactly 114 records, and the resulting file had exactly 114 missing parent references.

Recovery performed

The following workaround restored the session:

1. Fully quit Claude Desktop.
2. Back up the transcript and Desktop wrapper.
3. Create a separate transcript with a new session ID.
4. Reconnect each missing-parent record to the immediately preceding surviving UUID record.
5. Validate the repaired graph.

The repaired copy had:

• 0 missing parents
• 1 root
• A reachable main chain of 492 records
• 183 user records
• 241 assistant records

The repaired session then resumed with its full history in the CLI.

Using /desktop reproduced part of the bug: Desktop again assigned the imported session to BoltzGen, stripped five newer thinking-only records without reconnecting their children, failed to find the transcript from the wrong directory, and removed cliSessionId again.

The final successful workaround was:

1. Fully quit Desktop again.
2. Repair those five new missing links.
3. Change the Desktop wrapper’s cwd and originCwd to the correct Prosculpt directory.
4. Restore cliSessionId.
5. Reopen Desktop normally without running /desktop again.

The conversation now opens under Prosculpt with its complete visible history.

Suggested fix areas

It would be helpful if Desktop could:

1. Derive the project directory from the transcript’s stored cwd or actual JSONL location rather than the currently active Desktop project.
2. Search other known project directories before treating cliSessionId as stale.
3. Avoid modifying the user’s only transcript during import/recovery.
4. When removing thinking-only records, reconnect their children to the removed record’s surviving parent or retain a placeholder.
5. Validate that every non-null parentUuid exists before replacing the transcript.
6. Provide an in-app “repair/import existing transcript” workflow.
7. Avoid clearing cliSessionId when the first lookup may simply have used the wrong project directory.

This is recovered locally, but I am leaving the issue open because the workaround required manual repair of internal JSONL and Desktop metadata. The same corruption or project reassignment could affect other users or recur after another import/recovery.

I can provide sanitized wrapper files, graph-validation results, and relevant log excerpts privately.

The transcript is still on disk, so the immediate job is to reconnect Desktop to the original project rather than start a replacement session. I have seen this split when the Desktop wrapper carries one cwd/originCwd while the .jsonl lives under the slug for another project.

Run python tools/diagnose.py before trying Retry or Start fresh again. It compares the metadata files with ~/.claude/projects/ and prints the exact next command if the cliSessionId is missing, dangling, or attached to the wrong project slug. Use that command's dry-run first. Copy %APPDATA%\Claude\claude-code-sessions\ and ~\.claude\projects\ before any apply step, then fully quit Claude Desktop and verify claude.exe is gone before changing metadata.

I built BasedGPT/claude-code-session-recovery for this file-layer problem. The check that matters is whether the metadata file's cliSessionId resolves to the transcript file that contains the conversation. The reinstall may be the trigger, but the intact .jsonl and the successful CLI resume give you a concrete recovery path; avoid sending another message from the empty Desktop entry until the pointer is preserved.

Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)

I'm not a maintainer (Not sure I wish I would like to be), but I recently spent a while mapping where the Windows desktop
app keeps its session state, and your symptoms match something specific, so this may give you something concrete to check.

The app's session list is not built from the .jsonl transcripts. It reads a separate registry, one small JSON per session:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code-sessions\<account>\<device>\local_*.json

(%APPDATA%\Claude resolves to the same store — the app is MSIX, so its data is redirected under Packages\.)

Each record looks roughly like:

{"sessionId":"local_…","cliSessionId":"<the .jsonl UUID>","cwd":"C:\\Users\\…\\Prosculpt",
 "originCwd":"…","title":"…","isArchived":false}

Two things follow that fit your report:

• The project a session appears under comes from cwd in that record, not

from the transcript's location on disk. So a session can sit in the correct
C--Users-<user>-Prosculpt folder and still be displayed under a different
project if its record's cwd is wrong.

• <device> is machine-specific. An uninstall/reinstall — especially one

with an AppX error during removal, as you describe — is the kind of event that
could leave a second <device> folder, or records regenerated with the wrong
cwd. That would also explain why the CLI is unaffected: it never reads this
store.

Worth checking, all read-only:

$root = "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code-sessions"

# 1. More than one <device> folder? That alone would be telling.
Get-ChildItem $root -Recurse -Directory | Select-Object FullName

# 2. What each record claims about title / project / transcript
Get-ChildItem $root -Recurse -Filter 'local_*.json' | ForEach-Object {
    $j = Get-Content $_.FullName -Raw | ConvertFrom-Json
    [pscustomobject]@{ Title = $j.title; Cwd = $j.cwd; Cli = $j.cliSessionId; File = $_.Name }
} | Format-Table -AutoSize

# 3. For the blank one: does its cliSessionId actually exist on disk?
#    (an orphan record would render as an empty conversation)
Get-ChildItem "$env:USERPROFILE\.claude\projects" -Recurse -Filter '*.jsonl' |
    Select-Object -ExpandProperty BaseName

If the blank session's record points at a cliSessionId with no matching .jsonl, that is an orphaned index entry rather than lost data. And if the misplaced one has a cwd that does not match where it shows up, the index is what is wrong, not your transcripts — which is the better outcome, since the conversations are intact and resumable from the CLI meanwhile.

Close the app fully before changing anything there — it holds LevelDB locks while running.

This is a hypothesis from a different machine/case, not a diagnosis of yours; happy to be wrong. Verified against desktop app 1.37937.3.0.