Code Mode treats transient IPC queue saturation as a fatal disconnect
Nobody has claimed this yet.
- 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:
codex-rs/code-mode/src/remote_session/connection/driver.rscallsoutgoing_tx.try_send(frame).TrySendError::Fullinvokesfail("code-mode host outgoing queue is full").codex-rs/code-mode-host/src/peer.rsalso callsoutgoing_tx.try_send(frame).- Its
TrySendError::Fullpath disconnects the peer. - 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:
- Enable Code Mode in Codex CLI.
- Start a long-running session with many parallel agents.
- Have agents issue overlapping
functions.execcalls that produce bursty results. - Keep several executions yielded while additional commands and delegate responses arrive.
- Observe
code-mode host outgoing queue is fullwhen the outgoing channel saturates. - 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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