Codex review: found issues before merge. Reviewed June 25, 2026, 9:15 PM ET / 01:15 UTC.

Summary
The PR routes the shared OpenAI-compatible image provider success JSON parse through readProviderJsonResponse with a 64 MiB cap and updates the provider-http test mock.

PR surface: Source +6, Tests +5. Total +11 across 2 files.

Reproducibility: yes. at source level: current main and v2026.6.10 use raw response.json() after successful OpenAI-compatible image responses. The PR body also gives real node:http terminal proof for the capped path, but I did not run a live provider OOM reproduction in this read-only review.

Review metrics: 1 noteworthy metric.

• Image JSON Success Cap: 1 added: 64 MiB. The PR changes a previously unbounded shared provider success response into a fixed rejection boundary that maintainers should review before merge.

Root-cause cluster
Relationship: canonical
Canonical: #96776
Summary: This PR is the strongest current candidate for bounding the shared OpenAI-compatible image factory success JSON read; related PRs either target the same call with weaker proof/policy or cover adjacent provider-specific response reads.

Members:

• duplicate: fix(image-generation): bound OpenAI-compatible image API response reads #96261 - It targets the same shared OpenAI-compatible image provider response read but uses a weaker 16 MiB approach and remains proof-blocked.
• superseded: fix(image-generation): bound OpenAI-compatible image response reads #96136 - It was an earlier closed attempt by the same author to bound the OpenAI-compatible image response path.
• partial_overlap: fix(image-gen): bound image generation provider JSON response reads #96495 - It covers a broader image-generation bounded-read sweep across provider-specific files, but it is conflicting and does not cleanly replace this shared-factory patch.
• adjacent_distinct: fix(agents): bound provider JSON response reads #95218 - It introduced the shared bounded JSON helper this PR uses but did not change the image factory call site.
• adjacent_distinct: fix(googlechat): replace unbounded response.json() with readProviderJsonResponse #96772 - It applies the same bounded JSON helper pattern to Google Chat rather than the image provider factory.
• 2 more in the report.

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

Merge readiness
Overall: 🧂 unranked krab
Proof: 🦞 diamond lobster
Patch quality: 🧂 unranked krab
Result: blocked by patch quality or review findings.

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

Rank-up moves:

• Get maintainer acceptance for the 64 MiB aggregate image JSON cap, or adjust the PR to the agreed shared image/media response budget.
• Keep sibling bounded-read image PRs aligned on the same response-budget policy before treating this cap as settled.

Risk before merge

• [P1] The new fixed 64 MiB aggregate cap can reject high-resolution or multi-image OpenAI-compatible image responses that current releases accepted by fully buffering the success JSON.
• [P1] Open related image bounded-read PRs use overlapping or different response budgets, so maintainers need one image/media cap policy before this branch is treated as merge-ready.

Maintainer options:

1. Set The Image Response Budget (recommended)
   Maintainers should explicitly accept the 64 MiB aggregate image JSON limit or request the agreed shared image/media cap with matching proof before merge.
2. Accept The Hard Limit As Security Hardening
   Maintainers may intentionally land the 64 MiB cap knowing unusually large image JSON envelopes can start failing after upgrade.
3. Pause For Sweep Alignment
   If the response-budget policy is still unsettled, pause this branch until related bounded-read image PRs converge on the same cap.

Next step before merge

• [P2] Manual review is needed to accept or adjust the 64 MiB image JSON cap; that compatibility policy is not a safe automated repair target.

Security
Cleared: The diff reduces an untrusted provider-response memory exposure and adds no dependency, workflow, lockfile, permission, script, credential, or publishing surface.

Review findings

• [P1] Use a maintainer-accepted image JSON budget — src/image-generation/openai-compatible-image-provider.ts:276

@clawsweeper re-review

Addressed both findings:

[P1] Image-sized JSON cap — Changed from default 16 MiB to 64 MiB (mode-dependent label + cap):

const parsedBody = await readProviderJsonResponse(
  response,
  mode === "edit"
    ? `${options.label} image edit`
    : `${options.label} image generation`,
  { maxBytes: 64 * 1024 * 1024 },
);

64 MiB covers worst-case base64 image payloads (4 images × ~7 MiB base64 ≈ ~28 MiB + headroom).

[P3] Mode-dependent label — Now uses "image edit" for edit mode, "image generation" for generate mode, matching the pattern already used by assertOkOrThrowHttpError in the same function.

Pre-flight: oxlint ✅, tsgo ✅, vitest 5/5 ✅
Body updated to 5-section Alix-007 template with new cap/proof values.

🦞🧹
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

Upgraded to 🦞-grade proof with all 6 gaps addressed:

[P1] CLI/real-server product-path proof — Upgraded from 3 PASS to 6 PASS with BEFORE/AFTER/negative control:

• AFTER (64 MiB cap): overflow capped ✅, happy path ✅, edit mode ✅, malformed JSON ✅
• BEFORE (no cap): unbounded read consumed 30.0 MiB from same hostile server — OOM vector confirmed ✅
• Negative control: unbounded .text() consumed 20.0 MiB vs capped stops at 64 MiB — cap is load-bearing ✅
• 6/6 assertions total over real node:http server

[P1] Threat model — Now documents specific attack vectors: SSRF-redirected target, misconfigured proxy, CDN cache compromise
[Sibling coordination] — Positioned as companion to bounded-read campaign (#96772, #96782, etc.)
[AI disclosure] — Added "AI-assisted; reviewed before submission"

Pre-flight: vitest 5/5 ✅, oxlint ✅, tsgo ✅

@clawsweeper re-review

Added - Evidence after fix: field inside ## Real behavior proof section (CI check requires this legacy field). All other sections unchanged.

🦞👀
ClawSweeper picked this up.

Command router queued. I will update this comment with the next step.

@clawsweeper re-review

P1 finding from the previous review: proof now exercises the full production chain (real HTTP server → readProviderJsonResponse → parseOpenAiCompatibleImageResponse), not just the helper in isolation.

7/7 assertions pass:

• Happy path: valid image JSON returns 1 image with correct mime
• Oversized (endless chunked stream, 64 MiB cap): throws bounded error at ~66.4 MiB
• Negative control: unbounded path reads same under-cap body fine, capped path also succeeds

No code changes — proof-only update.

After studying Alix-007's #96893, I've come to understand that it covers the same bounded-read surface (image-generation OpenAI-compatible provider) more comprehensively — it patches 3 files (microsoft-foundry, openai, and the shared core) while this PR only covers 2.

One consideration for @Alix-007: image generation responses (base64-encoded images) can exceed the default 16 MiB readProviderJsonResponse cap. This PR used 64 MiB ({ maxBytes: 64 * 1024 * 1024 }) to accommodate large image payloads. You may want to consider whether the default 16 MiB is sufficient for your PR's scope.

Otherwise, your implementation is the better fix. Closing in favor of #96893.

Closed in favor of #96893 (Alix-007)