Dispatch start_code_task blocked by stale non-archived session records on Linux (1.46388.2); same root cause as #91745, still present after it was closed

Summary

Since the desktop app updated from 1.40609.1 to 1.46388.2 (Linux, apt), every Dispatch start_code_task into a folder that has ever hosted a Code session fails with:

Failed to start code session: A Claude Code session (local_00294129-...) is already active in this directory.

The session named in the error had finished on 2026-08-22, two weeks earlier. Deleting it in the UI only moved the block to the next non-archived record in the same folder. This is the same root cause reported in #91745 (closed as completed on 2026-09-05) and #92452, reproduced here on Linux with the 1.46388.2 build, whose app.asar still contains the check.

Environment

• Ubuntu 26.04 LTS (Hyper-V VM, Wayland/GNOME), x86_64
• claude-desktop 1.46388.2 from the Anthropic apt repository (Electron 42.10.0), bundled Claude Code 2.1.260
• Last known good: claude-desktop 1.40609.1, bundled Claude Code 2.1.255
• Target folders: a CIFS-mounted directory (not a git repo) and a subfolder of it. Dispatch host is this machine; the Dispatch orchestrator runs locally (dispatchParentOrigin: local).

Timeline (2026-09-06, local time)

• Until 17:18: Dispatch spawned Code sessions into the same folder all day (12 spawns logged for the day, 47 the days before), several concurrently. No start_code_task refusals in any earlier log file.
• 18:10: apt upgrade installed 1.46388.2 (log: Upgrade: claude-desktop:amd64 (1.40609.1, 1.46388.2)). Machine rebooted; app first launched on the new build at 18:14.
• 18:27 onward: every start_code_task into that folder fails:

18:27:05 [error] [DispatchTools] start_code_task failed for <folder>: A Claude Code session (local_0165e683-...) is already active in this directory.
18:35:30 [info] Deleted session local_0165e683-...        <- deleted in the UI
18:37:06 [error] [DispatchTools] start_code_task failed for <folder>: A Claude Code session (local_00294129-...) is already active in this directory.
18:37:57 [error] [DispatchTools] start_code_task failed for <folder>/<sub>: A Claude Code session (local_07ab01a5-...) is already active in this directory.

• local_00294129-... record: createdAt 2026-08-22, lastActivityAt 2026-08-22, isArchived: false, no process. local_07ab01a5-...: finished 2026-09-06 00:31, idle-disconnected by WarmLifecycle at 18:14, isArchived: false.
• A full app quit and relaunch (18:42) did not change anything; the app logs Loaded 258 persisted sessions and the same record blocks again.

Root cause (from resources/app.asar of 1.46388.2)

Identical to the analysis in #91745:

• startSession gates on r?.exclusiveCwd and calls findActiveSessionByCwd, which walks this.sessions and returns the first record where !isArchived and the normalized originCwd || cwd equals the requested cwd. It does not consult isRunning, lastActivityAt, or the CLI liveness registry.
• exclusiveCwd:!0 is hardcoded in the Dispatch startCodeSession callback and set nowhere else. Manual sessions from the Code tab are unaffected (we had several open in the same folder while Dispatch was being refused).
• Neither the Dispatch tool set nor the orchestrator has an archive/release tool, so from Dispatch the state cannot be cleared.
• Scale on this machine: 258 Code session records, all isArchived: false; 172 of them share the folder Dispatch targets. Archiving them one by one is not a workable mitigation, and any new child immediately re-blocks the folder until archived.

grep -c CwdInUseError resources/app.asar: 1.46388.2 = 3 occurrences; 1.40609.1 = 0.

Expected

Dispatch can start a Code session in a folder regardless of finished or idle sessions there, as it did through 1.40609.1 and as manual session creation still does. If a one-live-session-per-folder rule is intended, it should key off actual process liveness, and it should be documented; the changelog entries for 1.44121.1 through 1.46388.4 and the Dispatch guide do not mention it.

Workaround that restored the previous behavior

Downgrading with apt-get install --allow-downgrades claude-desktop=1.40609.1 and apt-mark hold claude-desktop. On 1.40609.1 the app loaded the same 258 records without errors, the Dispatch environment re-registered, and the persisted remote session reconnected. Which desktop release carries the fix for #91745? The 1.46388.4 changelog says "No user-facing changes" and #92452 reports the failure on 1.46388.4.