[BUG] Cowork local mode: resume is passed a session ID that never existed — the session file is intact on disk (Linux, 1.30096.1)

Note: see the follow-up comment below for app-log evidence — cliSessionId, transcript was unresumable (queue-ops only), and a fresh wrong ID minted every turn.

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?

Filing this as a new issue because #57109 (same symptom, Windows 11) is closed as duplicate and locked, and the related reports #36842, #36865 and #33912 are all closed as well. This one is not a "me too": it contains a root-cause trace that I have not seen in any of them — the session is persisted correctly, and the app writes the failure back into that same session file, but the ID it passes to resume belongs to no session at all.

Environment

• Claude desktop app 1.30096.1 (from the errorVersion field written into the session file)
• Linux x86_64, /home on eCryptfs
• Cowork task in local mode ("On your computer"). Cloud mode is unaffected.

Reproduction

100% reproducible, on the second message of any local Cowork task:

1. Start a Cowork task in local mode on any folder.
2. Message 1 — works normally.
3. Message 2 — fails immediately with:

No conversation found with session ID: fc9d5e70-3f89-4dce-ba44-d47277a4b4df

The app then clears the ID and starts a fresh session, so context is lost on every single turn, which makes local Cowork unusable.

Where local session state actually lives

~/.config/Claude/local-agent-mode-sessions/<workspace-uuid>/<conversation-uuid>/local_<session-uuid>.json

Not in ~/.claude/projects/, which only holds Claude Code sessions. Anyone diagnosing this who looks there will wrongly conclude that Cowork transcripts are never written. They are.

The session file of the failing run

352 KB, written during the failed run, containing the full turn-1 exchange. Its header:

{
  "sessionId": "local_47f668f2-236f-46f4-934e-54387e544be9",
  "cwd": ".../local-agent-mode-sessions/87e02f0b-.../5a7018d3-.../local_47f668f2-.../outputs",
  "createdAt": 1786792648779,
  "lastActivityAt": 1786792769176,
  "model": "claude-opus-5",
  "title": "Session configuration check",
  "hostLoopMode": true,
  "error": "No conversation found with session ID: fc9d5e70-3f89-4dce-ba44-d47277a4b4df",
  "errorCategory": "session_not_found",
  "errorAt": 1786792769189,
  "errorVersion": "1.30096.1",
  "initialMessage": "<my second message>"
}

Timeline (from the timestamps in that file)

| UTC | Event |
|---|---|
| 11:17:28 | createdAt — session local_47f668f2… created (turn 1) |
| 11:18:02 | the agent writes a file in my working folder — turn 1 completes normally |
| 11:19:29 | errorAt — turn 2 fails, session_not_found |

So local_47f668f2… is the turn-1 session: created at turn 1, active through turn 1, and still the file the app writes to when turn 2 fails.

The mismatch

| | Value |
|---|---|
| sessionId of the persisted session | local_47f668f2-236f-46f4-934e-54387e544be9 |
| ID passed to resume at turn 2 | fc9d5e70-3f89-4dce-ba44-d47277a4b4df |

Two observations:

1. Different UUID. fc9d5e70 matches no file anywhere on the machine — find ~/.config/Claude ~/.claude <data-partition> -name '*fc9d5e70*' returns nothing. It appears exactly once on the whole disk: inside the error string quoted above.
2. Different shape. Persisted session IDs carry a local_ prefix. The ID passed to resume is a bare UUID.

The app clearly still holds the correct session handle at turn 2 — it writes error, errorAt and errorCategory into the right file. It just asks the resume path for an identifier that was never that session's.

Suggested angle: the resume call site appears to receive a session ID from a different source than the one the persistence layer assigns and keys on. Worth checking whether the bare-UUID and local_-prefixed forms are the same value passing through two different code paths, or genuinely unrelated IDs.

Nothing is lost, for what it's worth — the conversations are intact on disk. The app just cannot find them.

Environmental causes ruled out by measurement

This machine has a non-standard setup, and none of it is responsible:

• eCryptfs filename-length limit — real (≈143 chars: a 180-char filename fails, 140 succeeds), but the longest filename the app creates is 47 chars. Never approached. Not ENAMETOOLONG.
• Relocated VM bundle — ~/.config/Claude/vm_bundles is symlinked to another partition for disk space, but local-agent-mode-sessions/ is a sibling real directory that was never relocated.
• Permissions / cross-device writes — writes to that directory succeed, including a 352 KB write during the failing run.

Consistent with the Windows 11 report in #57109: a logic bug travels across platforms; a filesystem constraint does not.

Related issues (all currently closed)

• #57109 — same symptom, Windows 11, Cowork. Closed as duplicate, locked.
• #36842 — session teleport, same error string, Windows.
• #36865 — every new cloud session fails with the same error, Windows.
• #33912 — claude --resume returns "No conversation found" although session files exist. Closed as not planned / stale. Closest to this report, but CLI-only.

Workaround

Running the task in the cloud instead of locally avoids it entirely — session state is handled server-side and this resume path is never taken. Settings → Cowork → "Run new tasks in the cloud".

What Should Happen?

No error

Error Messages/Logs

No conversation found with session ID: fc9d5e70-3f89-4dce-ba44-d47277a4b4df

Steps to Reproduce

100% reproducible, on the second message of any local Cowork task:

1. Start a Cowork task in local mode on any folder.
2. Message 1 — works normally.
3. Message 2 — fails immediately with:

No conversation found with session ID: fc9d5e70-3f89-4dce-ba44-d47277a4b4df

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude desktop app 1.30096.1

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_