On 1.0.6 (macOS), asking for the result of a job that is still running reports the job as nonexistent:
$ node codex-companion.mjs result task-mrkxdpsi-mij20h --cwd /Users/me/repo
No job found for "task-mrkxdpsi-mij20h". Run /codex:status to list known jobs.
$ echo $?
1
$ node codex-companion.mjs status task-mrkxdpsi-mij20h --cwd /Users/me/repo
- task-mrkxdpsi-mij20h | running | rescue | Codex Task
There is code in resolveResultJob that intends to say Job X is still running. Check /codex:status and try again once it finishes. — but it is unreachable when a job id is passed.
scripts/lib/job-control.mjs (line numbers at current main):
resolveResultJob (line 256) first calls matchJobReference(jobs, reference, terminalPredicate) with the predicate filtering to completed/failed/cancelled.matchJobReference (line 191) applies the predicate, then matches the reference against the filtered list, and throws No job found for "<ref>" (line 210) when nothing matches.- So for a queued/running job looked up by id, the throw fires inside the first call and the
active check at line 269 never runs. The "still running" message is reachable only in the no-reference path, where matchJobReference returns filtered[0] ?? null instead of throwing.
This is worse than a cosmetic wrong message because No job found is the same string the cwd-mismatch case produces. A caller polling result <id> cannot distinguish "wrong workspace" from "not finished yet" from "no such job", and the natural reading — the job does not exist — is the one that is false. We traced a real incident to an orchestrator concluding from this exact string that a dispatched job had never run, and redoing the work while the job was still going.
Possible fixes, either works:
- Make
matchJobReference return null when a reference matches nothing, and let each caller produce its own error message (resolveResultJob already has the branching to do this correctly).
- Or in
resolveResultJob, match the reference against the unfiltered job list first, then check the status of the match — producing "still running" for active jobs, "No finished job" only when the id genuinely is not in the workspace.
https://claude.ai/code/session_01B5Xst2TXwvPQ5ecfMckbBR
On 1.0.6 (macOS), asking for the result of a job that is still running reports the job as nonexistent:
There is code in
resolveResultJobthat intends to sayJob X is still running. Check /codex:status and try again once it finishes.— but it is unreachable when a job id is passed.scripts/lib/job-control.mjs(line numbers at current main):resolveResultJob(line 256) first callsmatchJobReference(jobs, reference, terminalPredicate)with the predicate filtering tocompleted/failed/cancelled.matchJobReference(line 191) applies the predicate, then matches the reference against the filtered list, and throwsNo job found for "<ref>"(line 210) when nothing matches.activecheck at line 269 never runs. The "still running" message is reachable only in the no-reference path, wherematchJobReferencereturnsfiltered[0] ?? nullinstead of throwing.This is worse than a cosmetic wrong message because
No job foundis the same string the cwd-mismatch case produces. A caller pollingresult <id>cannot distinguish "wrong workspace" from "not finished yet" from "no such job", and the natural reading — the job does not exist — is the one that is false. We traced a real incident to an orchestrator concluding from this exact string that a dispatched job had never run, and redoing the work while the job was still going.Possible fixes, either works:
matchJobReferencereturnnullwhen a reference matches nothing, and let each caller produce its own error message (resolveResultJobalready has the branching to do this correctly).resolveResultJob, match the reference against the unfiltered job list first, then check the status of the match — producing "still running" for active jobs, "No finished job" only when the id genuinely is not in the workspace.https://claude.ai/code/session_01B5Xst2TXwvPQ5ecfMckbBR