Codex Desktop on Windows: main process RangeError Failed to allocate memory after large terminal/tool output

Codex Desktop on Windows: main process RangeError Failed to allocate memory after large terminal/tool output

What version of the Codex App are you using?

Observed in screenshot stack path:

OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0

Earlier similar local incident was observed on:

OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0

What platform is your computer?

Windows 11, Codex Desktop installed as Windows AppX package.

What issue are you seeing?

Codex Desktop can show a main-process JavaScript error after a large terminal/tool output stream is produced inside a thread.

The error popup says:

A JavaScript error occurred in the main process

Uncaught Exception:
RangeError: Failed to allocate memory
    at createUnsafeBuffer (node:internal/buffer:1095:25)
    at Buffer.allocUnsafeSlow (node:buffer:447:10)
    at createFromString (node:buffer:503:22)
    at fromStringFast (node:buffer:481:12)
    at fromString (node:buffer:518:51)
    at Buffer.from (node:buffer:323:12)
    at readableAddChunkPushByteMode (node:internal/streams/readable:475:22)
    at Readable.push (node:internal/streams/readable:394:5)
    at Readable.read [as _read] (...OpenAI.Codex_26.616.10790.0_x64__2p2nqsd0c76g0\app\resourc...:2745)
    at Readable.read (node:internal/streams/readable:741:12)

This appears to be an Electron/Node main-process buffer allocation failure while handling a large readable stream/string, not a system-wide RAM exhaustion event.

What steps can reproduce the bug?

One local trigger was:

1. Use Codex Desktop on Windows in a workspace with large generated/dependency trees.
2. Run a broad recursive inventory command that prints many thousands of long paths to the terminal/tool output, especially paths under generated folders such as:

• node_modules
• .next
• dist
• build
• release
• runs
• restore-check extraction folders

1. Let the command output flow back into the Codex Desktop thread.
2. Codex Desktop shows a main-process JavaScript error dialog with RangeError: Failed to allocate memory.

The specific local command pattern that likely triggered the latest popup searched recursively under a large workspace for generated/dependency directories and printed a very large CSV-like listing of matching paths. The output included thousands of rows and long node_modules / generated-output paths before truncation.

Expected behavior

Codex Desktop should not crash or throw a main-process JavaScript error when a tool command produces very large output.

Expected handling:

• enforce a hard byte cap before main-process readable stream/string/buffer construction;
• truncate oversized terminal/tool output into a structured "output omitted/truncated" record;
• store full large outputs in a file or artifact when possible instead of trying to materialize them into one main-process string/buffer;
• keep the thread usable after truncation.

Actual behavior

Codex Desktop attempts to handle a large output stream/string in the main process and throws:

RangeError: Failed to allocate memory

The app shows a blocking JavaScript error dialog.

Additional local evidence

A prior local investigation of a similar Codex Desktop memory failure found electron-sampler worker failures:

ERR_WORKER_OUT_OF_MEMORY
Worker terminated due to reaching memory limit: JS heap out of memory

At that time Windows was not physically out of memory. The machine had about 103 GB free physical memory and a large pagefile available. That suggests the failure is inside Codex Desktop/Electron/Node heap or buffer handling rather than ordinary OS RAM exhaustion.

Why this may differ from image-heavy session issues

There are existing reports about image-heavy or oversized session JSONL causing Electron/string allocation failures. This report is focused on a related but separate path: large terminal/tool output from a command, especially recursive generated-folder listings, causing a main-process Node buffer allocation failure.

Proposed fix

At the terminal/tool-output ingestion boundary:

• cap bytes read into main-process buffers/strings;
• stream or page output instead of materializing all output at once;
• truncate with explicit metadata once a threshold is exceeded;
• avoid passing huge stdout/tool payloads through IPC as a single string;
• consider writing large raw output to an artifact file and exposing only a summary in the UI.

Workaround

Users can avoid triggering the issue by writing large inventories to CSV/JSON files and printing only bounded summaries, for example:

$rows | Export-Csv -LiteralPath $out -NoTypeInformation
$rows | Sort-Object SizeMB -Descending | Select-Object -First 20

Unsafe pattern:

Get-ChildItem C:\large-workspace -Recurse | ConvertTo-Csv

But Codex Desktop should defensively cap this output because agents can accidentally generate huge terminal output during normal filesystem inspection.