openai / openai/codex

Code Mode treats transient IPC queue saturation as a fatal disconnect

Open
#42,527 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug CLI connectivity tool-calls
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What version of Codex CLI is running?

The failure was reproduced with codex-cli 0.147.0.

I also verified that latest stable 0.153.0 and current main still contain both faulty try_send paths. Current inspected main is 728cb12fe5794b0c3a8e776fb4994b1650b973a8.

What subscription do you have?

Self-serve Business Pro Lite. The session reports plan type self_serve_business_prolite.

Which model were you using?

gpt-5.6-sol

What platform is your computer?
Darwin 25.6.0 arm64 arm

macOS 26.6, build 25G5057c.

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

Ghostty 1.3.1. The affected CLI session was not intentionally launched through tmux, screen, or zellij.

Codex doctor report

I ran codex doctor --json using the official 0.153.0 macOS arm64 release package. The archive checksum matched its published SHA-256.

The full report was reviewed before submission. Private absolute paths and unrelated historical rollout identifiers are omitted below.

{
  "schemaVersion": 1,
  "overallStatus": "warning",
  "codexVersion": "0.153.0",
  "checks": {
    "auth.credentials": {
      "status": "ok",
      "summary": "auth is configured",
      "details": {
        "stored API key": "false",
        "stored ChatGPT tokens": "true",
        "stored auth mode": "chatgpt"
      }
    },
    "config.load": {
      "status": "ok",
      "summary": "config loaded",
      "details": {
        "config.toml parse": "ok",
        "relevant enabled feature flags": "code_mode_buffered_exec, code_mode_host, unified_exec, multi_agent",
        "model": "gpt-5.6-sol",
        "model provider": "openai"
      }
    },
    "desktop.app_server.handshake": {
      "status": "ok",
      "summary": "the desktop app-server initialized successfully"
    },
    "git.environment": {
      "status": "ok",
      "summary": "git version 2.50.1"
    },
    "system.environment": {
      "status": "ok",
      "summary": "OS language en-US",
      "details": {
        "os": "Mac OS 26.6.0 [64-bit]"
      }
    },
    "terminal.env": {
      "status": "ok",
      "summary": "terminal metadata was detected"
    },
    "updates.status": {
      "status": "ok",
      "summary": "update configuration is locally consistent",
      "details": {
        "latest version": "0.153.0",
        "latest version status": "current version is not older"
      }
    }
  },
  "redactionNote": "The warning concerns unrelated historical rollout index inconsistencies. User paths and rollout IDs were removed."
}
What issue are you seeing?

During a long-running CLI session, parallel subagents generated overlapping tool calls and bursty results. Code Mode repeatedly returned:

code-mode host outgoing queue is full

The error occurred before useful tool output was returned. Running or yielded cells became inaccessible after the Code Mode host recycled.

Cell IDs changed from ordinary numeric values to generation-prefixed values such as g3:1, g4:1, and g9:4 after failures.

The error was recorded six times between 2026-08-31T20:24:41Z and 2026-08-31T21:01:23Z.

The root cause remains visible in latest stable and current main:

  1. codex-rs/code-mode/src/remote_session/connection/driver.rs calls outgoing_tx.try_send(frame).
  2. TrySendError::Full invokes fail("code-mode host outgoing queue is full").
  3. codex-rs/code-mode-host/src/peer.rs also calls outgoing_tx.try_send(frame).
  4. Its TrySendError::Full path disconnects the peer.
  5. Active-cell routing similarly converts transient channel fullness into connection failure.

These queues are intentionally bounded. Temporary fullness indicates congestion, not a closed or unhealthy connection.

The immediate queue capacity is 128 frames. The host also limits admission to 128 active cells and 256 in-flight requests.

What steps can reproduce the bug?

Affected thread ID:

01a057e7-b7fb-7db3-a5f2-c2929a43c8a6

Product-level reproduction:

  1. Enable Code Mode in Codex CLI.
  2. Start a long-running session with many parallel agents.
  3. Have agents issue overlapping functions.exec calls that produce bursty results.
  4. Keep several executions yielded while additional commands and delegate responses arrive.
  5. Observe code-mode host outgoing queue is full when the outgoing channel saturates.
  6. Observe generation-prefixed cell identifiers after the host is replaced.

The underlying failure can be reproduced deterministically with a capacity-one bounded channel:

let (tx, _rx) = tokio::sync::mpsc::channel(1);

tx.try_send(1_u8).unwrap();
assert!(matches!(
    tx.try_send(2_u8),
    Err(tokio::sync::mpsc::error::TrySendError::Full(_))
));

The current implementation turns that ordinary Full result into a fatal connection failure.

The patch adds capacity-one regression tests on both sides. They prove that the second send waits, remains cancellable, preserves FIFO ordering, and never disconnects.

What is the expected behavior?

Temporary queue saturation should apply bounded backpressure. Producers should await capacity while preserving FIFO order.

Queue fullness should not drop frames, recycle the Code Mode host, or invalidate unrelated execution cells.

A genuinely closed channel should still fail the connection. Connection cancellation must remain able to preempt blocked sends.

Additional information

I prepared a current-main patch and full technical report:

The patch changes both stdio directions to bounded awaited FIFO sends. It also prevents awaits while holding delegate or cell-route mutexes.

Admission becomes 512 active cells and 1,024 in-flight requests. One active agent can hold an execute request and a wait request simultaneously.

Validation against upstream main at 728cb12fe5794b0c3a8e776fb4994b1650b973a8:

cargo test -p codex-code-mode-host --lib
37 passed; 0 failed

cargo test -p codex-code-mode --lib
71 passed; 0 failed

just fix -p codex-code-mode-host
passed

just fix -p codex-code-mode
passed

git diff --check
passed

Related reports were reviewed before filing:

  • #33190 and #42106 concern active-cell admission exhaustion, not transient outgoing-queue fullness.
  • #19608 concerns an app-server outbound queue, not Code Mode stdio IPC.
  • #36698 tracks the independent Rusty V8 source-build artifact failure encountered during validation.

No searched issue contained the exact error, the try_send(Full) root cause, or an equivalent open patch.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with codex-rs/code-mode/src/remote_session/connection/driver.rs and codex-rs/code-mode-host/src/peer.rs, tracing each outgoing_tx.try_send path and its handling of a full channel. Run cargo test -p codex-code-mode-host --lib and cargo test -p codex-code-mode --lib, then inspect the capacity-one regression tests described in the issue. Done means temporary fullness waits without disconnecting or losing FIFO ordering, while closed channels and cancellation still behave correctly.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.