exec-server: streamed HTTP body notifications build an intermediate JSON value

What variant of Codex are you using?

CLI (remote exec-server)

What feature would you like to see?

I found a potential performance concern in current source rather than a confirmed user-visible bug. RpcNotificationSender::notify converts each typed HttpRequestBodyDeltaNotification into an owned serde_json::Value. The selected transport writer later serializes the enclosing JSON-RPC message to a String for stdio or WebSocket, or to a Vec<u8> for relay. Because ByteChunk serializes as base64, the intermediate Value already owns the complete deltaBase64 string before the final transport payload is built.

Please consider an internal already-serialized JSON-RPC notification queue item for this path. RpcNotificationSender could serialize the complete notification directly once; stdio would append its newline and flush, WebSocket would send that JSON as a text frame, and relay would place its UTF-8 bytes in RelayData before protobuf encoding. The change should preserve queue capacity and backpressure, notification-send failure behavior, transport disconnect behavior, ordering, sequence/EOF/error behavior, the exact method and fields, required deltaBase64, and every existing framing contract. HTTP pooling and exec-output event ownership remain outside this proposal.

Additional information

Evidence

• route_aware_http_client constructs and sends each typed body delta.
• send_body_delta routes it through RpcNotificationSender::notify; notify calls serde_json::to_value and stores the resulting Value in the outbound notification.
• The stdio and WebSocket writers serialize the resulting JSON-RPC message. The relay independently serializes JSON-RPC into its payload at relay.rs before protobuf framing.
• ByteChunk and HttpRequestBodyDeltaNotification make deltaBase64 part of the wire contract; the proposal isolates only the intermediate representation.
• Related prior art: #18581 introduced the executor HTTP body-delta protocol, #32112 bounded body-delta size and queued bytes, and #36006 removed the analogous intermediate serde_json::Value from app-server responses by keeping them typed through the outgoing queue. None removes the exec-server notification conversion.

Impact

Not measured. Each streamed delta currently allocates an intermediate Value tree, including owned string fields and the base64 deltaBase64 value, and then a final JSON String or Vec<u8>. The avoidable allocation may matter for frequent or near-limit deltas, but latency, throughput, CPU, allocation volume, and occurrence are unknown. Required base64 encoding and transport framing are not claimed avoidable.

Question

Would maintainers accept an internal serialized-notification queue item so each HTTP body delta is converted directly to JSON once while the stdio, WebSocket, and relay writers retain their existing framing and failure semantics?

I checked all relevant issues, comments, pull requests, discussions, and release notes; this report is not a duplicate.

I am reporting this finding only and am not proposing a pull request unless a maintainer invites one.

Disclosure

Investigated thoroughly with GPT-5.6 (high reasoning effort), using Oh My Pi as the agent framework.

This report is not generic or unreviewed AI-generated output. Its claims were checked against the cited evidence, and it includes the relevant detail intended to help maintainers resolve the issue.

If reports like this are not useful to the project, please let me know and I will refrain from submitting similar ones. My intent is to help without wasting maintainer time or energy or discouraging their work.

Thank you for your work.