fix: reap zombie 'running' jobs at the resume gate via pid-liveness check (#222, #202)

[storyarcade]

Problem

When a Codex task worker crashes or is killed externally, its job record stays status: "running" forever. The next task/resume call in that cwd then throws and is permanently blocked:

Task <id> is still running. Use /codex:status before continuing it.

resolveLatestTrackedTaskThread() finds any queued|running job and throws without checking whether the worker process is actually alive — there is no pid-liveness check, so a dead worker's record is indelible. (Root cause: #222; symptoms: #202, #164.)

Fix

Before the blocking throw, probe the worker pid:

1. process.kill(pid, 0) → ESRCH ⇒ dead, EPERM ⇒ alive-but-not-ours (treat as alive). Portable across macOS/Linux/Windows via libuv; no new dependency.
2. If the worker is dead, reconcile the job to failed — writing state.json (the store the gate reads) plus a best-effort per-job-file mirror for status/result readers — then mutate the in-memory snapshot and fall through to normal resolution.
3. Only throw the "still running" error if the worker is actually alive (live jobs are unaffected).

Why minimal (vs #216)

This touches only the gate function: ~12 lines + two small helpers. It does not add a deadline/timeout, a background reaper, or a daemon — just "don't block on a provably-dead worker." Builds on the approach in the now-conflicting #216, scoped to the surgical, conflict-free subset.

Known limitation (PID reuse)

A PID-based probe inherits the standard caveat: if the OS recycles the crashed worker's PID before the next task call and an unrelated process holds it, the probe briefly treats the zombie as alive. It self-corrects on a later call, and the dominant case (immediate crash) is handled correctly. A future hardening could store the job id in a pidfile and verify identity, not just existence — out of scope here.

Test

• Spawn a task, kill -9 the worker, run another task in the same cwd → previously throws forever; now the dead job is reconciled to failed and the new task proceeds.
• Live job unaffected: a running worker still correctly blocks with the original message.

node --check passes on the patched file.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 99390fd4b2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep checking for live active tasks after reaping one

When the newest active task has a dead PID but an older task in the same session is still queued/running, this reconciles only the single .find result and then falls through to findLatestResumableTaskJob. Fresh background tasks can be launched without passing through this resume gate, so multiple active task records are possible; in that state task --resume-last can resume a completed thread while the older live task is still running instead of preserving the existing "still running" block. After reaping a zombie, reload or loop over the remaining active tasks before selecting a resumable thread.

Useful? React with 👍 / 👎.

[ghbaud]

This is a clean, minimal fix for the blocking symptom in #202, and process.kill(pid, 0) is the right portable primitive for it.

One scope note, in case the intent is for this to also close the #222 root cause and not just #202: the reconcile happens at the resume gate via resolveLatestTrackedTaskThread(), which reads state.json. That covers every job that made it into state.json. It does not cover a worker that dies before it registers there — one that crashes after writeJobFile() but before upsertJob(). That job exists only as an orphaned per-job file with a stale running/queued status and a dead pid, and it never appears in state.json at all.

That variant doesn't trigger #202's blocking failure — the gate never finds the job, so nothing gets blocked — which is exactly why it's reasonable to leave it out of a #202-focused change. But it is still part of the #222 root cause: the dead job stays invisible to /codex:status and /codex:result, because both of those also start from state.json. So if this lands and #222 is closed along with it, that never-registered case would quietly remain.

I hit this exact variant on Windows 11 and wrote it up here: #222 (comment). The patch I'm running locally adds a small sweep over the per-job files that finds entries missing from state.json with a dead pid and reconciles them to failed, run at the status/result read paths. It's complementary to this PR rather than competing, since it touches the read paths instead of the resume gate. Happy to open it as a follow-up on top of this if that's useful.