Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Increase TCP user timeout for default client to avoid compaction hangs

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Fix Action

Fix / Workaround

builder = builder.tcp_user_timeout(DEFAULT_TCP_USER_TIMEOUT);

## Patch
 ```rust
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();
     }

Build

Code Example



---

const DEFAULT_TCP_USER_TIMEOUT: Duration = Duration::from_secs(120);
   
  and apply it when building the reqwest::Client:

  builder = builder.tcp_user_timeout(DEFAULT_TCP_USER_TIMEOUT);

---

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();
       }

---

cd codex-rs
  cargo build -p codex-cli --release

---

cargo build --target x86_64-unknown-linux-musl -p codex-cli --release
RAW_BUFFERClick to expand / collapse

What version of Codex CLI is running?

codex-cli 0.134.0

What subscription do you have?

GPT Pro 20x

Which model were you using?

gpt-5.5

What platform is your computer?

Ubuntu

What terminal emulator and version are you using (if applicable)?

No response

Codex doctor report

What issue are you seeing?

Long-running unary requests such as remote compaction can keep the connection open long enough that the default TCP user timeout is too short on Linux-family targets.

When that happens, compaction may hang or fail before the server finishes responding.

Fix

Set a bounded but longer timeout for the default client:

const DEFAULT_TCP_USER_TIMEOUT: Duration = Duration::from_secs(120);
 
and apply it when building the reqwest::Client:

builder = builder.tcp_user_timeout(DEFAULT_TCP_USER_TIMEOUT);

Patch

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();
    }

Build

From the repository:

 cd codex-rs
 cargo build -p codex-cli --release

Optional musl build:

  cargo build --target x86_64-unknown-linux-musl -p codex-cli --release

Result

After applying this change and rebuilding, compact / remote compaction completed successfully instead of hanging.

Comments

Increase TCP user timeout for default client

Set an explicit 120s tcp_user_timeout on the shared reqwest client. The default timeout can be too short for long-running unary requests such as remote compaction on Linux-family targets.

What steps can reproduce the bug?

Use /goal and this bug will happen.

What is the expected behavior?

No response

Additional information

No response

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Increase TCP user timeout for default client to avoid compaction hangs