[BUG] Cowork session resume crashes with "TypeError: Invalid UUID" and enters infinite retry loop

Resolved 💬 5 comments Opened Mar 16, 2026 by eos4git Closed Apr 13, 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?

Summary

Attempting to resume a Cowork session causes a fatal TypeError: Invalid UUID crash in the UI error boundary. After the crash, Cowork automatically retries resuming the same session indefinitely, with each attempt timing out after ~42-49 seconds. There is no circuit-breaker or way to abandon the corrupted session from the UI.

Environment

  • App Version: Claude 1.1.6679 (Electron 40.4.1)
  • OS: Windows 11 Pro (10.0.26200) x64
  • SDK version in VM: 2.1.74
  • Model: claude-opus-4-6

Steps to Reproduce

  1. Have an existing Cowork session that has been resumed multiple times over several weeks
  2. Attempt to resume the session
  3. UI crashes with TypeError: Invalid UUID
  4. Cowork automatically retries, entering a crash loop

Observed Behaviour

1. Initial fatal crash (claude.ai-web.log)

2026-03-16 18:16:20 [warn] [LOCAL_SESSION] unknown sdk message type: queue-operation
2026-03-16 18:16:20 [warn] [LOCAL_SESSION] unknown sdk message type: queue-operation
2026-03-16 18:16:20 [warn] [LOCAL_SESSION] unknown sdk message type: queue-operation
2026-03-16 18:16:41 [error] TypeError: Invalid UUID
2026-03-16 18:16:41 [error] [BOOTSTRAP] Fatal error boundary triggered [object Object]

2. Retry loop (cowork_vm_node.log)

Each retry spawns a new Claude CLI process with --resume <session-id>, buffers ~111KB of serialised session state via stdin, then fails identically:

[Spawn:vm] Spawn succeeded in 3279ms
[Keepalive] Ping failed: Keep-alive ping timed out          ← ~12s after spawn
[Process:...] failed to write stdin: Error: Request timed out
[Process:...] Exited, code=0, signal=null, duration=42541ms, oom=false

Five consecutive retry attempts observed before I manually closed the app:

| Attempt | Time | Process ID | Duration | Failure |
|---------|-------|-----------|----------|---------|
| 1 | 18:17:14 | 629076eb | 46s | Keepalive timeout → stdin write errors |
| 2 | 18:19:20 | e376ae6a | 42s | Keepalive timeout → stdin write errors |
| 3 | 18:21:17 | d00e0382 | 43s | Keepalive timeout → stdin write errors |
| 4 | 18:22:08 | ba4f356e | 42s | Keepalive timeout → stdin write errors |
| 5 | 18:24:55 | 6ba3750f | 49s | Keepalive timeout → stdin write errors |

3. Supporting errors

coworkd.log — repeated stdin pipe failures for each process:

stdin write error: write |1: file already closed

cowork-service.log — RPC socket aborted during each retry:

[RPC] Read error: failed to read length: An established connection was aborted by the software in your host machine.

cowork_vm_node.log — after each process exits:

RPC error -1: os: process already finished

4. Additional context

  • The session had been successfully resumed 12 times over several weeks prior to this failure
  • The session had 19 mounts and a large MCP server configuration (~100 plugin entries)
  • Dozens of [LOCAL_SESSION] unknown sdk message type: queue-operation warnings appear before and after the crash, suggesting a possible SDK/UI protocol mismatch
  • The VM itself starts fine (network CONNECTED, API REACHABLE, SDK install succeeds in ~2-4s) — only the --resume of this specific session fails

Expected Behaviour

  1. Either the session resumes successfully, or a clear error is shown with the option to abandon the corrupted session
  2. The retry loop should have a circuit-breaker (e.g., max 2-3 attempts) rather than retrying indefinitely
  3. The TypeError: Invalid UUID error should include a stack trace or the offending value, not just [object Object]

Workaround

The only recovery is to abandon the session entirely and start a new one — there is no UI affordance for this during the crash loop; you must force-close and reopen the app.

What Should Happen?

The Cowork session should resume.

Error Messages/Logs

2026-03-16 18:16:41 [error] TypeError: Invalid UUID
2026-03-16 18:16:41 [error] [BOOTSTRAP] Fatal error boundary triggered [object Object]


### Retry loop (cowork_vm_node.log)

After the initial crash, Cowork spawns new VM processes that all fail identically:

| Attempt | Time  | Process ID   | Duration | Failure                                    |
|---------|-------|-------------|----------|--------------------------------------------|
| 1       | 18:17 | `629076eb`  | 46s      | Keepalive timeout → stdin write errors     |
| 2       | 18:19 | `e376ae6a`  | 42s      | Keepalive timeout → stdin write errors     |
| 3       | 18:21 | `d00e0382`  | 43s      | Keepalive timeout → stdin write errors     |
| 4       | 18:22 | `ba4f356e`  | 42s      | Keepalive timeout → stdin write errors     |
| 5       | 18:25 | `6ba3750f`  | 49s      | Keepalive timeout → stdin write errors     |

Each attempt:
1. Spawns Claude CLI with `--resume 6e6b650b-...`
2. Buffers **~111KB** of serialised session state via stdin
3. Spawn succeeds in ~3s
4. Keepalive ping fails within 10-15s
5. stdin writes fail with `Request timed out` / `file already closed`
6. Process exits, VM restarts, cycle repeats

### Additional symptoms
- Dozens of `[LOCAL_SESSION] unknown sdk message type: queue-operation` warnings flood the web log before and after the crash
- `coworkd.log` shows repeated `stdin write error: write |1: file already closed` for each process
- `cowork-service.log` shows `RPC Read error: An established connection was aborted by the software in your host machine`

## Expected Behaviour

Either the session resumes successfully, or a clear error message is shown allowing the user to abandon the corrupted session rather than entering an infinite retry loop.

## Additional Context

- The session had been successfully resumed **12 times** prior to this failure (since late February), so the corruption likely occurred during the most recent session
- The session has 19 mounts including multiple remote plugins
- No retry circuit-breaker appears to exist — the loop would continue indefinitely

Steps to Reproduce

see above

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.56

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