When a task --write dispatch fails to land any workspace writes (e.g. the Windows sandbox denies apply_patch and all fallback writes — see openai/codex #30712/#31220/#32314), the companion still records the job as status: "completed" with touchedFiles: []. The orchestrating agent only learns of the loss from the model's prose.
Observed in production (companion 1.0.4, Windows 11, codex-cli 0.144.4): a write-mode rescue job ran ~6 minutes, every write path was denied by the sandbox, zero files landed — and the job record read status: "completed", so the coordinator dispatched follow-up work on the assumption the edits existed.
Suggested behavior: detect zero-write completion mechanically and surface the job as failed/degraded so callers see the loss without parsing prose. Note that touchedFiles alone is insufficient as a signal — it only tracks apply_patch file-change events, so shell-based writes (the common Windows fallback while the sandbox split-root issue stands) need a working-tree fingerprint comparison to avoid false positives.
Happy to submit a PR — implementation plus tests are ready (working-tree fingerprint before the turn; job marked failed with result.degraded: "zero-writes" and a DEGRADED banner when a write turn ends with no apply_patch changes and an unchanged fingerprint; shell-only writes and already-dirty-file edits covered; non-git workspaces skip detection).
When a
task --writedispatch fails to land any workspace writes (e.g. the Windows sandbox deniesapply_patchand all fallback writes — see openai/codex #30712/#31220/#32314), the companion still records the job asstatus: "completed"withtouchedFiles: []. The orchestrating agent only learns of the loss from the model's prose.Observed in production (companion 1.0.4, Windows 11, codex-cli 0.144.4): a write-mode rescue job ran ~6 minutes, every write path was denied by the sandbox, zero files landed — and the job record read
status: "completed", so the coordinator dispatched follow-up work on the assumption the edits existed.Suggested behavior: detect zero-write completion mechanically and surface the job as failed/degraded so callers see the loss without parsing prose. Note that
touchedFilesalone is insufficient as a signal — it only tracksapply_patchfile-change events, so shell-based writes (the common Windows fallback while the sandbox split-root issue stands) need a working-tree fingerprint comparison to avoid false positives.Happy to submit a PR — implementation plus tests are ready (working-tree fingerprint before the turn; job marked failed with
result.degraded: "zero-writes"and a DEGRADED banner when a write turn ends with no apply_patch changes and an unchanged fingerprint; shell-only writes and already-dirty-file edits covered; non-git workspaces skip detection).