Desktop: sessions with "create a fresh worktree" enabled hang and create nothing — regression between 1.24012.9 and 1.26832.0

Platform: Windows 11, Claude Code Desktop 1.30096.1 (MSIX/Windows Store), CLI 2.1.229
Regression: appeared immediately after the auto-update 1.28929.0 → 1.30096.1

Summary

Starting a background task ("chip") reports success, but no session is ever created. The UI shows a
session that hangs forever. This survives an app restart.

Repro

1. Have an assistant session spawn one or more background-task suggestions.
2. Click to launch them.
3. Observe: the session shell appears in the UI and never starts.

Evidence

Launch is accepted — every task is marked launched:

LocalSessions.popBackgroundTaskSuggestionById: sessionId=local_<redacted>, taskId=task_<a>, launched=true
LocalSessions.start:
LocalSessions.popBackgroundTaskSuggestionById: sessionId=local_<redacted>, taskId=task_<b>, launched=true
LocalSessions.start:

LocalSessions.start: logs with an empty payload — no sessionId, no cwd. Every other
LocalSessions.* line in the log carries sessionId=.

Nothing is created afterwards. Measured directly:

• session records in %APPDATA%\Claude\claude-code-sessions\<account>\<org>\: **1317 before, 1317

after** nine launches — not one record written

• no new directories under .claude/worktrees (newest predated the launches by 11 hours)
• no new claude.exe processes

While wedged, [WorktreePool] logged no activity at all. After an app restart it resumed
normally (untracked-dir GC, Reaping idle worktree) — but launching a task still hangs, so the
restart does not fix it.

Not the CLI governor

[CliGovernor] at cap; yielding warm spawn appears frequently in the same window and is a red
herring. Reading acquireSlot in resources/app.asar: a user spawn at cap logs would evict,
fires desktop_ccd_governor_soft_cap_exceeded, then falls through and spawns anyway — the cap is
soft. Only a warm (pre-warm) spawn returns {yielded: true}. Those lines mean background
pre-warming was skipped, nothing more.

Related: session records are lost if the app exits mid-write

Likely the same subsystem, and possibly a shared root cause worth checking.

On every session record file — including ones untouched since April — CreationTime ==
LastWriteTime exactly. The app rewrites each local_*.json whole rather than updating in place, so
a record is briefly absent during every write.

When the app quit for the auto-update, 9 records were permanently lost, and they were precisely the
sessions that were focused (i.e. being written) at that moment. The log names them:

[LocalSessionManager] [replaceEnabledMcpTools] Session "local_<redacted>" not found after session load; skipping

Transcripts survived, because those are separate append-only files under ~/.claude/projects/. So
no conversation content was lost — but the sessions vanished from the sidebar with no way to recover
them from the UI.

Suggested fix: write records atomically (temp file + rename) so an exit mid-write cannot destroy an
existing record.

Impact

Background tasks are unusable — the primary way to fan work out into fresh sessions. Workaround is
to launch sessions from a terminal instead, which bypasses LocalSessions.start entirely.

Possibly related: #59736, #54759, #29172, #25524 (sessions disappearing from the sidebar while
transcripts remain on disk).