[BUG] Claude Desktop (Linux) Cowork: turn-one oneshot is torn down with .claude/projects unmounted, so every follow-up fails with "No conversation found with session ID"

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?

In the Cowork tab of the Claude desktop app on Linux, the first message of a task
works normally. Every follow-up message in that same task fails immediately with
No conversation found with session ID: <uuid>. Retry reproduces the identical error
with the identical session ID, and restarting the app does not help. Every Cowork task
is effectively single-turn.

Cowork on Linux runs the engine inside a KVM guest. The guest executes each turn as a
disposable "oneshot" process and, on exit, unmounts everything including
.claude/projects. Meanwhile the host retains the CLI session ID from turn one and
attempts to resume against it on turn two. No transcript was persisted to the mounted
host .claude/projects before the unmount, so the resume finds nothing and the host
clears the ID as stale.

This appears architectural rather than environmental: session IDs are reused across
turns while each turn leaves no resumable state. I can only infer this from logs, so
treat the interpretation as a hypothesis and the timeline below as the evidence.

Environment

• OS: Linux Mint 22.3 (Ubuntu-based, meets the documented Ubuntu 22.04+ requirement)
• Desktop session: Cinnamon / X11
• App: claude-desktop 1.30096.1 from Anthropic's official apt repository.

apt policy confirms installed == candidate, so this is current stable.

• Engine: SDK binary v2.1.229 (per coworkd-console.log)
• Surface: Cowork tab, hostLoopMode: true
• Electron 42.7.0, deploymentMode: 1p
• Plan: paid subscription on a Team/Enterprise org

What Should Happen?

The follow-up message should resume the existing session and continue the task with
the prior turn's context intact.

Error Messages/Logs

### Timeline

Guest side, `~/.config/Claude/logs/coworkd-console.log`. End of turn one:


13:33:24 [process:oneshot-<X>] started PID 2997
13:33:24 [process:oneshot-<X>] direct child exited: code=0 signal=<nil>
13:33:24 [cgroup] cgroup oneshot-<X> is now empty (waited 98.082µs)
13:33:24 [cgroup] cleaned up cgroup oneshot-<X>
13:33:24 [process:oneshot-<X>] all processes exited, proceeding with cleanup
13:33:24 [process:oneshot-<X>] unmounted /sessions/<name>/mnt/.claude/skills
13:33:24 [process:oneshot-<X>] unmounted /sessions/<name>/mnt/.claude/projects
13:33:24 [process:oneshot-<X>] unmounted /sessions/<name>/mnt/uploads
13:33:24 [process:oneshot-<X>] unmounted /sessions/<name>/mnt/outputs
13:33:24 [process:oneshot-<X>] unmounted /sessions/<name>/mnt/<working-folder>
13:42:49 [coworkd] SDK binary v2.1.229 already installed, skipping


That SDK line is the **last** guest-side activity. On the follow-up message there is
no new oneshot spawn, no cgroup creation, and no mounts.

Host side, `~/.config/Claude/logs/main.log`, one second later:


[info] Mapping internal session local_<A> to CLI session <B>
  cli_session_id: '<B>',
13:42:50 [warn] [HostLoop] cli.js stderr: No conversation found with session ID: <B>
13:42:50 [info] [Result] Clearing stale cliSessionId <B> for session local_<A> - transcript was unresumable (queue-ops only)
  error_message: 'No conversation found with session ID: <B>',


The internal-to-CLI session mapping itself is correct.

### Session state file


{
  "sessionId": "local_<A>",
  "error": "No conversation found with session ID: <B>",
  "errorCategory": "session_not_found",
  "errorAt": <ts>,
  "errorVersion": "1.30096.1",
  "hostLoopMode": true,
  "processName": "<vm-name>",
  "vmProcessName": "<vm-name>"
}


### No resumable transcript exists

`CLAUDE_CONFIG_DIR` is passed as a host path into the per-session workspace:


