[diegosouzapw]

Closes #12643

Root cause (short)

handleChatImplementation in src/sse/handlers/chat.ts has a guard family for the messages
field (built up across #5110/#6402/#6407/#6412) that checks array-ness, non-emptiness, and
presence — but never the shape of the individual entries. The route's Zod schema is
intentionally wide (z.array(z.unknown()), per #6402), so messages: [null] or messages: [42]
sailed straight through the guard chain into translation. Two confirmed unguarded crash sites:

• open-sse/translator/request/openai-to-claude.ts — reads .role directly off each entry.
• open-sse/services/sessionManager.ts (extractSystemPrompt) — same, reached from
  generateSessionId earlier in the dispatch path than the translator.
• open-sse/services/contextManager.ts (fixToolPairs) — same unguarded shape assumption.

Any of these turns a malformed client request into an unhandled TypeError, surfacing as a raw
HTTP 500 instead of a clean 400.

Fix

Adds one more entry-shape guard clause to the existing chokepoint in chat.ts, right after the
empty-array check and before the missing-messages check: rejects the request with a 400
("messages: Expected array of objects") when any entry is null, a non-object primitive, or an
array (arrays are typeof "object" but not valid message objects).

Regression test

tests/unit/chat-messages-entry-objects-12643.test.ts (built on the existing
tests/integration/_chatPipelineHarness.ts harness).

RED (on unfixed release/v3.8.51 tip):

✖ #12643: messages: [null] is rejected with a clear 400
  TypeError: Cannot read properties of null (reading 'role')
      at sessionManager.ts:362:45 (extractSystemPrompt)
✖ #12643: messages with string/number entries are rejected with a clear 400
  AssertionError: must be a 400: [{"role":"user","content":"hi"},"oops"]
  502 !== 400
ℹ pass 1
ℹ fail 2

GREEN (with the fix):

✔ #12643: messages: [null] is rejected with a clear 400
✔ #12643: messages with string/number entries are rejected with a clear 400
✔ #12643: well-formed messages pass the entry guard
ℹ tests 3
ℹ pass 3
ℹ fail 0

Gates run

• npx eslint --suppressions-location config/quality/eslint-suppressions.json src/sse/handlers/chat.ts tests/unit/chat-messages-entry-objects-12643.test.ts — clean, no new warnings.
• npm run typecheck:core — clean.
• node scripts/check/check-file-size.mjs — src/sse/handlers/chat.ts is a frozen file; this
  irreducible +10-line guard at the existing chokepoint bumps it 2462→2472 with a matching
  rebaseline note in config/quality/file-size-baseline.json (same pattern as prior small-guard
  growths in this file, e.g. fix(responses-continuation): chain off the effective post-reconstruction input, not the pre-reconstruction client bytes #12641, fix(combo): treat a pin-only step as implicit connection allowlist #12697, feat(providers): add weekly quota tracking for grok-web #8127). open-sse/utils/stream.ts remains red —
  pre-existing base drift untouched by this PR (already 3115>3098 on the pure tip per its own
  baseline note; base-red 🔴 Release branch not green: release/v3.8.51 #12732, owned by /sweep-reds).
• node scripts/check/check-complexity.mjs — OK (2824 violations vs baseline 3218).
• node scripts/check/check-cognitive-complexity.mjs — OK (1276 violations vs baseline 1437).
• node scripts/check/check-test-discovery.mjs — OK, new test file discovered.

Existing tests aligned

None — no existing assertion encoded the old buggy contract. Ran the sibling guard suites for
regression: tests/unit/chat-messages-validation-6402.test.ts + tests/unit/chat-non-string-model-6407.test.ts
— 22/22 pass, no regression.

Credit

PR #12644 (@soroush5) proposed this exact fix — same guard shape, same error message — but was
closed on 2026-09-12 without merging, so the bug never actually shipped. This PR re-implements it
fresh against the current tip. Originally-proposed-by / Co-authored-by trailers added on the
commit.