Feature request: expose willRetry in codex exec --json error events

Open 💬 0 comments Opened Jul 14, 2026 by mchtech

What version of Codex is running?

codex-cli 0.142.0

What issue are you seeing?

When Codex encounters a retryable stream error, codex exec --json emits:

{
  "type": "error",
  "message": "Reconnecting... 1/5 (stream disconnected before completion: ...)"
}

Codex continues retrying the same turn and may later emit tool calls or complete successfully.

For integrations consuming the JSONL stream, retryable and terminal errors currently have the same observable shape. The only available workaround is parsing the human-readable Reconnecting... message.

Comparable behavior

Claude Code exposes retries as a machine-readable stream event:

{
  "type": "system",
  "subtype": "api_retry",
  "attempt": 1,
  "max_retries": 10,
  "error_status": 429
}

Consumers can record the failure and continue reading the stream without treating it as terminal.

What would you like to see?

Expose the retry state through the JSONL contract. For example:

{
  "type": "error",
  "message": "Reconnecting... 1/5 (...)",
  "will_retry": true
}

A separate retry event type would also provide the required distinction.

The app-server protocol already carries this information:

  • ErrorNotification contains will_retry.
  • Stream errors are converted to ErrorNotification with will_retry: true.

The codex exec --json adapter currently converts the notification into ThreadErrorEvent { message }, dropping will_retry.

Why is this useful?

Downstream integrations can keep turn-scoped resources alive during retries and clean them up only after a terminal error, without depending on English message parsing.

Related issue

View original on GitHub ↗