codex issue

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #28150
• #27680

Powered by Codex Action

I can reproduce the same main-process crash on macOS with the same JP.write -> Socket.onStdoutData shape. Adding sanitized local details in case it helps triage.

Environment

• Platform: macOS 26.4.1 (25E253), arm64
• Hardware: MacBook Pro, Apple M3 Pro, 36 GB RAM
• Codex app: 26.609.71450 (CFBundleVersion 3965), bundle id com.openai.codex
• Codex CLI on PATH: codex-cli 0.139.0
• Install path: /Applications/Codex.app

Error dialog

A JavaScript error occurred in the main process

Uncaught Exception:
RangeError: Invalid string length
at JP.write (/Applications/Codex.app/Contents/Resources/app.asar/.vite/build/src-fg9h3MDi.js:368:21)
at Socket.onStdoutData (/Applications/Codex.app/Contents/Resources/app.asar/.vite/build/src-fg9h3MDi.js:368:4146)
at Socket.emit (node:events:508:28)
at addChunk (node:internal/streams/readable:563:12)
at readableAddChunkPushByteMode (node:internal/streams/readable:514:3)
at Readable.push (node:internal/streams/readable:394:5)
at Pipe.onStreamRead (node:internal/stream_base_commons:189:23)

Observed behavior

• The modal could not be dismissed normally; clicking OK / trying to quit left Codex unusable.
• osascript -e 'tell application id "com.openai.codex" to quit' returned user canceled (-128).
• I had to terminate the Codex desktop process tree manually. After SIGTERM to the main /Applications/Codex.app/Contents/MacOS/Codex process, I also cleaned up leftover Codex Radar Sentinel, crashpad_handler, bare-modifier-monitor, and old codex app-server / node_repl helper processes.

Size clue

This machine has a very large Codex session store:

~/.codex/sessions total: ~11 GB
largest rollout JSONL: ~/.codex/sessions/<yyyy>/<mm>/<dd>/rollout-<redacted>.jsonl ~= 1910 MB
rollout files > 500 MB: 1 observed

The crash happened after long, media-heavy Codex Desktop usage. This seems consistent with the hypothesis in #22004 that the desktop main process is buffering a large runtime/stdout payload into one JS string and eventually hitting V8's maximum string length. The important difference here is that this is on macOS/Apple Silicon and on app version 26.609.71450, with the minified writer name now showing as JP.write.

Further debugging update from the same macOS repro, with local content redacted.

What I found

The crash was tied to one specific conversation. Opening that conversation in Codex Desktop triggered the RangeError: Invalid string length dialog immediately.

The matching local rollout file under ~/.codex/sessions/<yyyy>/<mm>/<dd>/rollout-<redacted>.jsonl had grown to about 1.9 GB:

rollout size before recovery: ~1908.5 MB
JSONL lines: 16,862
largest single JSONL line: ~12.1 MB
rollout files > 500 MB in ~/.codex/sessions: 1

Structural stats from parsing the JSONL, without printing private message content or image bytes:

record type counts:
  response_item: 12062
  event_msg:      4724
  turn_context:     40
  compacted:        29
  session_meta:      7

payload type counts:
  function_call:          3695
  function_call_output:   3694
  token_count:            2247
  message:                2176
  agent_message:          1952
  reasoning:              1940
  image_generation_call:   156
  image_generation_end:    156

The large payloads were not normal terminal output. function_call_output text output was only a small part of the useful history. The growth came from image payloads being persisted inline in multiple places:

large image/base64 locations observed:
  payload.result                                      # image_generation_call / image_generation_end
  payload.output[*].image_url                         # function_call_output image URLs
  payload.replacement_history[*].content[*].image_url  # compacted history

Approximate byte distribution before recovery:

image_generation_end:   ~553 MB
image_generation_call:  ~553 MB
compacted records:      ~269 MB
function_call_output:   ~505 MB total on disk, mostly image_url payloads rather than shell text

After replacing only embedded image/base64 strings with a tiny 1x1 PNG placeholder while preserving the JSONL event structure and all text fields:

rollout size after recovery: ~34.5 MB
redacted image strings:
  data:image/... strings: 405
  raw PNG/JPEG/WebP/GIF-looking large base64 strings in image fields: 315
remaining rollout files > 500 MB: 0

After that rewrite, Codex Desktop launched again without the Invalid string length / JP.write / Socket.onStdoutData crash. The tradeoff is that historical generated/attached images in that conversation become placeholders, but the text history and event structure remain loadable.

Inferred failure mode

This looks like a session-loading / stdout-framing issue rather than a renderer issue:

1. A media-heavy session stores large binary artifacts inline as base64 in JSONL.
2. Compaction can duplicate those image payloads into replacement_history, multiplying the same large strings.
3. When Desktop opens the conversation, the runtime streams a very large payload to the Electron main process.
4. The main process writer (JP.write in this build) appears to aggregate stdout into one JavaScript string.
5. Once the aggregate exceeds V8's maximum string length, RangeError: Invalid string length is thrown uncaught, leaving the app in a crash loop / non-dismissible modal state.

Suggested fix directions

A robust fix probably needs more than raising a limit:

• Do not store large generated/attached images inline in rollout JSONL. Store binary artifacts separately and reference them by file/blob id.
• Exclude image/base64 payloads from compaction replacement_history, or replace them with stable artifact references before compaction.
• Add a hard per-field / per-event size limit for session persistence, especially for image_url, result, and data fields.
• Do not aggregate arbitrary runtime stdout into one JS string in the Electron main process; use framed/streamed messages, chunk limits, and backpressure.
• Catch RangeError around the stdout writer so one bad session cannot crash the whole app.
• On startup or conversation open, detect oversized rollouts and offer a recovery path: quarantine, open text-only, or automatically strip media payloads while preserving the original file.
• Consider a migration that rewrites existing oversized sessions into text + external artifacts, because reinstall/reset does not help if the same large rollout remains in ~/.codex/sessions.

This was reproduced on macOS/Apple Silicon with Codex app 26.609.71450 (CFBundleVersion 3965). The stack in the dialog was the same shape as above: JP.write -> Socket.onStdoutData -> Readable.push -> Pipe.onStreamRead.