CLAUDE_CONFIG_DIR: /home/<user>/.config/Claude/local-agent-mode-sessions/<space>/<sub>/local_<A>/.claude


That `.claude` tree contains `projects/` and `sessions/`, both created at session start
and **both empty**. The only `.jsonl` anywhere in the workspace is the audit log:


$ find "$SESSION_DIR" -name "*.jsonl" -printf "%s\t%p\n"
79990   .../local_<A>/audit.jsonl


`grep -a` for the CLI session ID across both `rootfs.img` and `sessiondata.img`
returns 0 matches, so it is not hiding in the guest images either.

### What "queue-ops only" refers to

The task queue **does** persist across the virtiofs boundary:


$ ls "$SESSION_DIR/.claude/tasks/<B>/"
.lock  1.json  2.json  3.json


Each is a todo record, not a conversation message:


{
  "id": "1",
  "subject": "<todo subject>",
  "description": "<todo description>",
  "activeForm": "<in-progress label>",
  "status": "completed",
  "blocks": [],
  "blockedBy": []
}


So the queue survives and the transcript does not, matching the log wording exactly.
Note also the zero-byte `.lock` created at session start and never cleaned up.

### Ruled out

- **Env var.** `CLAUDE_CODE_SKIP_PROMPT_HISTORY` is not set. `main.log` dumps the full
  env passed to the `cli.js` spawn and contains zero occurrences of it. Nothing in
  `~/.bashrc`, `~/.profile`, `/etc/environment`, `~/.config/environment.d/`, the
  `.desktop` entries, or any systemd user unit. (`ps`/`/proc` inspection is not
  applicable, since `cli.js` runs inside the guest and is never a host process.)
- **Permissions.** All session dirs are owned by the running user, `touch` into
  `.claude/projects` succeeds, and `main.log` has no EACCES, EPERM, EROFS, ENOSPC, or
  write-failure entries. The engine demonstrably writes `.claude.json`, rotating
  backups, `policy-limits.json`, and the task queue into the same tree.
- **Filesystem type.** One working folder was on an exFAT mount. Removing all working
  folders and running a fresh session reproduces the failure identically.
- **Retention.** Fails on tasks minutes old. No `cleanupPeriodDays` override;
  `~/.claude/settings.json` contains only `theme` and
  `skipDangerousModePermissionPrompt`.
- **Stale install.** Installed version equals repository candidate.
- **Session-ID lookup scope.** Engine is v2.1.229, past the v2.1.223 change that
  broadened lookup beyond the current project directory.
- **The Aug 17 Opus 5 incident** (status.claude.com/incidents/zhk4v3yv1lsf). The
  failure above is at 13:42 UTC, 14 minutes before that incident was posted, and
  identical failures exist across sessions dating to July 31.
- **The engine itself.** The Code tab and the Claude Code CLI on this same machine
  write transcripts to `~/.claude/projects/` correctly and resume fine.

Steps to Reproduce

1. Open the Cowork tab and create a new task.
2. Send a prompt. It completes normally and produces output files.
3. Send any second message in the same task.
4. The task errors with No conversation found with session ID: <uuid>.
5. Retry reproduces the same error with the same session ID. Restarting the app does

not help.

Reproduces with and without a working folder selected, on any filesystem, on every
follow-up message.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.229

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

I'm on the latest Claude for Linux Desktop app, v1.30096.1 (194d93). The version fields were ambiguous for my case, so to be explicit: the failing component is the engine bundled inside the Cowork VM, which coworkd-console.log reports as SDK binary v2.1.229. I also have a standalone Claude Code v2.1.231 on the same machine, which works correctly and is not involved. OS is Linux Mint 22.3.

If this gets matched against existing reports of the same error string, the distinguishing evidence is the coworkd-console.log timeline above: the guest unmounts .claude/projects at the end of turn one, and no process is spawned at all for turn two. I haven't found another report with that timeline, but I may have missed one. Happy to provide full logs.