Srihari Sriraman shared in

Public

Handled terminated error in Codex responsesPublic

Agent

Model

Claude Opus 4.5 (latest)

Started

Jan 22, 8:27 PM

Messages58

Downloads0

Summary

Closed, Completed

Understand
Confirmed model and provider consistency.
Understand
Understand
Investigated source of 'terminated' error.
Understand
Edit
Added retry logic for 'terminated' errors.
Edit
Edit
Updated changelog with fix.
Edit

there's ~/Downloads/505349d6-b535-449f-9513-f277525708e1.jsonl. plese analyze how it came to the terminated failure

The session shows a code review task that failed during the model's response phase. Here's the breakdown:

Timeline:

19:00:19 - Session started
19:00:22 - User requested code review of a git diff
19:00:26 - Model (gpt-5.2-codex via openai-codex provider) called git diff
19:00:26 - Tool returned ~400 lines of diff (changes to extension system, before_bash_exec event, tool_result error handling)
19:00:42 - Model attempted to respond but was terminated

The failure:

Root cause analysis:

The zero token usage in the final message is the key indicator. The model started a thinking block ("Reviewing error handling in tool execution...") but the response was cut off before any tokens were actually counted.

This "terminated" error with zero usage typically means:

The API stream was severed before completion
Could be a provider-side timeout (the diff was substantial)
Could be connection dropped mid-response
Could be the Codex API rate-limited or terminated the request

The model was in the middle of reasoning about the code changes when it got cut off. It never produced any actual review findings because the stream died during the thinking phase.

Not a logic error in the code being reviewed. The failure is an infrastructure/API issue with the openai-codex provider.

what provider and model? was there a model or provider switch somewhere?

Looking at both assistant messages:

Message 1 (tool call):

api: openai-codex-responses
provider: openai-codex
model: gpt-5.2-codex

Message 2 (terminated):

api: openai-codex-responses
provider: openai-codex
model: gpt-5.2-codex

No switch. Same provider and model throughout. The session used gpt-5.2-codex via the openai-codex provider for both turns, and failed on the second turn during the thinking phase.

that's implemented in @packages/ai/src/providers/openai-codex-responses.ts check when and how it emits that error

The word "terminated" doesn't appear in this file. Let me search for where it's emitted:

Not found in our code. Let me check if it could come from the API response itself by looking at error handling more closely:

The "terminated" message isn't in our codebase. Looking at the error handling in the provider:

This is the source. The Codex API sent a response.failed SSE event with:

The provider extracts response.error.message and throws it directly, resulting in errorMessage: "terminated".

Summary: The failure came from the Codex API itself. The server terminated the response mid-stream (after the thinking started but before any output tokens were generated). This is why:

Usage shows 0/0 tokens (no response.completed event received)
The thinking was cut off mid-sentence
The error is just "terminated" (server-side termination reason)

This is an OpenAI Codex backend issue, not a pi bug. The server decided to terminate the response for some internal reason (could be timeout, resource limits, content policy, or infrastructure issue on their end).

does the provider have retry?

Yes, but only for the initial connection:

typescript

const MAX_RETRIES = 3;const BASE_DELAY_MS = 1000;
function isRetryableError(status: number, errorText: string): boolean {    if (status === 429 || status === 500 || status === 502 || status === 503 || status === 504) {        return true;    }    return /rate.?limit|overloaded|service.?unavailable|upstream.?connect|connection.?refused/i.test(errorText);}

The retry loop covers:

HTTP status errors (429, 5xx)
Network errors before streaming starts

No retry for mid-stream failures. Once response.ok is true and processStream() is called, any response.failed event (like the "terminated" one) just throws and exits. The stream was already in progress when the server terminated it.

To handle this case, you'd need retry logic that:

Detects mid-stream termination
Rebuilds the request with the conversation so far
Retries the entire turn

That's more complex since you'd need to track what content was already emitted and potentially deduplicate or handle partial tool calls.

i think @packages/coding-agent/src/core/agent-session.ts implements retry

Yes, agent-session.ts has retry logic, but "terminated" is not in the retryable patterns:

typescript

private _isRetryableError(message: AssistantMessage): boolean {    if (message.stopReason !== "error" || !message.errorMessage) return false;
    // Context overflow is handled by compaction, not retry    const contextWindow = this.model?.contextWindow ?? 0;    if (isContextOverflow(message, contextWindow)) return false;
    const err = message.errorMessage;    // Match: overloaded_error, rate limit, 429, 500, 502, 503, 504, service unavailable, connection errors, fetch failed    return /overloaded|rate.?limit|too many requests|429|500|502|503|504|service.?unavailable|server error|internal error|connection.?error|connection.?refused|other side closed|fetch failed|upstream.?connect|reset before headers/i.test(        err,    );}

The error "terminated" doesn't match any of these patterns, so it falls through without retry.

Fix: Add terminated to the regex pattern:

typescript

return /overloaded|rate.?limit|too many requests|429|500|502|503|504|service.?unavailable|server error|internal error|connection.?error|connection.?refused|other side closed|fetch failed|upstream.?connect|reset before headers|terminated/i.test(    err,);

This would allow the agent session to auto-retry when Codex terminates a response mid-stream.

add it, commit and push

Done. Pushed 9b84857b:

Added terminated to the retryable error regex in agent-session.ts
Updated CHANGELOG with the fix

Now when Codex returns "terminated" mid-stream, the agent will auto-retry with exponential backoff instead of failing immediately.

const MAX_RETRIES = 3;const BASE_DELAY_MS = 1000; function isRetryableError(status: number, errorText: string): boolean { if (status === 429 || status === 500 || status === 502 || status === 503 || status === 504) { return true; } return /rate.?limit|overloaded|service.?unavailable|upstream.?connect|connection.?refused/i.test(errorText);}

private _isRetryableError(message: AssistantMessage): boolean { if (message.stopReason !== "error" || !message.errorMessage) return false; // Context overflow is handled by compaction, not retry const contextWindow = this.model?.contextWindow ?? 0; if (isContextOverflow(message, contextWindow)) return false; const err = message.errorMessage; // Match: overloaded_error, rate limit, 429, 500, 502, 503, 504, service unavailable, connection errors, fetch failed return /overloaded|rate.?limit|too many requests|429|500|502|503|504|service.?unavailable|server error|internal error|connection.?error|connection.?refused|other side closed|fetch failed|upstream.?connect|reset before headers/i.test( err, );}