Error running remote compact task identifies the stage that failed, not the system that caused it. Codex was trying to compress an older, long conversation into a smaller continuation state. A dropped stream, timed-out request, unsupported provider route, invalid parameter, oversized context, policy block, response-parsing problem, or child process that never exits can all appear behind the same wrapper.
Do not begin by deleting .codex, signing out, switching models, changing networks, and opening duplicate chats. Preserve the evidence first: copy the entire message, note the Codex surface and version, inspect the repository diff and untracked files, and check whether the last command or remote job is still running. A failed compaction does not prove that the work immediately before it was rolled back. Before repeating any write, check for partial completion.
The suffix is the diagnostic payload
Use the text after the wrapper to choose the first boundary to test. These are conditional interpretations, not one-to-one guarantees.
| Message after the wrapper | Boundary worth testing first | Bounded next action |
|---|---|---|
stream disconnected before completion or stream closed before response.completed | Streaming transport between the Codex host and service; proxy, VPN, remote-host network, or client build | Resume the same session once without changing account, model, or project; compare the last visible event |
request timed out or a temporary-demand message | One compaction request exceeded its wait or the route was briefly unavailable | Wait briefly, then make one same-route retry; do not start a retry storm |
404 Not Found | The configured base URL does not expose the compact route, or the client and provider contracts disagree | Identify the actual provider/base URL and verify explicit compaction support |
Unknown parameter, service_tier, variant, or output-shape error | Client/provider/model parameter compatibility or a proxy translating the request/response incorrectly | Keep the model fixed and retain the complete response body; test the smallest matching route |
input exceeds ... context window or ran out of room | The compaction request itself no longer fits, or the selected model/context contract differs | Produce a short handoff of decisions, changed files, checks, risks, and next step before starting a fresh chat |
Request blocked or an explicit safety/policy message | The compaction input was rejected rather than lost in transport | Reduce the reproduction to the smallest relevant content; repeated identical retries are not a network test |
timeout waiting for child process to exit | A local or remote subprocess is keeping the operation open | Inspect the last command for a watcher, dev server, stdin prompt, child tree, or unclosed handle |
If the UI shows only the wrapper, capture when it occurred and whether it followed automatic compaction or /compact. Add the session or request ID if one is shown. “It failed five times” is less useful than one complete suffix, one timestamp with timezone, and one last confirmed action.
Confirm which route is actually compacting the chat
OpenAI's Compact a response reference documents POST /responses/compact for the public Responses API. The current model compaction guidance describes the result as opaque continuation state: it is meant to be passed forward, not parsed as a durable summary format.
That public API contract does not make every Codex route interchangeable:
- A Codex session authenticated with ChatGPT uses the client and the corresponding ChatGPT service route.
- A direct OpenAI API-key session is governed by its model, project, endpoint, and account limits.
- A custom provider may implement ordinary
/responseswhile omitting/responses/compact, rejecting a parameter, or returning a different stream shape. - The desktop app, local terminal, container, WSL, and Remote SSH host can inherit different DNS, proxy, certificate, and environment settings.
A browser loading ChatGPT proves only that the browser route works. A normal model response proves only that the normal response route works. Neither proves that the process hosting Codex can complete compaction through the same provider contract.
Recover the session without destroying the explanation
The current Codex developer commands expose different controls for different questions. /status shows current session information. /compact compacts the current chat. codex resume continues an interactive session, while codex exec resume can continue eligible non-interactive work. codex doctor creates a diagnostic report, and /feedback opens a feedback path that can optionally include logs.
A useful recovery attempt has a before-state and one changed condition:
- Record file changes, active processes, remote jobs, and any write that may already have happened.
- Save the full error, timestamp, Codex version/surface, authentication route, provider/base URL, and session ID.
- If the suffix looks transient, resume the original session once with the same account, model, project, and route.
- If the suffix names a stable incompatibility—404, unsupported parameter, parsing, or child-process exit—change only that boundary.
- Test with a read-only or easily reversible instruction before returning to the original workload.
If every resume immediately re-enters the failed compaction, stop cycling. Create a handoff that contains the goal, completed work, decisions, changed files, verification already run, unresolved risks, and one next action. Then fork or start a new session from that state. This preserves task continuity even when the transcript itself cannot be recovered.
Why popular resets are weak first tests
Deleting caches or the whole .codex directory may remove session locators, configuration, and evidence along with a damaged state. It is appropriate only after the evidence points to a specific corrupt local object and you have a backup. Switching to a smaller or different model changes capability, context, and sometimes provider routing at once; a success afterward does not isolate the original cause. Increasing a timeout helps only when the same operation reliably completes just beyond the old boundary. It does nothing for 404, unsupported fields, crashes, policy blocks, or deadlocks.
If the complete message is actually HTTP 429 or a usage-window rejection, follow the separate Codex rate-limit diagnosis. If you cannot yet prove that compaction is the stalled stage, use the broader Codex timeout boundary guide. If the evidence moves to command network access, provider settings, or configuration precedence, continue with the Codex sandbox and config guide.
Escalate with a small, useful record
Keep the report narrow: Codex version and surface, operating system, authentication type, provider/base URL with secrets removed, full error and timestamp, session/request ID, the last completed action, whether automatic or manual compaction triggered it, a minimal reproduction, and a redacted relevant log excerpt. Do not attach tokens, private prompts, source code, email addresses, or full configuration files unless a support channel explicitly needs a sanitized fragment.
The safe question is not “How many times should I retry?” It is “Which boundary does the suffix name, and what single reversible test will confirm or eliminate it?” Preserve the work first; let the next attempt produce evidence as well as progress.
