Windows: resume crashes after 0.12.7 to 0.12.11 upgrade when managed session changes

[kogangdon]

Summary

On Windows, resuming a session created under Gajae-Code 0.12.7 after upgrading to 0.12.11 caused the GJC process to crash with an unhandled rejection.

Environment

• OS: Windows 11 Pro (win32 10.0.26200, x64)
• Previous GJC version: 0.12.7
• Current GJC version: 0.12.11
• Operation: resume an existing managed session created before the upgrade
• Session storage: default managed session directory

Observed behavior

The resume operation terminated the process. The crash log recorded:

2026-08-04T01:39:46.746Z pid=34004 [Unhandled Rejection] Error: Managed session changed before migration authority was adopted.
Error: Managed session changed before migration authority was adopted.
    at prepareManagedCandidateForWrite (C:\\Users\\SHIFTUP\\node_modules\\@gajae-code\\coding-agent\\src\\session\\session-manager.ts:9693:14)
    at prepareManagedCandidateForStrictAdoption (C:\\Users\\SHIFTUP\\node_modules\\@gajae-code\\coding-agent\\src\\session\\session-manager.ts:9662:35)
    at handleResumeSession (C:\\Users\\SHIFTUP\\node_modules\\@gajae-code\\coding-agent\\src\\modes\\controllers\\selector-controller.ts:2761:57)
    at async <anonymous> (C:\\Users\\SHIFTUP\\node_modules\\@gajae-code\\coding-agent\\src\\modes\\controllers\\selector-controller.ts:2643:17)
    at processTicksAndRejections (native:7:39)

Expected behavior

If the selected session changes during the read/migration authority check, resume should fail gracefully with a user-visible status/message and leave the current session usable. It should not become an unhandled rejection that crashes GJC.

Analysis

The failure is consistent with a race between the read-only session inspection and managed-candidate preparation. The identity check correctly fails closed, but the rejection from prepareManagedCandidateForStrictAdoption() appears to escape handleResumeSession() because that preparation occurs before the inner switchSession() error handler. The picker callback is void-returning, so the rejection becomes an unhandled rejection.

The affected session was created under 0.12.7 and resumed after the 0.12.11 upgrade; this may involve the managed-session migration path introduced/changed across the upgrade. The issue may be intermittent, but the failure mode is process-fatal when it occurs.

The repeated Codex WebSocket prewarm warnings around the same period were non-fatal and do not appear related.

Suggested regression coverage

• Arrange a managed session whose identity changes between inspectSessionTailReadOnly() and prepareManagedCandidateForStrictAdoption().
• Assert resume reports a recoverable error/status instead of producing an unhandled rejection.
• Assert the active session remains usable after the failed resume.
• Add coverage for resuming a pre-0.12.11 session after upgrade on Windows.

[Yeachan-Heo]

ACCEPTED_BUG

Independently verified against current dev — every specific technical claim in this report checks out against live code, not just plausibility:

1. Exact crash site confirmed present. packages/coding-agent/src/session/session-manager.ts:9558-9559 (and the revalidation branch at :9595-9596) still throw new Error("Managed session changed before migration authority was adopted.") — the identical message in the crash log — from inside the async SessionManager.prepareManagedCandidateForWrite, called through prepareManagedCandidateForStrictAdoption.

2. The escape path is real, not hypothetical. handleResumeSession (selector-controller.ts:2732) wraps its body in a try { … } finally { … } with no catch on the outer block. prepareManagedCandidateForStrictAdoption (:2756) runs inside that unwrapped try, strictly before the inner switchSession try/catch (:2766) even starts — so a rejection here has no handler anywhere inside handleResumeSession to intercept it; the finally runs cleanup and the rejection keeps propagating. (Worth noting for anyone fixing this: even the inner switchSession catch rethrows unconditionally for any non-"busy" error at :2804, so this same escape exists for a second, adjacent class of resume failures — not just the migration-authority path.)

