Background-job reliability/UX: broken cancel, stale-job accumulation, individual-job wedge, no blocking await

Feedback from a heavy multi-cycle session on Windows (Git Bash + PowerShell) that delegated ~15 background review jobs through the codex-rescue agent. Four background-job reliability/UX issues, roughly in priority order.

1. cancel is broken from both shells

There was no way to cancel a job. From Git Bash the /PID-style argument gets MSYS path-mangled (turned into a filesystem path); from PowerShell the companion reports No job found (the PS invocation appears to look at a different session registry than the one the job was created in). Net effect: a stuck or unwanted job cannot be cancelled at all.

2. Stale/zombie jobs accumulate with no reaping

status listed jobs from prior sessions stuck in running for 11h-37h that never terminated. There is no auto-timeout and (because of #1) no way to clear them. Over a long session the status table fills with dead jobs, and it's unclear whether they still consume concurrency slots. Request: a max-runtime/auto-timeout, a prune/reap command, and clarity on whether stale jobs hold slots.

3. Individual jobs wedge in queued

One submitted job sat in queued for 1h40m and never started, while a job submitted later started and completed normally - so this was not global queue exhaustion; that specific job was individually wedged, with no diagnostic as to why. The only workaround was to abandon it and resubmit (which scheduled immediately). Some visibility into why a job won't leave queued, or a self-heal/requeue, would help.

4. No blocking await for a result

The submit-and-return model requires manually polling status then result. Across the session I hand-wrote ~8 bash poller loops (one per job) to watch for terminal state and fetch the result. A companion await <id> that blocks until terminal and prints the result - or a completion signal the host can wait on - would remove that entire boilerplate class.

Environment

Windows 11, Claude Code, codex plugin 1.0.6, jobs launched via the codex-rescue subagent (submit-and-return), polled via codex-companion.mjs status|result.

Happy to split these into separate issues if you'd prefer to track them individually.

Start with codex-companion.mjs and reproduce the Windows Git Bash and PowerShell behavior for cancel, status, and result using the submit-and-return workflow. Trace how jobs are registered, queued, and completed, then define tests or reproduction steps for cancellation, stale-job cleanup, queued-job recovery, and a blocking await command. Done means each requested workflow works reliably and stale jobs no longer obscure current state.