[BUG] coworkd auto-update reformats ext4 session disk, destroying all 31 active cowork sessions

[BUG] coworkd auto-update reformats ext4 session disk, destroying all 31 active cowork sessions

Description

A coworkd auto-update on March 2, 2026 reformatted my session disk (/dev/nvme1n1), destroying all 31 active cowork sessions representing 6 days of work. The updated binary failed to detect the existing ext4 filesystem and ran mkfs.ext4, wiping everything.

Environment

• OS: macOS Darwin 25.2.0
• Claude Desktop Version: Current as of March 2, 2026
• Claude Code Version: 2.1.51 (local-agent)
• Platform: Anthropic API (Max plan)

Steps to Reproduce

1. Have an active cowork environment with multiple sessions (31 in my case)
2. Wait for coworkd auto-update from 8e484a73 to 2511b20d
3. Sessions are destroyed on restart

The Fatal Log Sequence (from coworkd.log)

# BEFORE update - ext4 correctly detected, 31 sessions healthy:
2026/03/02 07:15:28 [coworkd] session disk already formatted as ext4
2026/03/02 07:15:28 [coworkd] user recovery complete: recovered=31 skipped=1 failed=0

# The destructive update:
2026/03/02 16:01:54 [updater] sdk-daemon update detected (old=8e484a73... new=2511b20d...)
2026/03/02 16:01:54 [coworkd] restarting to apply coworkd update
2026/03/02 16:01:57 [coworkd] formatting session disk /dev/nvme1n1 with ext4   <-- FATAL
2026/03/02 16:01:58 [coworkd] user recovery complete: recovered=0 skipped=1 failed=0

# Post-reformat:
2026/03/02 17:57:55 [coworkd] session disk already formatted as ext4
2026/03/02 17:57:55 [coworkd] user recovery complete: recovered=1 skipped=1 failed=0

Recovery Count Timeline

| Timestamp | Recovered | Event |
|-----------|-----------|-------|
| Feb 27 23:20:45 | 21 | After sdk-daemon update e3e82415 to 2511b20d (ext4 detected correctly) |
| Feb 28 09:02:54 | 25 | Normal restart |
| Mar 01 23:57:55 | 31 | Normal restart, peak count |
| Mar 02 07:15:28 | 31 | Last healthy state |
| Mar 02 16:01:58 | 0 | After sdk-daemon update 8e484a73 to 2511b20d |
| Mar 02 17:57:55 | 1 | Post-reformat, new session only |

Root Cause

The sdk-daemon binary 2511b20d was previously loaded on Feb 27 and correctly detected ext4 at that time. However, on Mar 2, when coworkd restarted with the update from 8e484a73 to 2511b20d, the same binary failed to detect the existing ext4 partition and reformatted the disk. This appears to be a race condition or state detection regression during the update restart sequence.

Impact

• 31 cowork sessions destroyed (created Feb 24 through Mar 1)
• Up to 39 total sessions lost (including 8 created on Mar 2 before the wipe)
• 6 days of accumulated work irrecoverably lost from the local disk
• I exhausted 11 local recovery methods including PhotoRec file carving (6,652 files recovered, all post-reformat). mkfs.ext4 on the 253MB partition overwrote all pre-reformat data.

Suggested Fixes

1. Pre-update backup: Snapshot sessiondata.img before any coworkd update
2. Double-check before formatting: If a disk was previously detected as ext4 (log evidence exists), require explicit confirmation or a second detection pass before reformatting
3. User confirmation: Never run mkfs.ext4 on a disk with existing sessions without user consent
4. Integrity check: Validate the ext4 superblock before deciding to format

Evidence Files Available

• coworkd.log (337KB) - contains the full reformat sequence
• cowork_vm_node.log (1.3MB) - contains all 39 session spawn records
• sessiondata.img.bak (253MB) - backup of the post-reformat disk image
• PhotoRec recovery output (106MB) - confirms all recovered data is post-reformat

Related Issues

• #24070 - Cowork VM fails to boot after auto-update (similar: update breaks VM, different: boot failure vs. data destruction)
• #29373 - Update loses Code session history (similar: update causes data loss, different: directory migration vs. disk reformat)
• #29154 - Session history lost after update (similar: update-triggered data loss)