Codex Background Tasks: Why Completed Jobs Cannot Be Resumed Directly

Imagine a workflow where a task is delegated to Codex inside Claude Code for work within a shared code repository. After some time, users run the /codex:result command and receive output, intending to continue modifying the same codebase. This operation carries a hidden risk: there is no guarantee the returned result comes from the target task. Developers need to validate which job the output belongs to, whether the task fully succeeded, and if the returned code matches the current state of the repository.

This article analyzes the underlying logic of openai/codex-plugin-cc. When users fetch results, the plugin only locates matching task end records. Before continuing work with these outputs, teams must verify job identity, termination status, and the active workspace. Switching back to Codex to resume work imports a separate set of context. The analysis draws from offline controlled experiments: the official job selection function runs with manually constructed local records, without live model workers or real conversation migration. The fixed source commit for validation is db52e28f4d9ded852ab3942cea316258ae4ef346. All tests were completed on September 20, 2026. This analysis does not generalize findings to all Codex product variants.

A Retrieved Result May Belong to the Most Recent Failed Task

A Completed Task Record Does Not Equal Successful Execution

Within a single conversation session, two finished task records can coexist: an older entry marked completed, and a newer entry marked failed. When calling the official resolveResultJob function without supplying a job ID, the plugin will return the newer failed record by default.

Manual Input	Actual Return from Official Function
Same conversation: older job-a-old completed, newer job-a-new failed	Default result selects job-a-new, status: failed
Single entry job-cancelled, status cancelled	Specified ID result can fetch this record

The plugin’s job-control.mjs filter accepts three terminal states: completed, failed, and cancelled. When no ID is passed, the system filters records by the active conversation, then sorts entries using updatedAt, returning the newest terminated task.

A result output does not automatically confirm task success. Subsequent processing reads file outputs and error logs stored in the record, but it does not re-run validation to confirm genuine successful model execution. This offline experiment only tests record selection logic and does not fabricate fake successful model responses.

Standard Verification Workflow

When starting a task, preserve the returned job-id. Use this identifier for all subsequent queries:

/codex:status <job-id>
/codex:result <job-id>

Replace <job-id> with the real task identifier. Validate status first, examine outputs and errors, then judge whether the task supports further operations. The native success field in the codebase is completed. Do not confuse this with custom status labels like succeeded.

Two Windows for the Same Repository Do Not Share The Same Task Table

Another common misconception: multiple Claude Code windows accessing one repository see identical task lists. In practice, task records are filtered by active conversation context.

In the offline test setup, two conversation sessions were created: Session A holds two active jobs, Session B holds one active task. The environment sets the current conversation ID to Session A.
When calling buildStatusSnapshot(..., {all: true}), the active task list only returns Session A’s two jobs. Session B’s task is hidden. However, calling buildSingleJobSnapshot with the full job ID from Session B successfully retrieves the isolated task record.

Two distinct retrieval paths exist. Queries without an ID filter records against the current conversation. Queries with an explicit job ID match records against the task list of the workspace, ignoring conversation scope. The --all flag only expands the total number of entries loaded, and does not remove conversation filtering. Without a valid current conversation context variable, the default list skips cross-session records.

This behavior explains a frequent confusion: after switching Claude Code windows, missing tasks do not mean records are deleted. Confirm the active workspace first. Explicit ID lookups can bypass conversation filtering, which proves this mechanism acts as scope filtering rather than account permission isolation.

This filtering rule also affects task cancellation. In the experiment, Session A contained two running Codex jobs. Calling the native cancel function without a job ID returns the following warning:

Multiple Codex jobs are active. Pass a job id to /codex:cancel.

This raw error output comes from offline test runs; no actual cancellation operation executes. The plugin requires explicit task selection and cannot guess the intended target job automatically.

Cancelled Records Cannot Replace File System Validation

Local Cancellation ≠ Remote Confirmation

When users trigger task cancellation, the workflow proceeds through three stages:

1. Attempt task interruption
2. Terminate job.pid for the corresponding process tree
3. Write the cancelled state to local records

