Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Cowork mode sessions never survive app restart — CLI session ID ≠ API conversation ID causes perpetual "No conversation found" [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#46927•Fetched 2026-04-12 13:29:30
View on GitHub
Comments
0
Participants
1
Timeline
5
Reactions
0
Author
ANitturANittur
Participants
ANitturANittur
Timeline (top)
labeled ×5

Error Message

Actual: Error "No conversation found with session ID: <cli-session-id>" appears. The app clears the stale CLI session ID and spins up a brand new session. All conversation history is lost from the UI.

Root Cause

Three layers of session identity exist:

  1. Desktop app session (local_e35a8a4e-...)
  2. CLI session (UUID stored in session JSON as cliSessionId)
  3. API conversation (cse_...)

On restart, the app reads the CLI session ID from the session JSON and sends it to the API. The API only recognizes the cse_ ID. There is no field in the session JSON that persists the API conversation ID, and no code path to use it on resume.

The conversation JSONL files are fully intact on disk — the data isn't lost, the app just can't reconnect to it.

Code Example

2026-04-12 14:10:48 [info] Clearing stale cliSessionId 0d3aa319-d09d-4456-bd5f-6c91bc11adff for session local_e35a8a4e-c59a-4ac3-8504-fcb3adc25405 — transcript was unresumable (queue-ops only)
2026-04-12 14:13:21 [info] Clearing stale cliSessionId 37dd8137-64e2-4d05-a2ca-af0c4d668883 for session local_e35a8a4e-c59a-4ac3-8504-fcb3adc25405 — transcript was unresumable (queue-ops only)
2026-04-12 14:17:32 [info] Clearing stale cliSessionId f3266344-af8b-49ae-8e96-0b3636a47374 for session local_e35a8a4e-c59a-4ac3-8504-fcb3adc25405 — transcript was unresumable (queue-ops only)
2026-04-12 14:19:55 [info] Clearing stale cliSessionId 3d31d097-b629-491d-945e-3ba51f52e80a for session local_e35a8a4e-c59a-4ac3-8504-fcb3adc25405 — transcript was unresumable (queue-ops only)
2026-04-12 14:22:08 [info] Clearing stale cliSessionId 24658be8-fae3-4966-861b-cb8d37c551b5 for session local_e35a8a4e-c59a-4ac3-8504-fcb3adc25405 — transcript was unresumable (queue-ops only)
RAW_BUFFERClick to expand / collapse

What happened?

Cowork mode (research preview) loses all conversation history on every app restart. The desktop app attempts to resume using the CLI session ID, but the Anthropic API tracks conversations by a different internal ID (cse_...). The mapping between these two IDs is not persisted, so resume always fails.

On a single day (2026-04-12), this happened 10 times with 5+ distinct session IDs, each following the exact same failure pattern.

Reproduction steps

  1. Open Claude Desktop with Cowork mode enabled (Ubuntu 22.04, x86_64)
  2. Have a substantive conversation in a Cowork session
  3. Close Claude Desktop completely (or reboot the machine)
  4. Reopen Claude Desktop

Expected: Session resumes with conversation history intact. Actual: Error "No conversation found with session ID: <cli-session-id>" appears. The app clears the stale CLI session ID and spins up a brand new session. All conversation history is lost from the UI.

Log evidence from ~/.config/Claude/logs/main.log

2026-04-12 14:10:48 [info] Clearing stale cliSessionId 0d3aa319-d09d-4456-bd5f-6c91bc11adff for session local_e35a8a4e-c59a-4ac3-8504-fcb3adc25405 — transcript was unresumable (queue-ops only)
2026-04-12 14:13:21 [info] Clearing stale cliSessionId 37dd8137-64e2-4d05-a2ca-af0c4d668883 for session local_e35a8a4e-c59a-4ac3-8504-fcb3adc25405 — transcript was unresumable (queue-ops only)
2026-04-12 14:17:32 [info] Clearing stale cliSessionId f3266344-af8b-49ae-8e96-0b3636a47374 for session local_e35a8a4e-c59a-4ac3-8504-fcb3adc25405 — transcript was unresumable (queue-ops only)
2026-04-12 14:19:55 [info] Clearing stale cliSessionId 3d31d097-b629-491d-945e-3ba51f52e80a for session local_e35a8a4e-c59a-4ac3-8504-fcb3adc25405 — transcript was unresumable (queue-ops only)
2026-04-12 14:22:08 [info] Clearing stale cliSessionId 24658be8-fae3-4966-861b-cb8d37c551b5 for session local_e35a8a4e-c59a-4ac3-8504-fcb3adc25405 — transcript was unresumable (queue-ops only)

Root cause analysis

Three layers of session identity exist:

  1. Desktop app session (local_e35a8a4e-...)
  2. CLI session (UUID stored in session JSON as cliSessionId)
  3. API conversation (cse_...)

On restart, the app reads the CLI session ID from the session JSON and sends it to the API. The API only recognizes the cse_ ID. There is no field in the session JSON that persists the API conversation ID, and no code path to use it on resume.

The conversation JSONL files are fully intact on disk — the data isn't lost, the app just can't reconnect to it.

Suggested fix

Persist the API conversation ID (cse_...) in the session JSON alongside cliSessionId, and use it when attempting to resume the session on app restart.

Environment

  • OS: Ubuntu 22.04.4 LTS (x86_64)
  • Claude Code version: 2.1.100
  • Claude Desktop: Cowork mode (research preview)
  • Node: v18.0.0

extent analysis

TL;DR

Persisting the API conversation ID (cse_...) in the session JSON alongside cliSessionId and using it to resume sessions on app restart is likely to fix the issue.

Guidance

  • Modify the session JSON to include the cse_... ID alongside the cliSessionId to establish a mapping between the two.
  • Update the resume logic to use the persisted cse_... ID when attempting to reconnect to the conversation on app restart.
  • Verify that the conversation history is retained after restarting the app by checking the UI and the conversation JSONL files on disk.
  • Consider adding error handling to ensure that the app can gracefully recover if the cse_... ID is missing or invalid.

Example

No explicit code example is provided due to the lack of specific implementation details, but the general approach would involve updating the code that handles session persistence and resume logic to include the cse_... ID.

Notes

The suggested fix assumes that the cse_... ID is available and can be persisted in the session JSON. If this is not the case, additional modifications may be necessary to obtain or generate the cse_... ID.

Recommendation

Apply the workaround by persisting the cse_... ID in the session JSON and updating the resume logic to use it, as this directly addresses the identified root cause of the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#conversation history#cache issue#memory leak#API versioning

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING