Codex review: needs maintainer review before merge. Reviewed June 27, 2026, 12:12 PM ET / 16:12 UTC.

Summary
The PR adds a 16 MiB createSseByteGuard wrapper to streamProxy and a regression test for oversized proxy streaming success bodies.

PR surface: Source +14, Tests +43. Total +57 across 2 files.

Reproducibility: yes. Current main and v2026.6.10 show a source-visible uncapped proxy SSE success-body reader, and the PR body includes after-fix live output showing a local HTTP oversized stream cancelled near the 16 MiB cap with small-stream controls.

Review metrics: 2 noteworthy metrics.

• Proxy SSE Total Cap: 1 added at 16 MiB. This is the new fail-closed runtime boundary maintainers need to accept or tune before merge.
• Open Overlapping Proxy Hardening PRs: 2 open. The same proxy stream loop is being changed in parallel, so final merge order affects which guard policy lands.

Root-cause cluster
Relationship: canonical
Canonical: #96768
Summary: This PR is the narrow canonical candidate for the runtime proxy total streaming-body cap; related proxy parser and broader hardening PRs overlap but do not currently replace it as a merged safe target.

Members:

• partial_overlap: fix(proxy): bound SSE parser via complete-line cap at 1 MiB #97191 - It guards per-line, retained-tail, and EOF parser buffers in the same streamProxy loop, but explicitly leaves the total response-body cap as a separate concern.
• partial_overlap: fix: proxy streams fail fast on oversized or stalled responses #97235 - It includes a total SSE cap using the shared guard plus non-2xx and idle-time behavior, but it is broader, open, and not established as the canonical replacement for this narrower PR.
• superseded: fix(proxy): bound SSE parser buffer to prevent OOM #96993 - It was a closed predecessor for a proxy parser-buffer cap and maintainer feedback rejected its 64 KiB string-length boundary; it does not cover this total-body guard.
• partial_overlap: fix(openai-chatgpt-responses): bound streaming success-body SSE reads at 16 MiB #96762 - The merged OpenAI ChatGPT Responses PR introduced the shared helper and precedent, but it did not wire the guard into streamProxy.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Have maintainers accept or tune the 16 MiB proxy success-body cap.
• Coordinate final merge order with the open per-event and broader proxy hardening PRs.

Risk before merge

• [P1] Existing runtime proxy success streams over 16 MiB will now throw and cancel instead of continuing, so maintainers need to accept or tune that fail-closed compatibility boundary.
• [P1] The same streamProxy loop is also touched by fix(proxy): bound SSE parser via complete-line cap at 1 MiB #97191 and fix: proxy streams fail fast on oversized or stalled responses #97235, so merge order should preserve the intended total-body, per-event, error-body, and idle-time policies.

Maintainer options:

1. Accept The 16 MiB Total Cap
   Maintainers can proceed if they accept that proxy SSE success bodies above 16 MiB now fail closed with a clear error.
2. Tune The Cap Before Merge
   If legitimate proxy deployments can exceed 16 MiB, adjust the cap and refresh overflow plus happy-path proof before landing.
3. Sequence With Proxy Guard PRs
   Coordinate this with fix(proxy): bound SSE parser via complete-line cap at 1 MiB #97191 and fix: proxy streams fail fast on oversized or stalled responses #97235 so overlapping guards do not drift during rebase or merge.

Next step before merge

• [P1] Human review is needed because the patch is correct but imposes a fail-closed proxy cap and overlaps live proxy-hardening PRs; no narrow automated repair remains.

Security
Cleared: The diff hardens an availability-sensitive runtime stream path and does not add dependencies, lockfile changes, CI permissions, secret handling, package metadata, or downloaded code execution.

@clawsweeper re-review

🦞 upgrades applied (PR body only):

1. 🦞fix: send plain string message in tau-rpc instead of structured object #25: Design Rationale — 4 WHYs (reuse helper, 16 MiB cap rationale, different constant name, fallback pattern)
2. Telegram integration #16: Risk checklist format (4-question checklist)
3. twilio: rewrite typing indicator with direct API calls and robust retry #19: Sibling refs — fix(anthropic): bound streaming 200 success-body SSE reads at 16 MiB #96701/fix(anthropic): bound streaming 200 success-body SSE reads at 16 MiB (provider path) #96723
4. Heartbeat skipped when last inbound message is from a group chat #20: Reuses existing helper declared — 'no new abstraction'

No code changes.

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

@clawsweeper re-review

