Observation
During a 2026-08-12 fix-issue-batch run in obsidian-vault (plugin 1.0.46), an agent driving codex-companion.mjs deep-review background jobs observed, on more than one round, the job terminating with status: failed and an empty .storedJob.rendered in the result --json payload — while the job log showed the Codex review turn had completed and produced real findings (including a high-severity one). The agent recovered all three rounds' findings by parsing the job log directly.
A separate, possibly related shape seen in the same run: a review that completed was then discarded by the runtime with failureClass: state-drift ("base ref main moved") because the repo's sidecar pushes to main every few minutes. That path at least surfaces an errorMessage; the empty-rendered path does not, so a caller following the documented flow (read .storedJob.rendered, report failure otherwise) would report "review unavailable" and silently lose findings that exist in the log.
Impact
Review findings that were actually produced are droppable by the happy-path client contract. In an orchestrated run, that turns a high-severity correctness finding into a "review unavailable" note.
Scope (non-prescriptive)
- Whether
rendered should be populated (or the raw turn output referenced) whenever the underlying review turn completed, regardless of the job's terminal classification.
- Whether state-drift discards should retain the review text alongside the error instead of discarding the result.
- Repro pointers: obsidian-vault worktree jobs from 2026-08-12 under
~/.claude/plugins/data/codex-patricks-plugins/state/obsidian-vault-issue-670-*/jobs/ (agent recovered findings from those logs).
Found during an obsidian-vault batch run; filed here because the defect is in the plugin's job/result layer, not the vault repo.
Observation
During a 2026-08-12 fix-issue-batch run in obsidian-vault (plugin 1.0.46), an agent driving
codex-companion.mjs deep-reviewbackground jobs observed, on more than one round, the job terminating withstatus: failedand an empty.storedJob.renderedin theresult --jsonpayload — while the job log showed the Codex review turn had completed and produced real findings (including a high-severity one). The agent recovered all three rounds' findings by parsing the job log directly.A separate, possibly related shape seen in the same run: a review that completed was then discarded by the runtime with
failureClass: state-drift("base ref main moved") because the repo's sidecar pushes to main every few minutes. That path at least surfaces an errorMessage; the empty-rendered path does not, so a caller following the documented flow (read.storedJob.rendered, report failure otherwise) would report "review unavailable" and silently lose findings that exist in the log.Impact
Review findings that were actually produced are droppable by the happy-path client contract. In an orchestrated run, that turns a high-severity correctness finding into a "review unavailable" note.
Scope (non-prescriptive)
renderedshould be populated (or the raw turn output referenced) whenever the underlying review turn completed, regardless of the job's terminal classification.~/.claude/plugins/data/codex-patricks-plugins/state/obsidian-vault-issue-670-*/jobs/(agent recovered findings from those logs).Found during an obsidian-vault batch run; filed here because the defect is in the plugin's job/result layer, not the vault repo.