task --background: detached worker is spawned before its job file is written, and a fast-failing worker leaves a permanently queued job that was reported as started

[VOXDConsulting]

Version: plugin 1.0.6 (codex-companion.mjs), observed on Windows 11, Node 24, codex-cli 0.146.0-alpha.3.1.

Summary. enqueueBackgroundTask spawns the detached task worker before writing the job record the worker requires at startup. If the worker wins the race (or dies at startup for any reason), the parent still writes a queued record and reports the task as started. Nothing ever moves that record to a terminal state, and status reports it as active indefinitely.

Where (scripts/codex-companion.mjs, v1.0.6):

• enqueueBackgroundTask calls spawnDetachedTaskWorker(cwd, job.id) at line 688, then writes the job file with writeJobFile(...) at line 697 and upserts the index at line 698.
• The worker (handleTaskWorker, line 838) immediately reads that job file and throws if it is absent.
• The worker is spawned with stdio: "ignore" and detached: true (lines 673-679), so its startup failure is invisible to the parent and to the user.
• renderQueuedTaskLaunch (line 556) then reports the task as started in the background.
• status classifies jobs from the stored status field only (buildStatusSnapshot, lib/job-control.mjs line 213 onward); there is no PID liveness check, so the stuck queued record looks active forever.

Impact. A user who dispatches a background task gets a success message and a job id, but no work is running and no error ever surfaces. The failure mode is indistinguishable from a slow queue until the user inspects the log file (which contains only the "Queued for background execution." line).

Suggested fix. Write the job file and upsert the index BEFORE spawning the worker (swap lines 688-698 so writeJobFile/upsertJob precede spawnDetachedTaskWorker). The worker's read-at-startup then cannot race the write. Optionally: have status reconcile queued/running records whose pid is no longer alive.

Related hardening idea (separate, smaller). A cancel failure on Windows (taskkill returning an unrecognized nonzero, e.g. "operation not supported" under a restricted shell) throws in terminateProcessTree (lib/process.mjs line 97) before any cancellation bookkeeping, which also leaves the record active with no recovery path; a liveness reconciliation in status would cover both cases.

[LZong-tw]

Confirming this on plugin 1.0.6 / codex-cli 0.146.0 / Windows 11 / Node 24, with a measurement of the race window, since the report describes it as a possibility ("if the worker wins the race") rather than a measured one.

Two background jobs on 2026-08-10 died exactly as described. For each I have the parent-side filesystem timestamps, which bracket the window precisely:

job	log file created (parent, immediately before spawnDetachedTaskWorker at :687-688)	job record written (writeJobFile at :697)	gap
task-msn143tk-l9fkoi	09:28:29.482Z	09:28:30.198Z	716 ms
task-msn1elxx-nyti7f	09:36:39.330Z	09:36:40.206Z	878 ms
task-msn4ltjs-62b5za	11:06:14.616Z	11:06:15.4Z	~800 ms

The third one matters most: it was dispatched alone. There were zero other companion jobs anywhere on the machine — across all 37 workspace state dirs — within ±5 minutes of it, and it failed identically. So this is not a thundering-herd effect that a concurrency limit upstream of the plugin can avoid; the window is simply wide enough on Windows that an ordinary single dispatch loses it. Anyone working around this by capping their own fan-out width (as we initially did) will still see it.

The child needs far less than that to reach its read. Running the worker in the foreground against a job id that has no record:

$ node scripts/codex-companion.mjs task-worker --cwd <workspace> --job-id task-doesnotexist-zzzzzz
No stored job found for task-doesnotexist-zzzzzz.
exit 1, elapsed 327 ms

So boot-to-readStoredJob is ~327 ms while the parent took 716-878 ms to write the record — the worker reads ~390-550 ms before the file exists. The race is not narrow on Windows under load; spawn() returning is what is slow, and the parent does its writeJobFile after that.

Both jobs match the predicted artifact exactly: status: "queued", startedAt: null, errorMessage: null, a dead recorded pid, and a log containing only

[2026-08-10T09:28:29.482Z] Starting Codex Task.
[2026-08-10T09:28:29.482Z] Queued for background execution.

The job JSON's mtime never moves after the parent's write. That rules out any failure after runTrackedJob's first write succeeded — lib/tracked-jobs.mjs:151-152 writes the running record unconditionally as its first action, so a post-read failure would have stamped the file. It does not by itself rule out a throw from that write itself, which would leave an identical artifact; the timing arithmetic above is what distinguishes the two, and the pre-try placement of those lines is a separate defect either way (below).

One addition to the fix: those first two writes at tracked-jobs.mjs:151-152 sit outside the function's own try/catch, so even after the ordering is corrected, a throw there still produces this same silent permanently-queued record. Moving them inside the try would close the remaining route to the artifact.