Summary
The background-job state machine (used by /codex:rescue, /codex:status,
/codex:cancel) appears to retain completed/failed job entries
indefinitely. Re-invoking with --background --fresh does not clear or
recycle these zombie entries, so subsequent runs can see and act on stale
state.
Reproduction
Environment:
- Windows 10 / 11
@openai/codex-plugin-cc 1.0.5
Steps:
- Run a Codex rescue task to completion via
codex:rescue --model gpt-5.5 --effort high --background.
- Wait until it shows
status: completed.
- Start a new task with
--background --fresh.
- Run
/codex:status — the previously-completed job is still listed,
and in some cases its job id is reused or its state bleeds into the
new run's status reporting.
Suggested fix
- Auto-GC
completed / failed job entries after N minutes (e.g. 30 min).
- Have
--fresh actively wipe terminal-state job entries before starting
the new run, not just decline to resume.
Happy to clarify with logs if useful — the state files live under
~/.claude/plugins/data/codex-openai-codex/state/....
Summary
The background-job state machine (used by
/codex:rescue,/codex:status,/codex:cancel) appears to retain completed/failed job entriesindefinitely. Re-invoking with
--background --freshdoes not clear orrecycle these zombie entries, so subsequent runs can see and act on stale
state.
Reproduction
Environment:
@openai/codex-plugin-cc1.0.5Steps:
codex:rescue --model gpt-5.5 --effort high --background.status: completed.--background --fresh./codex:status— the previously-completed job is still listed,and in some cases its job id is reused or its state bleeds into the
new run's status reporting.
Suggested fix
completed/failedjob entries after N minutes (e.g. 30 min).--freshactively wipe terminal-state job entries before startingthe new run, not just decline to resume.
Happy to clarify with logs if useful — the state files live under
~/.claude/plugins/data/codex-openai-codex/state/....