Fix (partial): a session stuck reporting "Active session is closing" forever when its kernel is OS-stopped (#1072)

[kaluli123123]

Scope note

This addresses one of #1072's three reported symptoms — "Active session <id> is closing" persisting forever after reattach fails, with the underlying worker process observed stuck in OS state T (job-control-stopped, e.g. an external SIGSTOP). The other two reported symptoms (idle-eviction-sweep timeouts leaking worker processes, and a session showing "Executing" after its tool call already finished) share the same general shape — something the daemon awaits assumes will always eventually settle, and a genuinely frozen (not merely slow) peer process breaks that assumption — but are separate leak points in different code paths and are not covered by this change. This is one focused sub-fix, not a full fix for #1072, and I want to be upfront about that rather than overclaim.

Root cause

closeSession() (daemon-mode.ts) sets closingSessions.set(activeSessionId, close) before awaiting closePromise (→ closeSessionOnce, which awaits state.runtime.session.abort() and state.runtime.dispose()), and only clears that bookkeeping in closePromise's own finally block. If the session's kernel process becomes OS-level job-control-stopped, it can no longer respond to anything short of SIGCONT/SIGKILL, so whatever closeSessionOnce is awaiting on it never settles, the finally block never runs, and closingSessions never clears — every future attach or close for that session fails with "is closing" until the whole worker/daemon is killed and the OS-level state is gone.

Why not just add a timeout

This project deliberately does not use blanket timeouts for RPCs/waits that can legitimately run a long time — see PR #1701, "remove blanket RPC timeouts, reject on real boundaries." A naive fixed-duration timeout here would just as wrongly treat a slow-but-healthy close as failed. The fix instead checks the kernel process's actual OS state directly, so it only ever acts on a confirmed-frozen peer, never a merely-busy one.

Fix

• utils/child-process.ts: new isStoppedProcess(pid), reusing the existing /proc-stat-then-ps-fallback pattern already used by isZombieProcess, checking for POSIX state T specifically.
• core/kernel/index.ts / core/tools/ipython.ts / core/agent-session.ts: a new kernelPid/kernelProcessPid getter chain (KernelManager → IpythonKernelProvisioner, already held privately by AgentSession → a public AgentSession.kernelProcessPid) exposes the running kernel's OS pid for this kind of liveness check, without adding any new public surface to the Jupyter-protocol-facing parts of the kernel.
• modes/daemon/daemon-mode.ts: closeSession() now starts a watchForStoppedKernelDuringClose() watchdog alongside the close. It polls isStoppedProcess() on the session's kernel pid every 2s while the close is still pending; on the first confirmed-stopped poll it sends one SIGCONT (a session that was merely, legitimately suspended resumes and the close proceeds normally); if it is still confirmed stopped after further polls despite that, it releases the closingSessions entry (matching the existing entry by identity, the same check closeSession's own cleanup already uses, so a race between the two is harmless) so the session becomes reattachable again. The original close keeps running in the background and settles normally whenever/if the kernel resumes on its own.

Tests

• test/child-process.test.ts: isStoppedProcess against a real SIGSTOP/SIGCONT cycle on a real spawned subprocess (not mocked), confirming it is true only while genuinely stopped and distinguishes "stopped" from "dead"/"zombied"/"merely running".
• test/suite/regressions/1072-stopped-kernel-close-recovery.test.ts (new): drives the real closeSession() path (not the watchdog method in isolation) with a deliberately-hung runtime.dispose() and a mocked isStoppedProcess/process.kill, using fake timers for determinism: confirms SIGCONT is sent once, closingSessions is released only after the configured number of confirmations, and (second test) a merely-slow (never reported stopped) close is left completely alone.

Both verified to fail against pre-fix daemon-mode.ts and pass after the fix.

Validation

cd packages/coding-agent && npx tsx ../../node_modules/vitest/dist/cli.js --run \
  test/suite/regressions/1072-stopped-kernel-close-recovery.test.ts test/child-process.test.ts \
  test/daemon-mode.test.ts test/suite/regressions/4257-update-restart-resume.test.ts
# 244 passed, 0 failed.

npx tsgo -p tsconfig.json --noEmit and the root npm run check (biome, tsgo, installer render, browser smoke) both pass. Added a packages/coding-agent/.changes/ fragment per the changelog-fragment CI check.

Patch

Branch: https://github.com/kaluli123123/prime-agent/tree/fix/stopped-kernel-close-recovery

Diff: main...kaluli123123:prime-agent:fix/stopped-kernel-close-recovery