openai / openai/codex-plugin-cc
codex-companion: workspace-keyed job registry returns 'No job found' for completed jobs when cwd drifts into a git repo
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 33.3k
- Forks
- 2.3k
- PR merge metrics
- No merged PRs in 30d
Description
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'.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing workspace resolution in scripts/lib/state.mjs and scripts/lib/workspace.mjs, then inspect state.json and jobs/.json handling. Reproduce status and result lookups after cwd changes, and review loadState, upsertJob, and saveState for the listed persistence concerns. Done should define the intended lookup, error details, and job-result failure signals without leaving history silently lost.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- git, javascript
- Domain
- cli, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 45/100