[BUG] Cowork spin-off task always fails instantly with "Couldn't set up this task" — branch spawn resumes a transcript UUID that was never written to disk (session_not_found, Windows MSIX)

Status Open
Reported on v2.1.221
Maintainer reply None cached
Activity 0 comments · opened Aug 6, 2026

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?

This is Cowork mode in the Windows Claude Desktop app (filing here per the precedent that Cowork/Windows issues are tracked in this repo — see #58421, #26073, #25579, #61350, #37312, #25707).

Spinning a task off from an existing Cowork conversation fails immediately, every time, with "Couldn't set up this task". Normal Cowork conversations and in-session subagents work fine.

7 attempts, 7 failures, on a clean install (installed 2026-08-03): 2026-08-04 00:11, 2026-08-04 09:52, 2026-08-04 18:55, 2026-08-05 11:55, 2026-08-05 15:10, 2026-08-06 09:57, 2026-08-06 21:06. It has never once succeeded on this machine.

What the logs show (full excerpt in the "Error Messages/Logs" field below): the app logs [Branch] First spawn resumes copied transcript <uuid> for session local_<id>, launches the CLI against the new session's cwd, and ~1 second later the CLI reports No conversation found with session ID: <uuid>. The cycle is marked unhealthy_reason: api_error, error_category: session_not_found, had_first_response: false, seconds_to_outcome: 2, transcript_size_bytes: undefined.

What I verified on disk immediately after the 2026-08-06 21:06:59 attempt:

  1. The transcript file 2125b0c2-f138-4f8f-a953-5587e2d8205f.jsonl does not exist anywhere under C:\Users\<user> (recursive search, including hidden/system).
  2. The spun-off session folder ...\local-agent-mode-sessions\<account>\<space>\local_70a68288-24c2-4ec2-b03f-3063e73ab31f\ does not exist either — while other session folders created the same evening (20:11, 20:38, 21:00, 21:08) are all present.
  3. For working sessions, transcripts live per-session at ...\local-agent-mode-sessions\<account>\<space>\local_<id>\.claude\projects\C--Users-<user>-AppData-Roaming-Claude-local-agent-mode-sessions-<account>-<space>-local-<id>-outputs\<uuid>.jsonl. Those project folder names are complete, 188 chars, not truncated or hash-stamped, and all use the AppData-Roaming-Claude spelling.

So the branch code announces "resumes copied transcript <uuid>" and hands that UUID to --resume, but the transcript (and apparently the whole session directory) is never materialised on disk — hence session_not_found. I can't tell from outside whether the copy is never written or whether the directory is cleaned up in the ~1 second between the spawn and the failure, but the resume target definitely isn't there when the CLI looks for it.

Possibly relevant context: this is an MSIX install, and C:\Users\<user>\AppData\Roaming\Claude is a reparse point whose target is C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude — the same data tree under two spellings. The app's cwd for the spawned session uses the AppData\Roaming\Claude\... spelling. If any part of the branch path writes through one spelling and reads through the other, or bails out silently on the reparse point, that would produce exactly this symptom. That's a hypothesis, not something I could confirm from user space.

Note there is no user-side workaround: the project folder name embeds a session ID generated at spawn time and the failure lands ~1 second later, so nothing can be pre-created or symlinked ahead of it. Reinstalling doesn't help either — claude.com/download ships the same MSIX package, and per the Windows deployment docs there is no non-MSIX Windows build to fall back to.

What Should Happen?

Spinning a task off from a Cowork conversation should start a working session that has the parent conversation's context, the same way in-session subagents and ordinary new conversations already do.

Concretely, whatever the [Branch] code path hands to --resume should be guaranteed to exist on disk (and stay there) before the CLI is launched — and if the copy fails, the app should surface the real reason rather than a generic "Couldn't set up this task".

Why I don't think this is a duplicate of the existing "No conversation found" reports:

  • #57109 / #49582 / #36865 are about every session or all new tasks failing. Here everything else works — only the spin-off/branch path fails, 7 times out of 7, on an otherwise healthy install.
  • #46927 (closed, locked) is about resume after app restart, where the transcript JSONL is intact on disk and only the ID mapping is wrong. Here the opposite is true: is_resume: false, transcript_size_bytes: undefined, and the transcript file genuinely isn't on disk at all.

Happy to run any diagnostic you'd like on this machine — I still have the failing install and full logs.

Error Messages/Logs

From %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\main.log
(note: %APPDATA%\Claude\logs is the same tree via the MSIX reparse point)

Attempt of 2026-08-06 21:06:59 — most recent of 7 identical failures:

2026-08-06 21:06:59 [info] [LocalAgentModeSessionManager] Using 17 remote plugins
2026-08-06 21:06:59 [info] [Branch] First spawn resumes copied transcript 2125b0c2-f138-4f8f-a953-5587e2d8205f for session local_70a68288-24c2-4ec2-b03f-3063e73ab31f
2026-08-06 21:06:59 [info] [HostLoop] sdkOptions after patch: {
  cwd: 'C:\\Users\\<user>\\AppData\\Roaming\\Claude\\local-agent-mode-sessions\\<account>\\<space>\\local_70a68288-24c2-4ec2-b03f-3063e73ab31f\\outputs',
  executable: 'C:\\Users\\<user>\\AppData\\Roaming\\Claude\\claude-code\\2.1.221\\claude.exe',
  executableArgs: [ [length]: 0 ],
  hasSpawnClaudeCodeProcess: false,
  toolCount: 15,
  allowedToolCount: 53,
  ...
2026-08-06 21:06:59 [info] [FileWatching] Starting file watcher for session local_70a68288-24c2-4ec2-b03f-3063e73ab31f: C:\Users\<user>\Claude\Projects
2026-08-06 21:07:00 [warn] [HostLoop] cli.js stderr: No conversation found with session ID: 2125b0c2-f138-4f8f-a953-5587e2d8205f
2026-08-06 21:07:00 [info] [Result] Turn failed for session local_70a68288-24c2-4ec2-b03f-3063e73ab31f: subtype=error_during_execution, is_error=true
2026-08-06 21:07:00 [info] [Lifecycle] Session local_70a68288-24c2-4ec2-b03f-3063e73ab31f: running -> idle
2026-08-06 21:07:00 [info] [CycleHealth] Unhealthy cycle: {
  session_id: 'local_70a68288-24c2-4ec2-b03f-3063e73ab31f',
  scheduled_task_id: null,
  variant_key: '07_16_2026.replace',
  session_built_prompt: true,
  session_type: undefined,
  parent_session_id: undefined,
  host_loop_mode: true,
  model: 'claude-opus-5',
  permission_mode: 'bypassPermissions',
  cli_session_id: null,
  cycle_health: 'unhealthy',
  had_first_response: false,
  seconds_to_outcome: 2,
  is_resume: false,
  unhealthy_reason: 'api_error',
  error_message: 'No conversation found with session ID: 2125b0c2-f138-4f8f-a953-5587e2d8205f',
  error_category: 'session_not_found',
  transcript_size_bytes: undefined
}

Note `parent_session_id: undefined` and `cli_session_id: null` on a branch spawn, and
`transcript_size_bytes: undefined` — there was no transcript to measure.

The same [Branch] -> session_not_found pair appears in main.log / main1.log / main2.log for
all 7 attempts (2026-08-04 00:11, 09:52, 18:55; 2026-08-05 11:55, 15:10; 2026-08-06 09:57, 21:06).

Steps to Reproduce

  1. Install Claude Desktop for Windows from claude.com/download (MSIX package, family name Claude_pzs8sxrjxfjjc; mine is Claude_1.25927.0.0_x64__pzs8sxrjxfjjc, SignatureKind Developer).
  2. Open Cowork, connect a working folder, and hold an ordinary conversation so the session has a transcript. This part works fine.
  3. From that conversation, spin off a task (branch it into its own task).
  4. The task window shows "Couldn't set up this task" within about two seconds. It has never succeeded here — 7 attempts over 3 days.
  5. Open %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\main.log and search for First spawn resumes copied transcript. Immediately below it you will find No conversation found with session ID: <same uuid> and an Unhealthy cycle block with error_category: 'session_not_found'.
  6. Search the whole user profile for <uuid>.jsonl — it is not there.
  7. Look in ...\AppData\Roaming\Claude\local-agent-mode-sessions\<account>\<space>\ — the local_<id> folder named in the [Branch] line does not exist, although folders for sessions created minutes earlier and later do.

For contrast, a healthy Cowork session at the same time has its transcript at:
...\local-agent-mode-sessions\<account>\<space>\local_<id>\.claude\projects\C--Users-<user>-AppData-Roaming-Claude-local-agent-mode-sessions-<account>-<space>-local-<id>-outputs\<uuid>.jsonl

Environment details that may matter:

  • Windows 11 Pro 10.0.26200 (build 26200), long paths disabled (LongPathsEnabled = 0); real session paths are 386-429 chars, and the project folder name alone is 188 chars.
  • C:\Users\<user>\AppData\Roaming\Claude is a reparse point to C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude.
  • In-session subagents, scheduled tasks and normal conversations all work; only the spin-off path fails.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.221 (bundled CLI) - Claude Desktop 1.25927.0.0, Cowork mode

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

This is Claude Desktop's Cowork mode, not the Claude Code CLI — there is no claude --version for it, so the version field lists the bundled CLI (...\AppData\Roaming\Claude\claude-code\2.1.221\claude.exe) plus the desktop app version from Get-AppxPackage. The Terminal/Shell field doesn't really apply either; this is a GUI app.

Environment:

  • Claude Desktop Claude_1.25927.0.0_x64__pzs8sxrjxfjjc, SignatureKind Developer (sideloaded MSIX from the claude.com/download installer, not the Store).
  • Windows 11 Pro, 10.0.26200, build 26200.
  • Installed 2026-08-03; spin-off has never worked once since.
  • Failing cycles ran claude-opus-5, permission_mode: bypassPermissions.

Two things that might narrow it down:

  1. Only the branch/spin-off path is affected. Ordinary Cowork conversations, in-session subagents and scheduled tasks all run fine at the same moment, in the same app, against the same folder — so the VM, the virtualization services and the CLI binary are all healthy.
  1. On this MSIX install %APPDATA%\Claude is a reparse point onto %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude (same data, two spellings — the cause of #58421 and #26073). The [Branch] path is the one place I've found that writes a file and then immediately reads it back by path, and it's the one place that fails. That may be coincidence, but if the copy is written through one spelling and looked up through the other, or if the write silently fails on the reparse point, the observed symptom follows exactly.

I still have the failing install and the complete logs, and I'm happy to run any diagnostic (process monitor trace, directory watch during a spawn, etc.) that would help pin this down.

View original on GitHub ↗