[ktutumi]

Summary

• Ignore late process output and completion side effects from jobs removed during session reaping.
• Clear the cached UI context and contain stale hasUI access during session replacement.
• Preserve exit-state tracking so graceful termination does not trigger a delayed SIGKILL.
• Add real-process regression coverage for stale contexts, replacement-session UI and wake isolation, late output, and force-kill cancellation.

Root cause

reapAll() sends SIGTERM asynchronously and clears the job map before child-process data and close events necessarily finish. Those late events could access the stale cached UI context or wake and repaint the replacement session.

Testing

• npm test — 677 passed, 14 skipped
• npm run typecheck
• Confirmed the late-output regression test fails before the stream guard and passes after it.

Closes #119

[itayinbarr]

Approved and merging. Thank you for filing the issue and the fix together, with a harness that reproduces a timing-dependent crash deterministically. That is the hard part of this bug.

Your root cause is right, and I want to record the part that is easy to miss on review: the one-line move of hasUI into the try is the crash fix, but on its own it would have left the worse half of the bug in place. A reaped job's late data and close events would still repaint and wake the replacement session, so /new would have silently leaked the old session's job output into the new one instead of crashing. The jobs.has(job.id) guards are what actually make reaping mean something.

The ordering inside finish() is the detail I checked hardest, because it is the one that would have bitten later:

job.exited = true;          // before the map check
job.exitCode = code;
job.endedAt = Date.now();
if (!jobs.has(job.id)) return;

Setting exited ahead of the early return keeps scheduleForceKill's hasExited() gate honest for a job that reapAll already removed. Returning first would have re-introduced #102's orphan-SIGKILL problem from the other direction, and your fourth test pins exactly that. Good catch.

Verified locally: full suite 677 passed, typecheck clean, branch not behind main. CI was sitting in action_required because you are a first-time contributor here; I have approved the workflow run.

I am folding this into a wider pass in the same release. This is the third instance of the same shape (#108 in the context watchdog, now this), and SubCoderTracker holds a ctx across async sub-coder updates the same way, so I am adding a shared guard rather than waiting for the fourth report.