Bound stdio JSON-RPC frame size

[jif-oai]

Why

BufReader::lines() keeps growing until it sees a newline or EOF. A misbehaving stdio exec-server could therefore make the peer retain an unbounded JSON-RPC frame without ever completing it.

The 64 MiB ceiling intentionally matches the existing serialized JSON-RPC message ceiling on Noise and WebSocket transports, keeping the per-message bound consistent across transports.

What changed

• Limit inbound stdio JSON-RPC payloads to 64 MiB, excluding the line terminator.
• Read one byte past the limit so an oversized unterminated frame disconnects immediately.
• Preserve both LF and CRLF framing, including a payload exactly at the limit.
• Keep ordinary bounded malformed JSON on the existing non-fatal malformed-message path.
• Cover the exact-limit and hostile unterminated cases in connection tests.

Scope

This PR only closes the unbounded newline-delimited stdio read path. Other transports keep their existing framing behavior.

[goyiii44545-gif]

im not here here to distrube any of your company roadmaps and goals-- a small idea of mine is, maybe you could have this adjusted in real time. so if the payload is [payloads to 64 MiB], but discovered due to some weird RFC , or internet-server-provider... it needs to be limited to like 32MiB it could happen. ([ --> Also with like consideration of latency reduction, but can be adjust, every time a user reopen codex, which is often. or can be sent as a COMMAND in the websocket comunication <-- ])

I would like to refer to cfead68 which was made by @richardopenai which is a commit I like a lot.

but never the less, codex is a very very solid product despite some hard-learn-lessons -- with the idea how large products should scale, when you have weird technicalities like isp

[jif-oai]

@goyiii44545-gif Thanks. The 64 MiB bound here only applies to local stdio framing, so ws and ISP conditions aren’t involved. We can revisit the fixed limit if compatibility data shows a need