Rebased onto current main. The createSseByteGuard helper (originally 87 LoC in this PR) is now in main (via #96762 merge), so the diff no longer includes the helper creation — only the application in streamProxy. Body updated to "Reuses the existing helper from main".

Diff: 2 files, +59/-2 (no more streaming-byte-guard.ts creation). Test count: 5/5.

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Heads up for maintainers: this PR is in re-review loop because three open PRs all touch the same streamProxy loop:

• fix(runtime/proxy): bound streaming success-body SSE reads at 16 MiB #96768 (this PR) — 16 MiB success-body cap via the shared sanitizeOpenAISdkSseResponse guard
• fix(proxy): bound SSE parser via complete-line cap at 1 MiB #97191 (also me) — 1 MiB complete-line cap on the SSE parser (handles the per-line retention path)
• fix: proxy streams fail fast on oversized or stalled responses #97235 (@zhangguiping-xydt) — total SSE cap via shared guard + non-2xx body cap + idle-time backpressure

All three address proxy-stream memory/availability hardening, but at different layers and with different cap values. The ClawSweeper P1 is "coordinate final merge order with the open per-event and broader proxy hardening PRs" — that's a maintainer decision, not something I can resolve as a contributor.

What I see as the relationship:

• fix(proxy): bound SSE parser via complete-line cap at 1 MiB #97191 is the per-line parser cap (1 MiB, complete-line) — narrowest scope, lowest risk
• fix(runtime/proxy): bound streaming success-body SSE reads at 16 MiB #96768 is the total body cap (16 MiB) via shared guard — the most consistent with the SSE/stream campaign pattern
• fix: proxy streams fail fast on oversized or stalled responses #97235 is the broadest (cap + non-2xx + idle backpressure) — biggest behavior change

If maintainers want a single canonical proxy hardening PR, the order I'd suggest is #97191 → #96768 → #97235 (narrow → broad). But the right answer depends on which behavior we want to land, which is a product decision.

Asking maintainers: which layering do you want? Three separate PRs by layer, or one broad PR (#97235) that supersedes the others?

In the meantime, this PR is rated 🐚 with proof sufficient. The re-review loop is purely on the coordination P1.

Closing this in favor of letting main keep its existing coverage.

What I found reading openclaw/main after the last re-review

src/agents/runtime/proxy.ts already has the bounded-read surface this PR is named after:

import { readResponseWithLimit } from "@openclaw/media-core/read-response-with-limit";
import { createSseByteGuard, type SseByteGuard } from "../streaming-byte-guard.js";

const PROXY_ERROR_BODY_MAX_BYTES = 16 * 1024 * 1024;
const PROXY_SSE_STREAM_MAX_BYTES = 16 * 1024 * 1024;
const PROXY_SSE_PENDING_BUFFER_MAX_BYTES = PROXY_SSE_STREAM_MAX_BYTES;
const PROXY_SSE_READ_IDLE_TIMEOUT_MS = 120_000;

And src/agents/runtime/proxy.test.ts already covers the streaming-success-body case the new test would have added:

• line 247 it("caps unterminated pending SSE bytes before a frame delimiter arrives", ...) — chunk stream with no \n\n frame yet, asserts Proxy SSE stream exceeded 16777216 bytes
• line 274 it("caps delimiter-terminated SSE success body bytes", ...) — chunk stream with full-frame over the cap, asserts same error
• line 218 it("bounds non-2xx proxy JSON error reads", ...) — non-2xx path
• line 301 it("re-arms the SSE idle timeout after each received chunk", ...)
• line 510 it("releases the proxy response reader after a terminal stream", ...)

Together those cover: streaming success body (with and without content-length / frame terminator), non-2xx JSON error body, idle timeout re-arm, reader release, EOF-without-terminal — i.e. the same surface the PR's net additions were intending.

Why this PR is no longer the right fit

The diff against main reads as regressive for this surface:

• Removes readResponseWithLimit import and PROXY_ERROR_BODY_MAX_BYTES / PROXY_SSE_STREAM_MAX_BYTES / PROXY_SSE_PENDING_BUFFER_MAX_BYTES constants (lines deleted in proxy.ts)
• Removes the timeoutMs field from ProxySerializableStreamOptions and from buildProxyRequestOptions
• Removes the resolveProxyReadIdleTimeoutMs helper entirely
• Keeps only createSseByteGuard from a relative path (../../agents/streaming-byte-guard.js) — main uses the SDK-barrel form
• Net of proxy.test.ts removes the pendingReaderResponse / resultWithinMs / settledResult helpers and the applies timeoutMs before proxy response headers arrive test that main currently has at line 189

So the PR's "+16/-2 prod + single new test" headline understates the actual change: it replaces proven coverage in main with a strictly narrower subset, and the one "new" test (bounds streamed proxy success bodies without content-length) overlaps the existing line 247 / line 274 tests above.

A clean-PR migration would carry the same regression and the same overlap across — which is exactly the failure mode this PR has been sitting in for the 🔁 re-review loop.

Reference: a comparable successful bounded-read PR

#97628 (fix(google): bound google OAuth fetchWithTimeout arrayBuffer at 16 MiB) just landed 🦞 with the same template (single file + inline test through the production wrapper) against a surface where main had no coverage. That kind of move is the right shape to repeat here if there's a real uncovered gap.

If a follow-up surfaces a genuine streaming-success-body gap not covered by the line-247 / line-274 / line-218 trio, the right next step is a fresh single-commit PR adding only that test plus a one-line production hook — not this refactor.

🤖 Generated with Claude Code