Error running remote compact task
What version of Codex CLI is running?
0.114.0
What subscription do you have?
Pro
Which model were you using?
gpt-5.4
What platform is your computer?
Linux 6.17.0-19-generic x86_64 x86_64
What terminal emulator and version are you using (if applicable)?
Codex CLI in terminal
What issue are you seeing?
Problem:
/compact fails after ~150s (30s timeout × 4 retries) with a misleading error message that obscures the real cause
Root cause:
original compact path does not set a per-request timeout; shared reqwest client inherits upstream defaults; reqwest sets Linux-family tcp_user_timeout to 30s
Proposed fix:
explicitly set a higher tcp_user_timeout in core/src/default_client.rs
Suggested diff:
diff --git a/codex-rs/core/src/default_client.rs b/codex-rs/core/src/default_client.rs
--- a/codex-rs/core/src/default_client.rs
+++ b/codex-rs/core/src/default_client.rs
@@
use std::sync::LazyLock;
use std::sync::Mutex;
use std::sync::RwLock;
+use std::time::Duration;
@@
pub const CODEX_INTERNAL_ORIGINATOR_OVERRIDE_ENV_VAR: &str = "CODEX_INTERNAL_ORIGINATOR_OVERRIDE";
pub const RESIDENCY_HEADER_NAME: &str = "x-openai-internal-codex-residency";
+const DEFAULT_TCP_USER_TIMEOUT: Duration = Duration::from_secs(120);
@@
let mut builder = reqwest::Client::builder()
.user_agent(ua)
.default_headers(default_headers());
+ // reqwest defaults tcp_user_timeout to 30s on Linux-family targets, which is too short
+ // for long-running unary requests such as remote compaction.
+ builder = builder.tcp_user_timeout(DEFAULT_TCP_USER_TIMEOUT);
if is_sandboxed() {
builder = builder.no_proxy();
}Additional notes:
- The error message
timeout waiting for child process to exitis misleading for this path and warrants a separate cleanup - Consider making this value overridable via
config.toml
What steps can reproduce the bug?
Platform: linux
APP: Codex CLI
Model: gpt-5.4
Keep using a context.. it will eventually get the error after filing to auto compact for ~150s Error running remote compact task: timeout waiting for child process to exit.
It compacts usually a 1-3 times okay before it stops being able to compact it.
What is the expected behavior?
That the system doesn't timeout each compact attempt in 30 seconds as that is not enough time for the API to finish.
Additional information
Hire me ;)
I chase bug relentlessly.
104 Comments
I should mention that I applied this fix on my local Codex CLI and it has solved the auto-compact and /compact issue for me. My compacts take about 45 to 65 second. I'm using 258K tokens in my
config.toml.I tried your fix - it works for me, now no any errors. Thank you!
Is there a fix for the VSCode extension on Windows? I couldn't locate the core/src/default_client.rs file. I attempted to compile the Codex CLI from source and configured VSCode to load my custom-built binary. After restarting, I returned to a previously failed session (where compression had crashed) to see if it would perform the "compact" behavior correctly. However, it didn't seem to work.
The background information auto-compaction still fails with the following output:
"Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)".
I’m not sure what went wrong. I suspect that a new session might be required to properly load the newly compiled CLI. I am currently testing this to see if the auto-compact bug persists after multiple compression attempts in a fresh session.
This issue still exists on 0.115.0. I'm getting the same problem you described. Running on Linux Mint. Did not have this issue operating on same giant codebase with same tasks on WIndows.
I can't guarantee it will work out for anyone else but, I tested this in case others are desperate.
So.. Codex is capable of making this modification on itself. I allowed it to get the repo, make the change, install everything it needed to compile, compile, and overwrite parts of its own installation. I'm on a VM I backed up before letting it try. Worked out first attempt though.
It would be so much better if someone with pull request powers saw this very tiny and safe change though.
That was my plan for tomorrow, I'll report back if it resolves it.
Same issue here — I’ve been seeing this ~150s timeout for months. This fix would definitely help. Thanks.
Thank you! This helped! I patched and rebuilt codex-cli 0.115.0, replaced the local binary, and /compact is working for me now on RHEL.
I'm glad I could help.
<img width="655" height="371" alt="Image" src="https://github.com/user-attachments/assets/44345b23-6c87-424c-a922-4cd51b33af78" /> 为啥，每次提问都会报这样的问题
may also be caused by a conflict between Codex CLI and the App, especially if you are using both at the same time.
It can happen when both tools operate on the same directory, which may lead to unexpected behavior or inconsistencies (for example, concurrent edits or state conflicts in the same workspace ).
You just need to isolate them.
The quickest solution is to uninstall everything and then reinstall only one of them.
Before uninstalling, you can create a backup. Then have another agent restore only the chat history from the backup (do not restore any non-chat data).
Just a thought — that looks like a openai timeout failure. Could be worth a quick npx ai-doctor run to see what it flags.
There might be settings to control the timeout for the config.toml .. but this was for a different OS, so maybe not https://github.com/openai/codex/issues/14559#issuecomment-4109480635
EDIT: I've confirmed creating a provider and setting it timeout works
@etraut-openai The timeout issues on compact can be corrected as weidonyoung provided here: https://github.com/openai/codex/issues/14559#issuecomment-4109480635
The default
openaiprovider just needs it's timeout extendedstream_idle_timeout_ms = 120000. I chose 120 seconds for the example because I have seen a 76 second compact. 90 is probably also viable.Verified on Windows 11 and Ubuntu 24.04
I don't think that's a great solution. It papers over an underlying latency issue. We have been working on fixing the root cause.
I understand the concern, but this is not just papering over the issue.
From the issue details, the current ~150s failure is the result of reqwest-related timeout behavior on this path, not just abstract latency. In practice, once that timeout is hit, the active session is disrupted badly enough that we often have to start a new session just to continue working.
I agree that fixing the root cause and reducing /compact latency is necessary. But right now, the highest priority should be eliminating the reqwest-driven 150s timeout itself. As long as that remains, the current session can still fail in a way that is highly disruptive to users.
I'm glad to hear you are working on the root cause.
It would be a good idea if some solution was pushed out in the interim for those that cannot make these changes I present themselves? This bug is crippling to those that are affected. Sometime a single big refactor can burn the whole context window and the next context will not be able to pick that up cleanly.
This issue is significantly impacting my ability to use the product.
It has been present since November 2025, which makes it hard to understand why such a critical bug in a consumer-facing product remains unresolved for so long.
I understand that you are working on the root cause, but from a user perspective, the current situation is not acceptable. I would really appreciate more transparency on the timeline or any interim mitigation.
I have found the fix. The issue was caused by a conflict between the Codex CLI, VS Code Codex extension, and the Codex app.
To resolve this, I uninstalled all Codex-related software from both the Windows and WSL2 environments. Meanwhile, I manually deleted the .codex folders located in the user directories of both systems. After restarting my computer, I performed a fresh installation of the Codex app only on the Windows side.
The software is now functioning perfectly, and the issues mentioned above have completely disappeared!
For me setting my reasoning down to "Low" and the speed to "Fast" got me through the compaction at just under 10 minutes, then I moved it back to high.
@etraut-openai any updates on a fix? or an option to return to the in-app compaction prompt? pretty disruptive, I'm hitting endpoint timeouts on every compaction at this point.
@ducky0518 this worked 😅
This bug is crippling. I'm having to start new sessions and piece together context for it every few minutes.
@ducky0518 's solution isn't working for me either.
The Codex app has an even tighter limit I think, ~80 seconds before I get the error.
I also encountered this problem. It exists on my Linux host, but not on Windows hosts
I have a ready fix for this in my fork, but
openai/codexis currentlycollaborators_onlyfor PR creation, so I cannot open the PR directly from my account.Branch:
minanagehsalalma:fix/remote-compact-timeout-recoveryCommit:
ea2504064Compare: https://github.com/openai/codex/compare/main...minanagehsalalma:fix/remote-compact-timeout-recovery?expand=1
Proposed PR title:
Fix remote compact timeout recoveryWhat the patch does:
CodexErr::RequestTimeoutso remote compaction reportsrequest timed outinstead of the unrelated child-process timeout messageValidation I ran locally:
compact_remote: 25 passed, 1 ignoredcompact_resume_fork: 4 passedrequest_compression: 4 passedPrebuilt binary handoff:
Credit:
If a collaborator is willing, please open the PR from the compare link above so this can be reviewed and linked back to this issue.
Small follow-up for routing: @aibrahim-oai and @jif-oai, this fix is ready on my fork and the compare resolves cleanly, but
openai/codexiscollaborators_onlyfor PR creation from my account.If one of you owns this path or can redirect it to the right owner, would you mind taking a look and opening the PR from this branch if it looks appropriate?
Compare: https://github.com/openai/codex/compare/main...minanagehsalalma:fix/remote-compact-timeout-recovery?expand=1
Credit should stay with @minanagehsalalma for the authored branch/commit.
Also experiencing this. But I'm erroring in ~1-3s, like it's not even attempting.
@coleski give the fix a try it been working good for me tho so far.
@minanagehsalalma didn't work for me. though i restarted my computer and that resolves for a while
@coleski I meant this https://github.com/minanagehsalalma/codex/releases/tag/remote-compact-timeout-recovery-ea2504064
FTW. @ducky0518 . Funciono. aun asi, dejo mi id de incidencia local para que lo solucionen 019d8403-543b-7602-813f-e5d4c694b02c
Problem still alive. I have it already 2 months...
The problem is still not resolved — that’s very strange. Does nobody at OpenAI use Linux themselves?
It lasted for half a year.
macos also encounters this problem, v0.120.0
My local fix for the Codex CLI issue was simply changing this in
~/.codex/config.toml:stream_idle_timeout_ms = 900000That bumps the wait timeout to 15 minutes as a local workaround. It works on my machine.
still facing the issue
Seems like the issue is fixed. Since today’s latest update, I haven’t experienced any context compacting errors, although context compacting itself has completed successfully many times. Is anyone still experiencing this issue?
@earnie-ou what exact version and system are you on?
@minanagehsalalma Codex Version 26.417.41555 (1858) for macOS
Nevermind. The issue is back today.
This issue has already made the entire program completely unusable. Because of this issue, Codex cannot handle any complex task and directly interrupts at the very first step. You must take action on this.
Do OpenAI’s own staff use Codex? Right now, the entire Codex product is completely unusable. It would be fair to say that Codex is functionally disabled. What I get in return for my Pro subscription fee is nothing but errors.
As a world-class company, your efficiency is undoubtedly extremely poor. I am deeply disappointed by this.
---
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)This error effectively prevents Codex from handling any real task.
It is fair to say that you have failed.
<html><head></head><body><h1>The Quiet Architecture of Neglect: A Professional Critique of OpenAI’s Operational Inaction</h1><h2>Executive Summary</h2><p>There are many ways for a technology company to fail. Some fail by lacking ambition. Some fail by misunderstanding the market. Some fail because their products are technically inferior, commercially irrelevant, or strategically incoherent.</p><p>OpenAI’s present failure is more subtle, and therefore more disappointing.</p><p>It is not a failure of imagination. It is not a failure of branding. It is not even, in the narrowest sense, a failure of technical possibility. OpenAI has repeatedly demonstrated that it possesses extraordinary research capacity, enormous infrastructure leverage, global visibility, elite engineering talent, and a user base willing to tolerate friction in exchange for frontier capability.</p><p>The failure lies elsewhere.</p><p>It lies in operational indifference.</p><p>It lies in the gap between what OpenAI claims its tools are becoming and what users actually experience when attempting to rely on them for serious work. It lies in products marketed as intelligent agents while behaving, under real workload conditions, like brittle prototypes waiting for permission to collapse. It lies in subscription models that imply premium reliability while delivering error messages with the regularity of a scheduled service. It lies in the extraordinary contradiction of a company presenting itself as a leader in autonomous software engineering while allowing its coding product to become functionally incapacitated by unresolved infrastructure defects.</p><p>Most importantly, it lies in the apparent absence of urgency.</p><p>When a tool such as Codex fails at the first step of complex work because of an error like:</p><pre><code class="language-text">Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
</code></pre><p>the issue is not merely cosmetic. It is not a minor inconvenience. It is not an edge case to be filed away beneath some polite internal label such as “intermittent degradation.”</p><p>It is a direct failure of the product’s core premise.</p><p>A coding agent that cannot preserve context, cannot complete compaction, cannot continue execution, and cannot survive ordinary complexity is not temporarily inconvenienced. It is operationally disabled. The user does not receive degraded intelligence. The user receives stoppage. Not imperfection, but interruption. Not reduced performance, but collapse.</p><p>And yet the most remarkable part is not the error itself. Software fails. Distributed systems fail. APIs fail. Networks fail. Reasonable users understand this. What is harder to understand is why a company of OpenAI’s scale, reputation, and resources permits such failures to persist in ways that make the product practically unusable, while continuing to charge premium subscription fees and project an image of technical inevitability.</p><p>This is not merely a product complaint.</p><p>It is a critique of institutional behavior.</p><hr><h2>1. The Difference Between Innovation and Reliability</h2><p>OpenAI has become exceptionally good at announcing the future.</p><p>The company knows how to present technological progress as destiny. It speaks fluently in the language of agents, autonomy, reasoning, intelligence, productivity, and transformation. It has positioned itself not simply as a software vendor, but as a central actor in the future of human-computer interaction.</p><p>That positioning creates obligations.</p><p>A company that sells entertainment software may get away with instability. A social application may survive temporary absurdity. A novelty tool may fail frequently and still remain amusing. But a professional coding agent is different. It is not a toy. It is not a demo. It is not a decorative assistant sitting politely beside the real workflow.</p><p>A coding agent is supposed to enter the workflow itself.</p><p>It touches repositories, reads architecture, modifies files, runs commands, reasons about dependencies, executes tests, and helps users complete work that may be commercial, urgent, and technically complex. Once a company asks users to treat such a system as part of their development process, reliability is no longer an optional polish layer. It becomes part of the product’s moral contract.</p><p>The issue, then, is not that Codex sometimes fails. The issue is that Codex appears insufficiently protected against predictable failure modes. The issue is that its operational design seems unable to sustain precisely the kind of complexity it is advertised to handle. The issue is that users are left staring at internal system errors while the company’s public narrative continues to speak as if the future has already been delivered.</p><p>There is a familiar pattern in modern AI product development: release the capability before the operational discipline catches up. This approach may be tolerable during an experimental preview. It becomes unacceptable when the product is folded into paid tiers, promoted as a serious assistant, and relied upon by users who are not paying for conceptual inspiration but for functioning software.</p><p>Reliability is not the enemy of innovation. Reliability is the point at which innovation becomes usable.</p><p>Without reliability, “agentic coding” is not a product category. It is a performance of ambition.</p><hr><h2>2. The Compact Task Error as a Symptom, Not an Accident</h2><p>The specific error concerning the remote compact task is especially revealing.</p><pre><code class="language-text">stream disconnected before completion
</code></pre><p>This phrase carries more meaning than it may appear to. It indicates not simply that a request failed, but that the system was engaged in a continuity-preserving operation and failed before completion. In a coding agent context, compaction is not a peripheral feature. It is part of the agent’s ability to manage long-running context, preserve continuity, and continue reasoning across complex tasks.</p><p>When that process fails, the agent does not merely lose elegance. It loses working memory. It loses continuity. It loses the capacity to handle complexity over time.</p><p>This is why the problem is so severe. A coding assistant that fails to compact context cannot reliably sustain meaningful work on large projects. It may still answer small questions. It may still perform trivial edits. It may still create the illusion of usefulness in simple cases. But the moment the task requires persistence, accumulation, cross-file reasoning, or multi-step execution, the system begins to fracture.</p><p>This is not a minor backend hiccup. It is a core architectural failure surfacing as a runtime error.</p><p>To users, however, the distinction hardly matters. Whether the root cause is a streaming transport failure, request timeout, backend instability, insufficient retry logic, poor session recovery, brittle state management, or flawed task orchestration, the result is identical: Codex stops functioning. The user’s work stops with it.</p><p>And this is where OpenAI’s inaction becomes difficult to excuse.</p><p>A serious engineering organization should treat this class of failure as high severity. Not because every individual user complaint is automatically catastrophic, but because the failure attacks the product’s central value proposition. It prevents the agent from doing the thing users are paying it to do.</p><p>In mature software operations, there is a basic distinction between defects that inconvenience a feature and defects that invalidate the product. This issue belongs to the second category.</p><p>If Codex cannot reliably handle complex tasks because its own context-management path breaks, then the product is not merely buggy. It is structurally unreliable.</p><hr><h2>3. The Irony of a Coding Agent That Cannot Recover</h2><p>The deepest irony is almost too obvious to mention, which is precisely why it must be mentioned.</p><p>Codex is supposed to help users handle software complexity. Yet when Codex encounters its own operational complexity, it often appears unable to recover gracefully.</p><p>A human developer would be criticized for building software that fails without retry, without fallback, without diagnostic clarity, without graceful degradation, and without meaningful recovery. A senior engineer reviewing such a system would ask obvious questions:</p><ul><li><p>Why is the failure not retried?</p></li><li><p>Why is there no resumable state?</p></li><li><p>Why is the user not given a recovery option?</p></li><li><p>Why does one backend operation terminate the entire task?</p></li><li><p>Why is the error exposed in such a raw and unhelpful form?</p></li><li><p>Why is there no local fallback or partial continuation path?</p></li><li><p>Why does the product fail at precisely the point where continuity matters most?</p></li></ul><p>These are not exotic questions. They are elementary reliability questions.</p><p>And yet the user experience suggests that Codex itself is not being held to the engineering standards it is supposed to help others maintain. It is apparently capable of advising users about robust system design while failing to embody those principles in its own execution path.</p><p>This produces a kind of institutional absurdity: a company teaching the world how software will be written in the future while delivering a coding tool that can be defeated by its own backend request lifecycle.</p><p>The irony would be amusing if it were not attached to paid subscriptions and interrupted work.</p><hr><h2>4. Sandbox Permission Management: Security as Friction Without Elegance</h2><p>The second major failure is sandbox-mode permission management.</p><p>Security matters. No serious user should want an autonomous coding agent to execute arbitrary commands with unlimited access and no constraints. Permission boundaries are necessary. Sandboxing is necessary. User consent is necessary. Least privilege is necessary.</p><p>But security design has two responsibilities, not one.</p><p>It must protect the user, and it must preserve the workflow.</p><p>A permission system that protects the user by making the tool clumsy, interruptive, inconsistent, and dramatically less capable than competitors is not a refined security model. It is merely friction with a policy justification.</p><p>The comparison with Claude Code is therefore unavoidable. If another tool can provide a smoother command-execution experience, maintain higher task continuity, and create less operational drag while still preserving meaningful user control, then the problem is not the existence of permissions. The problem is OpenAI’s implementation of permissions.</p><p>A professional coding environment requires predictable execution semantics. Users need to understand what the agent can do, what it cannot do, when it will ask for permission, how approvals persist, and how command execution fits into the task lifecycle. If the permission model causes frequent failure, excessive interruption, or low command success rates, it ceases to feel like a security layer and begins to feel like a product deficiency.</p><p>A mature sandbox should be:</p>
Requirement | Expected Behavior
-- | --
Predictable | The user should understand when permission is required.
Granular | Permissions should match actual risk, not block broad categories unnecessarily.
Persistent where appropriate | Repeated approvals for equivalent low-risk operations should be avoidable.
Transparent | The agent should explain why a command is blocked or requires approval.
Recoverable | Failed commands should lead to alternate strategies, not task collapse.
Efficient | Security should not make ordinary development workflows feel hostile.
<p>When these properties are absent, sandboxing becomes theater. It displays concern for safety while quietly damaging usefulness.</p><p>OpenAI should not pretend that users are asking for reckless execution. Serious users are asking for competent execution under rational constraints.</p><p>There is a difference.</p><hr><h2>5. Premium Pricing and the Ethics of Reliability</h2><p>A paid subscription changes the moral texture of product failure.</p><p>Free users may reasonably expect experimentation. Preview users may reasonably expect instability. But Pro subscribers are not merely browsing a laboratory demonstration. They are paying for access to a product they are encouraged to treat as powerful, professional, and production-relevant.</p><p>When the actual return on that subscription is a stream of internal errors, failed tasks, broken continuity, and low command success rates, the issue becomes commercial as well as technical.</p><p>The user is not paying for OpenAI’s aspirations. The user is paying for service.</p><p>This distinction matters. A company may be admired for research while still being criticized for product execution. It may lead the field in model capability while lagging in user experience. It may possess world-class infrastructure while still deliver unreliable workflows. These contradictions are not impossible. In fact, they are increasingly visible.</p><p>The central complaint is not that OpenAI has failed to solve every hard problem in artificial intelligence. The complaint is that OpenAI has failed to resolve ordinary product reliability problems in a tool that users are paying to use.</p><p>No serious enterprise would accept a vendor explanation that effectively says: “The product is revolutionary when it works.” That phrase is not a service-level guarantee. It is an admission.</p><p>For a professional user, reliability is not decorative. It is the foundation.</p><p>A tool that works brilliantly 40 percent of the time and collapses mysteriously during serious workloads is not a professional tool. It is an unstable accelerator: impressive in demonstrations, dangerous in dependency.</p><hr><h2>6. The Aesthetic of Inaction</h2><p>OpenAI’s most frustrating behavior is not merely failure, but the appearance of institutional stillness around failure.</p><p>Users report issues. Users document errors. Users identify reproducible pain points. Users explain how the product breaks. Users compare alternatives. Users pay subscription fees. And then, from the outside, the response often appears slow, opaque, and insufficiently accountable.</p><p>This creates what might be called the aesthetic of inaction.</p><p>The company continues to move quickly in public narratives, but slowly in user-facing repair. It continues to publish progress while basic workflow defects persist. It continues to expand ambition while existing tools remain fragile. It continues to speak of agents while users manually restart tasks that should never have died.</p><p>The contrast is not flattering.</p><p>A world-class company is not measured only by the brilliance of its research announcements. It is measured by how quickly it notices when users are blocked. It is measured by how clearly it communicates about product failures. It is measured by whether it treats broken workflows as urgent, not merely unfortunate. It is measured by whether paying users feel respected when the product fails.</p><p>There is a particular kind of arrogance that appears when a company becomes too associated with the future. It may begin to treat present usability as a secondary concern. It may assume that users will tolerate instability because the underlying technology is impressive. It may believe that capability excuses inconvenience.</p><p>That belief is mistaken.</p><p>Capability attracts users. Reliability keeps them.</p><hr><h2>7. “It Works for Simple Tasks” Is Not a Defense</h2><p>One common defense of unstable AI coding tools is that they still work for simple tasks.</p><p>This is irrelevant.</p><p>A tool designed for complex coding workflows cannot be defended by saying it works when complexity is removed. A bridge cannot be praised because it holds under light decorative weight if it fails under traffic. A database cannot be considered reliable because it stores small records but corrupts under production load. A compiler cannot be called successful because it handles hello-world examples but crashes on real projects.</p><p>The entire purpose of Codex is to reduce the burden of complexity. If it fails precisely when complexity appears, then it is not merely imperfect. It is failing at the boundary where its value is supposed to begin.</p><p>Simple tasks are not the benchmark.</p><p>Real repositories are the benchmark. Dependency conflicts are the benchmark. Multi-file refactors are the benchmark. Test failures are the benchmark. Long-running task continuity is the benchmark. Context preservation is the benchmark. Recovery after interruption is the benchmark.</p><p>A coding agent should not be evaluated by whether it can produce a small snippet in isolation. That was impressive several product generations ago. The current standard is whether it can operate as a reliable collaborator in a real development environment.</p><p>By that standard, persistent remote compact failures and brittle sandbox execution are not minor defects. They are disqualifying weaknesses.</p><hr><h2>8. The Competitive Reality OpenAI Cannot Ignore</h2><p>OpenAI does not operate in a vacuum.</p><p>Claude Code exists. Other agentic coding tools exist. Local-first workflows exist. IDE-integrated assistants exist. Developer tools are becoming more competitive, more specialized, and more operationally disciplined. Users are no longer comparing Codex against imagination. They are comparing it against alternatives.</p><p>That comparison is increasingly practical.</p><p>Users ask:</p><ul><li><p>Which tool completes tasks with fewer interruptions?</p></li><li><p>Which tool handles command execution more reliably?</p></li><li><p>Which tool preserves context better?</p></li><li><p>Which tool recovers from errors?</p></li><li><p>Which tool integrates with real repositories more smoothly?</p></li><li><p>Which tool respects my time?</p></li><li><p>Which tool produces fewer dead ends?</p></li><li><p>Which tool makes me feel like I am working with an assistant rather than supervising a malfunctioning appliance?</p></li></ul><p>These are not abstract benchmarks. They are daily workflow questions.</p><p>If Codex loses on these dimensions, OpenAI’s model quality may not be enough to compensate. Intelligence trapped inside unreliable product infrastructure is wasted intelligence. A brilliant agent that cannot execute consistently becomes inferior to a less brilliant agent that can complete the work.</p><p>This is the brutal truth of developer tooling: the best tool is not always the one with the most impressive underlying model. It is the one that survives contact with the workflow.</p><p>OpenAI should understand this. Developers are unforgiving in the long term. They may experiment widely, but they retain only what compounds productivity. A tool that repeatedly breaks trust will be abandoned, regardless of its theoretical intelligence.</p><hr><h2>9. The Burden of Being OpenAI</h2><p>OpenAI’s failures attract strong criticism because OpenAI has chosen a strong position.</p><p>It has not presented itself as a small experimental vendor quietly exploring uncertain terrain. It has positioned itself as one of the most important technology companies in the world. It has accepted vast attention, vast capital, vast influence, and vast user dependence.</p><p>That position brings a burden.</p><p>When a minor tool fails, users complain. When OpenAI fails, users question the seriousness of the institution. This is not unfair. It is proportional to the company’s claims.</p><p>A company cannot simultaneously benefit from being perceived as world-defining and then ask to be judged like a fragile prototype when its products break. Prestige is not free. It is purchased through responsibility.</p><p>If OpenAI wants users to believe that its agents will transform work, then it must demonstrate that its agents can actually work. If OpenAI wants professional users to pay premium prices, it must deliver premium reliability. If OpenAI wants to lead the coding-agent category, it must treat operational defects as existential product issues, not background noise.</p><p>The burden is simple: act like the company your marketing implies you are.</p><hr><h2>10. What Competent Action Would Look Like</h2><p>Criticism is most useful when it identifies not only failure, but the shape of repair.</p><p>A serious response from OpenAI would include several concrete measures.</p><h3>10.1 Treat Compact Failures as High-Severity Incidents</h3><p>Any failure that prevents Codex from continuing complex tasks should be classified as a high-severity product incident. It directly attacks the core use case. The fix should not be deprioritized behind cosmetic improvements, new branding surfaces, or marginal interface changes.</p><h3>10.2 Implement Robust Retry and Resume Semantics</h3><p>If a stream disconnects before completion, the system should not simply fail the task. It should have structured recovery paths:</p><ul><li><p>automatic retry with backoff;</p></li><li><p>resumable compaction;</p></li><li><p>checkpointed task state;</p></li><li><p>user-visible recovery options;</p></li><li><p>partial continuation where possible;</p></li><li><p>diagnostic reporting that is understandable and actionable.</p></li></ul><p>A professional agent should not be so easily destroyed by one failed backend request.</p><h3>10.3 Provide Transparent Status and Incident Reporting</h3><p>Users should not have to guess whether the product is broken globally, regionally, account-specifically, or task-specifically. OpenAI should provide clearer product-specific health indicators for Codex, including known degradations affecting task continuity, sandbox execution, compaction, and command workflows.</p><h3>10.4 Redesign Sandbox Permissions Around Developer Reality</h3><p>The permission model should be risk-based, not merely restrictive. It should allow users to define trusted workspaces, persistent approval classes, command categories, and policy profiles. Serious users need controlled autonomy, not constant interruption.</p><h3>10.5 Improve Error Messages</h3><p>Raw backend errors are not acceptable as final user-facing explanations. A better error message should explain:</p><ul><li><p>what failed;</p></li><li><p>whether user action can resolve it;</p></li><li><p>whether the task can be resumed;</p></li><li><p>whether the issue is likely transient;</p></li><li><p>what diagnostic information is available;</p></li><li><p>what OpenAI is doing to prevent recurrence.</p></li></ul><p>A URL and a disconnected stream are not a support strategy.</p><h3>10.6 Offer Service Credits or Subscription Remedies for Extended Unusability</h3><p>If a paid product is functionally unavailable for a meaningful period, users should not be expected to simply absorb the loss. Service credit, subscription extension, or explicit compensation would signal that OpenAI recognizes the difference between inconvenience and non-delivery.</p><h3>10.7 Benchmark Against Competing Coding Agents Honestly</h3><p>OpenAI should compare Codex not only on model intelligence, but on workflow completion rate, command success rate, recovery rate, sandbox friction, multi-step task persistence, and real-repository performance. These are the metrics that matter to users.</p><hr><h2>11. The Professional User’s Final Judgment</h2><p>Professional users are not asking OpenAI for perfection.</p><p>They are asking for seriousness.</p><p>They are asking that a coding agent not collapse at the first step of a complex task. They are asking that sandbox security not become a synonym for poor usability. They are asking that paid subscriptions deliver more than recurring errors. They are asking that the company responsible for one of the most influential AI platforms in the world demonstrate operational maturity equal to its public ambition.</p><p>At present, the gap is too large.</p><p>The product promises agency but often delivers fragility. It promises coding assistance but often requires supervision more tedious than doing the work manually. It promises frontier capability but fails on ordinary reliability. It promises productivity but interrupts the workflow. It promises intelligence but neglects resilience.</p><p>This is why the criticism is severe.</p><p>Not because users enjoy complaining. Not because they misunderstand the difficulty of distributed systems. Not because they expect magic. But because they see clearly that OpenAI has the resources to do better, the obligation to do better, and the market position that demands better.</p><p>A small company might be forgiven for moving slowly.</p><p>OpenAI does not have that excuse.</p><hr><h2>12. Conclusion: Failure by Tolerance</h2><p>The most damaging failures are not always caused by ignorance. Sometimes they are caused by tolerance.</p><p>A company tolerates broken workflows. It tolerates vague errors. It tolerates user frustration. It tolerates support opacity. It tolerates product instability because growth continues, subscriptions renew, and public attention remains high. Over time, this tolerance becomes culture. The product may still improve, but the user learns a different lesson: the company will move when it wants to, not necessarily when the user is blocked.</p><p>That is the essence of the current complaint.</p><p>OpenAI’s problem is not that Codex encountered an error. The problem is that such errors can render the product effectively unusable, while the company’s response appears too slow, too opaque, and too detached from the reality of professional use.</p><p>A coding agent that cannot handle complex tasks is not a coding agent in any meaningful professional sense. A sandbox that makes execution unreliable is not a mature security model. A premium subscription that returns repeated failures is not a premium service. A world-leading AI company that allows these conditions to persist should expect criticism, and it should expect that criticism to be sharp.</p><p>OpenAI has succeeded brilliantly at making users believe in what might be possible.</p><p>Now it must do the less glamorous work of making the product dependable.</p><p>Until then, Codex will remain an instructive contradiction: a tool presented as the future of software development, yet too often defeated by the ordinary requirements of software development itself.</p></body></html>
I prepared a narrow patch for this specific reqwest TCP user timeout path, but upstream PR creation is blocked for my account (
CreatePullRequestpermission denied / collaborators-only behavior).Branch:
ikingye:fix/disable-reqwest-tcp-user-timeoutCommit:
9ef5ccdCompare: https://github.com/openai/codex/compare/main...ikingye:fix/disable-reqwest-tcp-user-timeout?expand=1
What the patch does:
TCP_USER_TIMEOUTfor the default Codex HTTP client by applyingtcp_user_timeout(None)on Linux/Android/FuchsiaNoneWhy this targets the reported symptom:
responses/compactis a unary request that can legitimately wait longer than reqwest's 30s Linux TCP user timeout before response bytes arrive. Disabling that reqwest/socket-level timeout keeps long compact requests from being disconnected by the default client before the backend can respond.Validation run locally on top of current
main(a2db6f9):cargo test -p codex-login default_clientpasses: 8 passed, 0 failedcargo fmt -- --config imports_granularity=Itempasses, with existing nightly-only rustfmt warnings forimports_granularitycargo clippy --fix --tests --allow-dirty -p codex-loginpasses, no follow-up source changescargo fmt --checkpasses, with the same rustfmt warningscargo test -p codex-core compact_remotestill has the existingremote_compact_trim_estimate_uses_session_base_instructionsfailure: 22 passed, 1 failed, 1 ignored. The failing assertion is in compact-history trimming; this patch only touchescodex-rs/logindefault HTTP client construction.If a collaborator wants to open/review it, the compare link above resolves cleanly against
main.As I replied above, increasing the stream_idle_timeout_ms is enough.
In the official documentation,
stream_idle_timeout_msis not a top-level configuration, but rather a configuration at the model provider level.This solves the issue for me in gpt-5.5:
<img width="966" height="757" alt="Image" src="https://github.com/user-attachments/assets/e6fe30dd-d9ee-46bb-9de7-9402786a78ed" />
I was also able to validate the
tcp_user_timeoutdiagnosis on a newer VS Code/CLI build.Environment:
openai.chatgpt-26.5422.30944-linux-x64codex-cli 0.125.0-alpha.3Before patching, the VS Code logs repeatedly showed:
codex_core::compact_remote: remote compaction failed ... compact_error=timeout waiting for child process to exitThe source location in this build is now:
codex-rs/login/src/auth/default_client.rsI patched the shared reqwest client there to set a 120s
tcp_user_timeouton Linux-family targets, built a replacement CLI, and pointed VS Code at it viachatgpt.cliExecutable.After the patch, I pushed a live chat to roughly
231k-234k / 258ktokens. It compacted and resumed successfully. Searching the current extension logs after the compaction found no matches for:remote compaction failedFailed to run pre-sampling compacttimeout waiting for child processcompact_errorThe minimal source change I tested is:
DurationimportDEFAULT_TCP_USER_TIMEOUT = Duration::from_secs(120)builder.tcp_user_timeout(DEFAULT_TCP_USER_TIMEOUT)intry_build_reqwest_client()That is in
codex-rs/login/src/auth/default_client.rson currentmain.I have a public branch with the one-file patch available if a maintainer wants a PR:
https://github.com/vvartiov-ai/codex/tree/fix-linux-tcp-user-timeout
@vvartiov-ai I did similar fix and I been using it for a month now.
I tested the config workaround on Codex.app, and there is an important caveat: changing the top-level model_provider makes old threads disappear from the App history UI.
They are not deleted. The issue is that Codex.app appears to filter thread/list by the currently active config.model_provider_id. Existing threads are stored with model_provider = "openai", while the workaround requires something like model_provider = "openai-long-timeout". As a result, the App only lists threads for the new provider and hides the old openai threads.
So for Codex.app, the config workaround is not safe as a general fix unless users are okay with old threads being hidden, or they manually migrate the SQLite state DB, which is risky and should not be required.
A better fix for Codex.app would be to apply the timeout change to the built-in openai provider / shared HTTP client without changing the provider id. That way existing threads remain visible and remote compaction can still get the longer timeout.
It's good now. Thanks for the work OAI.
Please fix this. It's really annoying. Many more people are complaining at https://github.com/openai/codex/issues/9544
Same issue here. The bug (if not something by design) prevents the agent from running long tasks since the work often terminates at points of memory compression.
Yes, it's about the TCP connection timing out. The fix is in https://github.com/vvartiov-ai/codex/tree/fix-linux-tcp-user-timeout I created but I cannot create a PR for it myself. You can also just pull and compile that branch yourself if you need the fix right away.
See https://github.com/openai/codex/issues/14860#issuecomment-4319989182 above.
Why is such a basic feature still not fixed? Tons of people have submitted PRs already—what are the maintainers even doing?
+1 Same here ! please fix it !
Hard to believe this is still unresolved.
For a tool that depends heavily on long-running coding sessions and context management, /compact failing is not a small paper cut. It breaks the core loop.
Please prioritize this. At minimum, make the error message honest. Ideally, fix the timeout behavior and make the value configurable.
it's still unresolved! please fix this!
Thanks,it does works.Maybe magic CANCEL.
Still unresolved
Any fix here?
+1
When can OpenAI fix it?
Guys, we keep running into this problem. Please, let’s finally fix it! It’s impossible to work properly. What are we paying $100–200 for?
I experienced this issue consistently while trying to run compaction on a Ubuntu guest running under VMWare Workstation (Hyper-V, so network mode is NAT) on a Windows host. Happy to report that @Grallen's fix totally worked; at risk of derailing, for anyone else who may be trying to get the Codex vscode extension to work, once you've compiled the binary with the corrected timeout, you can point the codex extension at it via the vscode setting
chatgpt.cliExecutable.i got the same issue but i think it's because i'm on azure model as a provider, anyone else ?
Azure won't fail. Increase your token limit on the portal to see if it works.
I'm already at 10M TPM i don't think it's about token limit
Even with classic host its doing thatSent from my iPhoneOn 14 May 2026, at 14:12, Rafik Belkadi @.***> wrote:Rafik-Belkadi-Reccap left a comment (openai/codex#14860)
i got the same issue but i think it's because i'm on azure model as a provider, anyone else ?
Azure won't fail. Increase your token limit on the portal to see if it works.
I'm already at 10M TPM i don't think it's about token limit
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you commented.Message ID: @.***>
This is a major blocker for looooong threads. Have to keep creating new threads because of this poorly designed timeout.
I just went back to opencode at this point
This is a major issue and breaks all long running tasks. Has there been any official response?
I don't understand why this bug continues for so long. HAS ANY OPENAI employee tried CodeX??? If so, why didn't they find this P0 issue?
I agree with it.
I am facing same issue. Has anyone created a PR based on this?
I suspect OpenAI is overselling to retail users. They might be deliberately leaving this issue unfixed just to throttle user engagement/usage.
This is a major issue and breaks all long running tasks!
We are in AI bubble for sure
Same issue -- 019cd581-6886-7c72-aaba-0ddcfc3627a2
Same issue, gpt-5.5 High, codex cli 0.133.0, Apple M5 MacOS Tahoe 26.4.1, under VPN, Plus subscription
In standard mode, both auto-triggered compression and manual
/compactexecution fail with the following error:Error running remote compact task: stream disconnected before completion: error sending request for url ([https://chatgpt.com/backend-api/codex/responses/compact](https://chatgpt.com/backend-api/codex/responses/compact)).Switching to fast mode and manually running
/compactresolves the issue. According to the docs, fast mode provides a 1.5x speedup but consumes more credits. Therefore, I suspect this problem is timeout-related, where the compaction command is timing out in standard mode.However, this is clearly a major bug that severely impacts long-context environments and continuous workflows. I hope OpenAI team can fix this as soon as possible.
same issue with me! I had this on a long running gpt 5.4 project tried to move to 5.5 broke, and now even 5.4 is broken.
same issue, gpt 5.5, xhigh, when auto compression
Two months have passed since this ticket was first opened, and there is still no official fix. I still get the following error quite often during long-running sessions:
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
/modelswitch back to codex 5.3, then manually/compact. After compacting, switch back to the modelSometimes it works fine for me now, but I honestly have no idea why OAI hasn’t been able to fix it for the past two months.
they just shipped a big update but this is still open lol
for god sake can any openai employee actually look at this??!! What’s wrong with you guys
For the ~30s-per-attempt variant of this bug specifically (failure visible as
"request timed out", or on older builds"timeout waiting for child process to exit") — the root cause has been pinned down in #24323: reqwest 0.12 hard-codesTCP_USER_TIMEOUT=30sper-socket on Linux/Android/Fuchsia, which caps long unary requests below codex's own.timeout()budget. The kernel returnsETIMEDOUT (os error 110)during request send well before the application timer ever runs.Proposed fix, ready to merge as-is: https://github.com/zaid-marji/codex/commit/666e49cf5626be616a8b5627b3a40dbde7ef9ee8
cfg-gated to the platforms where reqwest exposestcp_user_timeout.1200s) chosen to matchstream_idle_timeout × COMPACT_REQUEST_TIMEOUT_IDLE_MULTIPLIERso the socket option never silently shadows the per-request.timeout()codex already sets.cargo check+cargo clippyclean, rebased on currentmain..timeout()) by filling the socket layer below it.Per the contributing guidelines I haven't opened a PR — happy to do so if invited, or the maintainers can cherry-pick
666e49cdirectly into a maintainer-authored PR.---
If you're hitting this and can't wait for upstream, apply the patch yourself:
main666e49c(or apply the 14-line diff manually)cargo build --release -p codex-cli~/.vscode-server/extensions/openai.chatgpt-*-linux-x64/bin/linux-x86_64/codex(or your platform equivalent) with the rebuilt binaryNeeds re-applying after each extension auto-update — VS Code installs new versions into a sibling directory, each shipping the unpatched upstream binary.
Other failure modes appearing on this thread — e.g.,
stream disconnected before completionafter ~60s — are separate causes that this patch does NOT address.My workaround:
Use
/modelto switch back toCodex 5.2 Low, then manually type something to trigger compacting. I usually typepauseto prevent Codex from continuing with the low model.After compacting is done, switch back to the original model and continue.
Would be nice if the 5.5/5.4 context compact issue was fixed before 5.3 codex was sunset...
I can't use the application successfully at all now, despite trying various workarounds. I get this error in nearly every workflow that 5.4 or 5.5 attempts to compact context.
<img width="577" height="169" alt="Image" src="https://github.com/user-attachments/assets/8c6f3512-c5d0-4b76-a6ac-e5726b465c11" /> looks like 5.3 low doesn't work as a workaround
same issue
"If your development skills are lacking, just let AI do the development."
https://github.com/garyfpga/codex-compact-fix
try my fork if you are using CLI
I change it to use local compact
just use my fork for the moment
Yo they fixed it in the last update, finally
Still happens in v0.139.0
@garyfpga Not created a PR?
which 139 are you using, npm or the .sh one?
I am using the .sh one (which I assume is from the rust binary)
and the problem is gone.
But if you still have the problem, I can add the binary in my fork and you can use it (linux cli)
I actually did some more "optimization" on the compact path, like
let me know if using the .sh official binary fix your problem first. My fork is just AI slop, I think it is okay as a temp solution but isn't worthy to merge back.
I am using the .sh only
@garyfpga, sorry it is a different error, https://github.com/openai/codex/issues/18052#issuecomment-4367149256
https://github.com/garyfpga/codex-compact-fix/releases/tag/codex-cli-binary-2026-06-09
use this if you don't wanna compile, or you can just use rustc to compile from source. takes 30 minutes in my machine
also add that in config.toml
it will first try max_attempts on remote compact, then fall back to local
local must always work but lower quality
[remote_compact]
max_attempts = 3
attempt_timeout_sec = 180
tcp_keepalive_interval_ms = 1000
Damn, I found that what they do is switched to v2 remote compact and a few things, but it is not entirely fixed and I still sometimes hit that problem
I will properly maintain and release my version then
<img width="1311" height="215" alt="Image" src="https://github.com/user-attachments/assets/aeba2723-198e-4025-9976-c54a62f643b1" />
Just to show off a bit...
Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use
/feedbackand open a new bug report.