Source code fields for cancelled tasks include status: "cancelled", turnInterruptAttempted, and turnInterrupted. Static code review shows the handleCancel function reads thread and turn identifiers, attempts interruption, terminates the process tree, then updates the local job entry to cancelled.

The critical limitation: this workflow contains no built-in Git rollback logic for the workspace. Even when interruption attempts fail, the system can still write the cancelled state locally. The cancelled flag alone cannot prove the remote turn acknowledged termination, nor confirm modified files have been restored to their original state. This conclusion comes from static source review; the experiment did not run live termination or remote interruption tests.

Returning to the repository workflow example: if file modifications were permitted during investigation, users must inspect current files after cancellation before deciding to retain or revert changes. Use these shell commands to inspect repository state:

git status --short
git diff --stat
git diff --cached --stat

The two diff commands inspect unstaged and staged file changes respectively. The status output lists modified files, and further diff review exposes content changes. These commands help confirm repository state, though they cannot capture all external side effects. Never run destructive commands simply because a task was cancelled.

For records marked completed, the flag only indicates the task reached its terminal state. Output references may remain valuable even if the task partially failed. The worst case is silent partial success, where file changes expand far beyond the intended scope, requiring full re-review. It is unnecessary to rebuild the full background task every time.

Resume Existing Jobs or Transfer Conversations

Two separate operations control task continuation: resume and transfer.

1. resume: Continue an existing Codex investigation within the same conversation
2. transfer: Import a Codex thread into a separate Claude conversation

Before resuming work, validate the current file state first.
For ongoing Codex investigations within the same conversation, use /codex:resume. The fixed version of the command requires confirmation of the selected Claude conversation’s resumable records. Without explicit resume or fresh parameters, the prompt forces users to select or rebuild background task state. The command converts work into background task execution, controlling how Claude Code subagents operate.

For cross-conversation handoff, transfer imports the Codex thread ID into a new Claude session:

/codex:transfer <thread-id>

The import loads the Codex runtime project, reads the .json metadata file, and imports source code references. If the thread is not found, the system returns an error. The transfer operation does not automatically migrate Git workspace changes or full file modifications. It imports metadata only. A transfer success response does not guarantee all file state is fully replicated in the new conversation.

When teams manage multi-agent workflows with many Codex and Claude Code sessions, unified request routing can reduce complexity. 4sapi acts as an API gateway to centralize credential and traffic management across multi-model agent pipelines.

Document Handoff: Generate Verifiable Transfer Notes

When handing tasks between sessions, preserve structured verifiable records rather than only passing final outputs. The template below defines key handoff fields:

• Goal: What question the investigation intends to resolve
• Input: The starting repository state and baseline code
• Current: job-id, timestamp, and active workspace
• Changes: Which files have been modified
• Conclusion: Critical findings and unresolved risks
• Next steps: Who continues the task, and what edits are permitted

The commit hash from git rev-parse HEAD can record the starting commit point. However, HEAD alone cannot represent uncommitted edits. Separate records must capture staged and unstaged diffs, as well as newly added untracked files. A handoff note only provides a starting reference point; the receiving developer must re-verify the current working tree.

If a task only performs read-only investigation and leaves files unchanged, validation is simpler. If edits occurred during execution, or the workspace has switched, inspect file and job status before restoring conversation.

When invoking /codex:result, always reference the original job-id captured at task startup. Only matching identifiers confirm that outputs belong to the target task.

Conclusion

Codex task completion status stored in plugin records is not sufficient proof for safe workflow continuation. Developers must validate job identifiers, task terminal states, and the actual filesystem changes in the repository. The plugin’s default behavior returns the newest terminated record without ID filtering, which can accidentally load failed task outputs.

Cancellation and completion status flags are metadata markers only. Neither status automatically reverts file modifications within the workspace. Cross-conversation transfer and resume operations carry scope limitations: they import metadata, but do not replicate full workspace state. Standardized handoff documentation and Git state inspection are required to safely continue work across sessions.

Offline experiments used the official plugin source repository and matching probe.mjs scripts, and all test outputs and local reproductions are retained. No live model workers or real conversation agents were invoked for these validation tests.

International access: https://4sapi.com
Domestic access: https://4sapi.cn