Loading today’s stories
Build1 distinct publisher3 min readPublished
A dev.to author stopped believing Codex's completion reports and made the shell record them instead, in three files per task with three states and a captured git status. It holds up, as long as each worker gets its own worktree.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
AgentCheck reviews what the agent actually changed, and does it without another model1 distinct publisher
build
A cost monitor overcounted 4.9x, then went dark for a week when set -e did its job1 distinct publisher
build
Twenty-three security checks, zero coverage: AI coding agents as build-pipeline attack surface1 distinct publisher
build
Five coding agents on one repo is a staffing problem, and worktrees only fix the filesystem1 distinct publisher
The load-bearing detail is authorship. The model does not write the status file; the wrapper does, around the `codex exec` call, using a `write_status` function that cats a heredoc over the path it was handed [12][16]. So the recorded fact is not "the agent believes it finished" but "the process exited zero, and here is the tree afterwards" [1]. That is a much smaller claim than a completion report, and small claims are the checkable ones. The post's framing is that `cat status-file` output cannot be forged [17], which is true of the file and is really a statement about who holds the pen.
The recorded identity is a branch name. `write_status` stamps State, Updated, Branch from `git rev-parse --abbrev-ref HEAD`, and Worktree from `$(pwd)` [16]. A branch name does not move when work lands; a commit id does. The missing commit is exactly the case these fields cannot detect [1][2], and the `git status --short` capture does not cover it either, because git prints nothing for a clean tree, so "committed everything" and "touched nothing" render identically [3]. Recording HEAD's SHA on each write closes that for the price of one more `git rev-parse`.
The post says several workers can share a directory as long as each owns its own task, handoff and status files [9]. That claim holds for clobbering but not for the evidence: `codex exec` runs with `-C $(pwd)` [12], so concurrent workers share one tree, and the `git status --short` block copied into each handoff [13] is a snapshot of everybody's edits [4]. The Worktree field already names the fix.
Two requirements in the error handling pull against each other. The failure path writes a handoff note and `State: failed` before exiting 1 [14], which only runs if the `codex exec` call is guarded with `if` or `||`; under `set -e` an unguarded non-zero exit ends the script before the branch is reached [6]. And of the three states, two are terminal [8], so a worker killed by an OOM or a reboot leaves `State: running` behind forever. A poller therefore reads State plus Updated and applies a staleness threshold [5]. The timestamp is already in the record [10][16], which suggests the author met this one in production.
The number only transfers to your setup if your runner's exit code correlates with whether the work happened, if the four handoff sections are produced by the run rather than echoed from the task file [7], and if someone downstream actually opens the file. What this verifies is narrower than correctness: it replaces a sentence in a transcript with a short list of artifacts a shell can read [17], which is a narrowing worth having. One thing it does not narrow: the invocation is `codex exec -p yolo` [12], and the post never says what that profile permits, so the trust the design withholds from the model's own report ends up placed in the profile flag instead.
Ranked by verification strength, evidence, and original report placement.
The author of a dev.to post writes that after delegating tasks to Codex and receiving "Completed", checking the code showed the critical change was not there, a different file had been touched, or git commit had never run.
The same post says the problem is not specific to Codex: with Claude Code, and even with code the author wrote himself, running a self-audit right after a completion declaration turns up something every single time.
The design rule stated in the post: even if the AI says completed, it is not complete unless the line State: completed exists in the status file.
The post states that if the handoff file does not contain the real output of git status --short, you do not know what changed.
The script is invoked as: bash scripts/orchestrate-codex-worker.sh <task-file> <handoff-file> <status-file>, taking three arguments up front.
Roles of the three files: the task file contains only what to do; the handoff file is the note written on success or failure alike for the next reader (the next Claude Code session, or the author); the status file is machine-readable progress state.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 29, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Code on the page, anecdote behind it
The verifiable half is genuinely verifiable: dev.to prints write_status in full and the worker prompt in full, so the recording mechanism can be read rather than believed. The half that carries the argument is not. The missing change, the wrong file, the absent commit are one developer's recollection with no logs or diffs, and the piece breaks off mid-sentence before the codex exec line and its failure branch appear as actual code — the one place where set -e and a failed status write have to be reconciled.
One developer's machine
Nothing in this reporting travels past its author. There is no repository link, no other user, no count of tasks run, no team that adopted the three-file convention — only a script described by the person who wrote it for himself. We would rather say so than convert a first-person write-up into a usage number.
"Files don't lie" outruns the files
The phrase doing the most work — cat on a status file cannot be forged — is true and beside the point. A record holding a branch name and no commit id cannot answer the no-commit-at-all failure that started the exercise, and git status --short falls equally silent whether every edit was committed or none was made. Same for non-interference: separate bookkeeping files keep workers from clobbering each other's notes, not from appearing in each other's evidence. Moving the completion flag out of the model's prose is a real improvement; it is a narrower one than the writing claims.
Own byline, own script, nothing for sale
The pressures here are ordinary developer-blog pressures: a clean narrative arc, a memorable slogan, an implicit case that the author's tooling instincts are worth following. There is no product being pitched and no vendor relationship in view — and tellingly, the post names a gpt-5.4 model and a yolo permission profile without explaining either, the sort of loose end a sponsored write-up would have tidied.
Checkable design, unchecked story
What we can check, we can check thoroughly — the code is right there, and the design's limits follow from it. Everything else is a single publisher, a single author, no replication, and a listing that stops short. Our most useful observations in this story come from reading Git and Bash semantics against the printed script, not from anything a second source confirmed, and that is a thinner footing than it feels like.