Codex app-server input has no per-message byte limit

[alexfertel]

What happened

The Codex app-server protocol accepts a newline-delimited JSON message of any size. It stores fragments until a newline arrives, joins them into one string, and then parses the full JSON value. The parser has no byte limit before these allocations.

The current count limit does not address this case. MAX_BUFFERED_RAW_MESSAGES = 32 limits decoded queue entries, not the size of one input message.

This install has received Codex events containing diff strings near 49 million characters. A single valid provider notification can therefore require a large line string, a parsed object, and later runtime event objects at the same time.

Diagnosis

makeCodexAppServerPatchedProtocol reads text chunks from the child process and stores unfinished line fragments in remainder. It tracks no byte count. When it finds a newline, it runs remainder.join(""), then decodeWireMessage parses the result through Schema.fromJsonString.

The protocol applies its 32-message sliding queue only after JSON decoding and routing. The bound cannot stop one oversized line from exhausting the heap during line assembly or parsing.

Issue #5389 fixed quadratic input scanning. The current loop scans each chunk once, so that fix is present. It did not add a per-message byte limit.

Expected behavior: the protocol should enforce a documented byte ceiling while it receives line fragments. If a message exceeds the ceiling, T3 should stop or fail that provider session with a clear error instead of joining and parsing the full value. The check must run before remainder.join("").

Steps to reproduce

Synthetic reproduction:

1. Create a fake Codex app-server standard input stream.
2. Send one newline-delimited JSON notification whose params contains a generated string large enough to approach the V8 heap limit.
3. Split the message across many input chunks so the protocol stores fragments in remainder.
4. End the line with a newline.
5. Observe that the protocol joins and parses the full message without checking its byte size.

A focused regression test can add an injectable low message limit, send fragments that cross it, and assert that parsing never runs and the session receives a typed transport error.

Version

0.0.43-nightly.20260920.2005, commit 7445aa733ada.

Environment

• T3 Code desktop app with local backend
• Darwin 25.6.0, arm64
• Node.js 26.8.2
• Codex provider

Evidence

Current count bound:
  MAX_BUFFERED_RAW_MESSAGES = 32

Unbounded line state:
  const remainder: Array<string> = []

Line assembly:
  remainder.push(chunk.slice(start, newline))
  lines.push(remainder.join(""))

Decode order:
  assembled line -> decodeWireMessage(line) -> routeMessage(decoded)

Largest decoded file-change diff seen on this install:
  about 49 million characters

No home paths, thread IDs, turn IDs, project names, commands, diff text, or credentials are included.

Related issues

• [Bug]: app-server stdin reader is quadratic in line length — OOM crash on large tool payloads #5389 fixed quadratic scanning in the app-server input reader. It did not add a byte limit.
• Oversized Codex diff event exhausts desktop backend heap #10924 and fix(server): bound provider event log records before serialization #12305 bound diagnostic event serialization after protocol decoding.
• Codex thread resume can exhaust server heap on large histories #7075 concerns an oversized thread/resume response. This report applies to any oversized app-server message.
• Codex file-change diffs are duplicated in SQLite and exhaust backend heap #12758 concerns large payloads after decoding and persistence.

No open issue or pull request found in the upstream search covers the missing pre-parse byte limit.

Fix applied or workaround

No source patch was made. Avoiding very large provider messages reduces risk, but T3 has no local setting for a protocol message limit.

Filed by

Codex, GPT-5, via t3 triage

[juliusmarminge]

Triage

Confirmed on current main. This is a real reliability gap, not a duplicate of the later-stage heap issues.

makeCodexAppServerPatchedProtocol in packages/effect-codex-app-server/src/protocol.ts stores unfinished JSONL fragments in remainder with no byte counter. On newline (and again on stdin end) it does remainder.join(""), then decodeWireMessage → Schema.fromJsonString. MAX_BUFFERED_RAW_MESSAGES = 32 only bounds decoded notification/request queues and in-flight request handlers. It cannot stop one oversized line from allocating during join or parse.

#5389 / #8605 already made scanning linear (each chunk is scanned once; that loop is present). They did not add a size ceiling. The existing protocol test still sends a fragmented ~4 MiB turn/diff/updated and expects a successful parse.

This is earlier than the other Codex heap reports:

• #10924 / #12305 — diagnostic serialization after decode
• #12758 — SQLite activity persistence after decode
• #12883 — unbounded ingestion queues after decode
• #7075 — large thread/resume response body
• #7258 — usage transcript file reader

ACP already has Effect ndJsonRpc()’s 16 MiB maxBufferSize. Codex’s custom reader does not. #11216 / #11217 show that a cap that is too low bricks legitimate large sessions.

Suggested fix

Track pending fragment bytes while chunks arrive. If a line would exceed a documented ceiling, drop remainder, skip join / parse / raw logging, and terminate the provider session with a typed transport error. Inject a tiny limit in protocol.test.ts so the regression can prove decode never runs.

Production ceiling needs to sit above real Codex diffs (the 4 MiB test and the ~49M-character events on this install) and well below a V8 heap-threatening line. 16 MiB would reject those diffs. Something in the 64–128 MiB range is the useful band. A just-under-limit message can still blow up later in persistence/queues; those stay #12758 / #12883.

[cestercian]

I'd like to take this — focused per-message byte limit on the Codex app-server input path.