[BUG] Dispatch-spawned sessions hang to 15-min timeout: forward-slash cwd hits untrusted duplicate project entry, trust dialog never surfaced

Summary

Sessions spawned by Dispatch ([DispatchTools] Spawned host code session ...) sometimes never execute their first turn. The session shows as running with a spinner, writes no transcript, and after ~15 minutes hits the warm-lifecycle idle timeout and is marked "The session stopped responding. Send your message again to resume with a fresh process." (errorCategory: timeout). Manually stopping and restarting the session makes it start normally, which masks the bug.

Root cause (verified in config + logs, workaround confirmed): the Dispatch spawn path resolves the project cwd with forward slashes, which creates or matches a separate project entry in ~/.claude.json from the backslash entry that interactive sessions use. The forward-slash entry has hasTrustDialogAccepted: false, so the spawned CLI blocks on the workspace trust prompt - and Dispatch never surfaces that prompt in the UI. The session hangs until the timeout.

Environment

• Windows 11 Pro 10.0.26200
• Claude Desktop 1.25927.0.0 (MSIX/Store install)
• Claude Code host CLI 2.1.221
• Dispatch parent: local ditto session; spawned sessions are local host code sessions

Evidence

~/.claude.json ends up with duplicate project entries per repo, differing only in path separator. Backslash entries (used by interactive sessions) are all trusted; forward-slash duplicates are untrusted:

'C:\Repos\brain-be'  hasTrustDialogAccepted=true
'C:/Repos/brain-be'  hasTrustDialogAccepted=false

I had 20 forward-slash entries; 18 were untrusted. The only 2 trusted forward-slash entries were the two cwds where dispatched sessions reliably start. Correlation across 28 dispatch spawns in my logs:

• Dispatches to the 2 forward-slash-trusted cwds: start normally (init 8-75s).
• Dispatches to forward-slash-untrusted cwds: hang. Examples from main.log:
• [CCD start-timing] local_e1237375-... init=691200ms (11.5 min - started only after I manually restarted it)
• [CCD start-timing] local_1c2ea5e9-... emitted 43 minutes after its [DispatchTools] Spawned host code session line (stalled until manual restart, then init=37s)
• local_fa98cfce-... spawned 23:00:56, no start-timing line ever, no transcript file ever created, [WarmLifecycle:session] Idle timeout reached, disconnecting at exactly +15:00, session state file records errorCategory: "timeout"

No permission request was emitted to the UI for the stuck session during the stall window (checked main.log), so the trust prompt is blocking CLI-side with nothing rendered Desktop-side.

Repro

1. On Windows, pick a repo that has been used interactively (backslash project entry trusted) but whose forward-slash twin entry is absent or untrusted in ~/.claude.json.
2. Dispatch a task to that repo from the Dispatch UI.
3. Session spins, writes no transcript, and times out after ~15 minutes. Stopping and restarting it manually makes it run.

Workaround

Set hasTrustDialogAccepted: true on the forward-slash duplicates in ~/.claude.json. After flipping the 18 untrusted entries, dispatched sessions start normally.

Suggested fixes

• Normalize the project key (separator and drive-letter case) before trust lookup, so one folder has one entry.
• Have Dispatch surface CLI-side trust/permission prompts in its UI, or fail fast instead of hanging to the idle timeout when the child blocks on an interactive prompt.

Related (all closed not-planned, each covers half of this)

• #19910 - duplicate .claude.json project entries from Windows path-format inconsistency (the trigger)
• #36342 - trust prompt blocks programmatically spawned sessions (the mechanism)
• #53606 - trust prompt blocks unattended remote-control sessions
• #47899 - dispatched/scheduled sessions stuck "Running" with zero turns on Windows (same symptom, root cause never identified - plausibly this bug)