Codex Responses: CRLF event streams parse as an empty successful turn, the final event is dropped, and non-retryable 4xx are retried

[Jiaaqiliu]

Environment. prime-agent 0.7.3, main at f8f0036, Node 22.17.0, macOS 15 (darwin 25.5.0).

Summary

Three defects in the OpenAI Codex Responses provider, all on the same request/parse path. The first one is the concerning one: on a CRLF event stream the provider yields a successful, empty, zero-usage assistant turn instead of an error.

1. parseSSE frames events on a literal "\n\n"

providers/openai-codex-responses.ts:517:

let idx = buffer.indexOf("\n\n");
while (idx !== -1) { ... }

SSE separates events with a blank line, which on the wire is CRLF for a spec-compliant server and for anything behind a proxy that rewrites line endings. \r\n\r\n contains no two consecutive \n, so indexOf is permanently -1. No event is ever yielded, buffer grows for the whole response, and processResponsesStream sees an empty iterator — so output.stopReason keeps its "stop" initializer and nothing raises.

Feeding the repo's own event list from test/openai-codex-stream.test.ts CRLF-delimited produces content: [], usage: {..., totalTokens: 0}, stopReason: "stop".

providers/anthropic.ts:298-325 already handles \r, \n, and \r\n via nextLineBreakIndex/consumeLine. parseSSE does not.

2. The final event is dropped when the body does not end with a blank line

The read loop only emits what indexOf can carve out, then breaks straight into the finally. There is no trailing flush of buffer and no final decoder.decode(). For Codex the last event is response.completed, which sets usage, cost, and the toolUse promotion in openai-responses-shared.ts:472. So the turn reports zero tokens and zero cost, and a tool-calling turn is reported as stop — the agent loop stops instead of running the tools. anthropic.ts:359-380 does this correctly.

3. The retry loop retries every non-retryable status

openai-codex-responses.ts:238:

if (attempt < MAX_RETRIES && isRetryableError(response.status, errorText)) { ...; continue; }
const info = await parseErrorResponse(fakeResponse);
throw new Error(info.friendlyMessage || info.message);   // the "do not retry" path
} catch (error) {                                        // catches the line above
    ...
    if (attempt < MAX_RETRIES && !lastError.message.includes("usage limit")) { ...; continue; }

The throw that expresses "this status is not retryable" sits inside the same try, so the generic catch swallows it and retries anyway. isRetryableError only decides which branch does the sleeping. Mocking a 400 {"error":{"code":"invalid_request_error","message":"bad model"}} produces 4 requests and about 7s of backoff. The same applies to 401, which re-sends a known-bad token three extra times.

Suggested fix

• Normalize line endings when appending to the buffer, holding back a trailing CR so a chunk boundary landing inside a CRLF pair is not turned into two newlines and does not split an event in half.
• Flush the decoder and emit the remaining buffer when the reader reports done.
• Raise a distinct error type on the non-retryable path and rethrow it in the catch, so isRetryableError actually decides.

---

I have a fix with a regression test on a branch: fix/codex-sse-framing-and-retries. npm run check passes and the surrounding suites still pass. I opened it as a PR first and the contribution gate closed it, which is what CONTRIBUTING.md says should happen, so I am bringing it here instead. Happy to leave it as is, adjust it, or drop it entirely if you would rather fix this differently.