Advanced · 7 min read
Recover an interrupted Codex task without losing work
Preserve the work, identify the failing layer, and recover with a bounded next step instead of repeating the same failed action.
For users comfortable inspecting local files and error messages. Historical Windows evidence is dated below; it is not a claim about every current release.
An interrupted response does not tell you whether a file edit or external action completed. Check the result first, then diagnose the connection, tool, or project failure.
1. Find out what already happened
Save the exact error text, the approximate time, your client and version, and the action that was running. Inspect the working files and Git diff before repeating an edit. If a publish, submission, or other external action was interrupted, read back the destination before trying again.
Keep private prompts, tokens, cookies, and account details out of a public report. You usually need the error signature and a minimal reproduction, not a complete transcript of the project.
git status --short --branch
git diff --stat2. Identify the failing layer
Use the smallest check that separates competing explanations. If only one project command fails, inspect that command and its environment. If unrelated tasks fail with the same transport error in the same time window, investigate the shared connection or service path before rewriting project code.
| What you see | What to check first |
|---|---|
| A test reports an assertion or type error | The changed code, test output, and repository configuration. |
| A tool is absent or permission is denied | Whether this session provides the tool and permits the requested action. |
| A stream disconnects or a response cannot be decoded | The service status and local connection path; preserve the exact message. |
| A web page times out | Whether the page failed, the browser connection failed, or the whole app exited. |
3. A dated case: remote compact failed
On July 23, 2026, our Windows notes recorded two unrelated project tasks stopping with the same 'Error running remote compact task' response-decoding error in Codex App 26.715.10079.0. The simultaneous failures made a shared transport problem more plausible than two independent code defects. That was a diagnostic inference, not proof of a particular server-side cause.
The user temporarily recovered by fully exiting Codex, restarting it, reopening the affected task, and asking it to continue. This is a historical local workaround. We have not reproduced that incident on the current release or established an official fix, so restarting is not presented here as a guaranteed repair.
Our July 23 reproduction was added as a comment to an earlier public compression-disconnect report. That comment records the failure evidence; it is not an official fix announcement. If your symptoms differ, use the diagnostic steps rather than applying the old workaround automatically.
4. Recover once, then reassess
Check the official service status and current troubleshooting guidance. Before restarting an app, preserve unfinished work and any unsaved form or generated result. Reopen the intended project, inspect its state, and attempt one small continuation that can demonstrate recovery.
If the same failure returns, stop repeating it. Record whether it affects another harmless task, whether a tool is missing or merely timing out, and whether the previous action left a result. Do not weaken security settings or change credentials solely because a transport error appeared.
Reference: OpenAI Status · OpenAI: Codex troubleshooting
5. Verify the original operation
A different tool succeeding can let you finish the task, but it does not prove that the original route recovered. Try the original harmless operation again when appropriate, or state that it remains unavailable. For a compaction interruption, continuing a short message alone does not establish that the next compaction will succeed.
If you report the issue, include the client, operating system, version, exact error, a small reproduction, and what the bounded retry changed. State what you could not test. This produces a more useful report than 'Codex is broken.'
Try it in Codex
Start with a read-only diagnosis
Help diagnose the interrupted operation in this task. Start read-only.
Record the exact error and identify the client, project, and affected action from available evidence. Inspect current files and Git state to determine whether a previous edit persisted. If an external action may have completed, verify its destination before proposing a retry.
Distinguish project errors, unavailable tools or permissions, and transport failures. Suggest the smallest safe check that separates these causes. Preserve unsaved work. Do not reset files, delete state, change credentials or security settings, restart apps, or repeat external writes. Report observations separately from hypotheses.Read the prompt before sending it. Copying does not run it.
Check your result
- You know which action failed and which results already exist.
- The diagnosis separates observed evidence from a suspected cause.
- Any retry is bounded and its outcome is recorded.
- A temporary workaround is clearly distinguished from a verified repair.
Sources and scope
Official references support the product behavior described above. The task prompts and practical checks are our community guidance.
- OpenAI StatusCheck for a service incident at the time you encounter a failure; a green status page does not rule out a local problem.
- OpenAI: Codex troubleshootingOfficial troubleshooting guidance; the July incident above is a separate community observation.
- Our July 23 compression-disconnect reproductionPublic user-reported Windows evidence added to an earlier Issue. The temporary restart result is from our local notes; neither establishes an official fix.
Something changed in your version? Send a correction with the guide URL, platform, and version. Leave out credentials and private project content.