3. The picker callback genuinely erases the async contract. showSessionSelector's callback (selector-controller.ts:2636-2639) is async sessionPath => { done(); await this.handleResumeSession(sessionPath); }, but it's assigned to SessionSelectorComponent's constructor parameter typed onSelect: (sessionPath: string) => void (session-selector.ts:200). TypeScript's structural typing accepts an async function where void is expected, silently discarding the return type. The actual call site, session-selector.ts:217 (and :252), invokes this.onSelect(session.path) synchronously from inside a keypress-driven input handler — no await, no .catch(), no void marker. A rejection surfacing after that call's first await boundary is unreachable from any surrounding frame.

4. No safety net catches it. grep -rl "unhandledRejection" packages/coding-agent/src returns nothing — there is no process-level handler to convert this into a graceful degradation; Bun's default unhandled-rejection behavior (crash) applies directly, matching the reporter's crash log exactly.

5. Not a duplicate. The only related merged fix in this area, fix(coding-agent): stop a second resume from crashing the session picker [supersedes #3521] #3523 ("stop a second resume from crashing the session picker"), added the #resumeInFlight re-entrancy guard visible at selector-controller.ts:2730-2737 — confirmed still present, but it only prevents a second concurrent resume from starting; it does nothing for a single resume whose managed-candidate identity check fails. No open issue or merged PR addresses this specific escape.

Platform scope note: the control-flow defect itself is platform-agnostic — any OS hitting the identity-mismatch race during prepareManagedCandidateForWrite would crash identically, since nothing in the escape path is Windows-specific. The report is Windows-only evidence, consistent with Windows filesystem/AV-scan timing making the read-then-revalidate race window more likely to trigger in practice, not with the bug being Windows-exclusive in cause.

Scope for the fix (bounded, not prescribing implementation): packages/coding-agent/src/modes/controllers/selector-controller.ts (handleResumeSession needs an outer catch that reports via this.ctx.showStatus/showError instead of rethrowing past a void boundary) and packages/coding-agent/src/modes/components/session-selector.ts (the onSelect/onSelection contract should either be typed to reflect its async nature or the call sites should explicitly handle rejection). Assigned to the Windows batch per this triage's lane; root cause and fix surface are shared TUI/coding-agent session-controller code, not Windows-only source.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[Yeachan-Heo]

Batch triage — ADMITTED / OPEN

Admission: accepted P1 user-facing correctness bug. Current dev is 732856b3ccb3fade6e9fbc17908a4fbca5a7682f; the failure path remains present in source.

Duplicate status: not a duplicate of #3523. That merged repair serializes overlapping resumes and handles typed transition-busy admission. #3804 is the still-unobserved pre-switch strict-identity rejection from managed-candidate preparation.

Hostile source review

• SessionManager.prepareManagedCandidateForStrictAdoption() still fails closed with Managed session changed before migration authority was adopted. when the selected identity changes.
• SelectorController.handleResumeSession() awaits that preparation before the inner switchSession() catch begins.
• SessionSelectorComponent still accepts onSelect as (sessionPath: string) => void and invokes it without observing a returned promise. The picker passes an async callback, so the rejection can escape as an unhandled rejection.
• Current regression coverage awaits handleResumeSession() directly and explicitly expects the rejection; it does not exercise the actual void picker-dispatch boundary or prove a visible recoverable error.

CI: current-head Dev CI run 30935832940 is failed, but the primary failure is unrelated shard-8 sdk-operation-inventory.test.ts:66. Windows dev:doctor/session-path and coding-agent TypeScript build pass. This CI is neither fix evidence nor a #3804-specific regression result.

Platform scope: Windows is the observed environment, not proven exclusive causation. The control-flow defect is platform-agnostic; Windows filesystem/AV timing may only make the identity race easier to hit.

Contributor ledger: @kogangdon supplied the exact Windows upgrade reproduction and crash stack; @yazzang-homelab authored the earlier #3523 resume-reentrancy repair; @Yeachan-Heo owns the current interactive/session routing path and accepted the report.

Owner path: no active PR and no formal assignee. Route to @Yeachan-Heo / the coding-agent interactive-session owner. Preserve the strict identity fence; observe and translate the async rejection at the UI dispatch boundary (or an equivalently complete boundary), keep the current session usable, and add picker-level regression coverage for visible recovery and no unhandled rejection. Do not weaken identity validation or auto-retry the changed candidate.

Signed: GJC / gaebal-gajae