What Problem This Solves

The parseSSE generator in src/llm/providers/openai-chatgpt-responses.ts:719 accumulates decoded SSE chunks into an internal buffer string (line 726) that only shrinks when a \n\n event boundary is found. If a hostile or misconfigured SSE endpoint sends data without double-newline delimiters, the buffer grows unboundedly — consuming all available memory and OOM-killing the gateway process.

This affects every streaming Codex/OpenAI chat completion call routed through the SSE transport path (transport: "sse" or WebSocket failure fallback).

Changes

• src/llm/providers/openai-chatgpt-responses.ts (+10 LoC): Added SSE_PARSE_MAX_BUFFER_BYTES = 64 KiB constant. After each chunk decode, the buffer check throws CodexProtocolError if the accumulated buffer exceeds the cap — preventing unbounded memory growth.

• src/llm/providers/openai-chatgpt-responses.test.ts (+35 LoC): Added inline test "rejects oversized SSE response that exceeds buffer cap" — creates a Response with a ReadableStream body of 65 KiB (no \n\n), runs it through the production streamOpenAICodexResponses -> parseSSE chain, and asserts the error shows the buffer cap message.

Real behavior proof

• Behavior addressed: Unbounded SSE buffer growth when streaming endpoint sends data without \n\n event delimiters — buffer capped at 64 KiB, throws CodexProtocolError on overflow.
• Real environment tested: Linux x86_64, Node 22.19, OpenClaw main@81e53202f2
• Exact steps or command run after this patch:

  node --import tsx _proof_sse_cap.mts
  

• Evidence after fix:

  PASS  oversized body: real fetch throws buffer cap error (server sent 65.0 KiB, cap=64.0 KiB)
  PASS  well-formed SSE: parsed 1 event(s) correctly (server sent 71 B)
  PASS  exact-cap body: accumulated 64.0 KiB without throwing (cap is strict >, not >=)
  PASS  negative control: unbounded read accumulates 65.0 KiB past the 64.0 KiB cap (without fix, OOM vector confirmed)
  
  Results: 4/4 passed
  

  17/17 unit tests passed: pnpm test src/llm/providers/openai-chatgpt-responses.test.ts --run
• Observed result after fix:
  • Real node:http server on 127.0.0.1 delivered a 65 KiB SSE body without \n\n → client threw CodexProtocolError: Codex SSE response exceeded max buffer size (65536 bytes). Server-side bytes-sent: 65.0 KiB.
  • Same server with well-formed SSE (71 B including \n\n) → parsed 1 event correctly.
  • Exact-cap boundary (64 KiB, no \n\n) → accumulated without throwing (cap uses strict >, not >=).
  • Negative control: same 65 KiB body without the cap check → full 65 KiB accumulated in-memory (OOM vector confirmed).
• What was not tested: WebSocket transport path (different parser); non-OpenAI providers (separate PRs for Anthropic, agent transport streams).

Out of scope

• Anthropic SSE decoder (src/llm/providers/anthropic.ts:345 — iterateSseMessages) has the same pattern plus data[]/raw[] array accumulation. Follow-up PR.
• Agent transport SSE buffers (src/agents/provider-transport-fetch.ts, src/agents/runtime/proxy.ts) — separate PRs.

Risk

Low. The cap (64 KiB) is well above any reasonable SSE event payload. If triggered, the stream errors with a clear CodexProtocolError message rather than silently terminating. The change is additive — no existing behavior is modified, only a guard added.

AI-assisted; reviewed before submission.