In codex-companion (openai-codex plugin 1.0.6), status <job-id> and result <job-id> resolve jobs exclusively through the workspace-scoped state.json registry, whose directory key is derived from the git toplevel of the current cwd (scripts/lib/state.mjs resolveStateDir, scripts/lib/workspace.mjs). If the same command is run from a subdirectory that happens to be a different git repo, the lookup targets a different (usually empty) registry and fails with 'No job found for ""' even though jobs/.json with the full result exists in the sibling workspace state dir - a confusing failure for orchestrators whose cwd drifts between calls. Suggested fixes: fall back to a direct jobs/.json existence check (per-workspace or across workspace dirs) before reporting 'No job found', and/or include the resolved workspace root and state-dir path in the error message. Related robustness gaps in the same store: loadState silently swallows JSON parse errors and returns an empty registry, state.json is written non-atomically with no cross-process locking despite concurrent detached task-workers doing read-modify-write via upsertJob, and saveState deletes job .json/.log files as a side effect of any prune - so a single torn or lost write can silently orphan or destroy job history. Separately, a task job's result.rawOutput is the model's final message stored verbatim with exit status derived only from turn completion, so a turn that achieved nothing (e.g. a nested codex exec resume blocked by the read-only sandbox) still yields status 0 with fabricated content as the job result; consider surfacing commandExecutions/failure signals in the stored result so callers can distinguish 'turn ended' from 'work performed'.
In codex-companion (openai-codex plugin 1.0.6),
status <job-id>andresult <job-id>resolve jobs exclusively through the workspace-scoped state.json registry, whose directory key is derived from the git toplevel of the current cwd (scripts/lib/state.mjs resolveStateDir, scripts/lib/workspace.mjs). If the same command is run from a subdirectory that happens to be a different git repo, the lookup targets a different (usually empty) registry and fails with 'No job found for ""' even though jobs/.json with the full result exists in the sibling workspace state dir - a confusing failure for orchestrators whose cwd drifts between calls. Suggested fixes: fall back to a direct jobs/.json existence check (per-workspace or across workspace dirs) before reporting 'No job found', and/or include the resolved workspace root and state-dir path in the error message. Related robustness gaps in the same store: loadState silently swallows JSON parse errors and returns an empty registry, state.json is written non-atomically with no cross-process locking despite concurrent detached task-workers doing read-modify-write via upsertJob, and saveState deletes job .json/.log files as a side effect of any prune - so a single torn or lost write can silently orphan or destroy job history. Separately, a task job's result.rawOutput is the model's final message stored verbatim with exit status derived only from turn completion, so a turn that achieved nothing (e.g. a nestedcodex exec resumeblocked by the read-only sandbox) still yields status 0 with fabricated content as the job result; consider surfacing commandExecutions/failure signals in the stored result so callers can distinguish 'turn ended' from 'work performed'.