Codex macOS app crashes (Oops / Maximum call stack size exceeded in AppRoutes)

I hit the same Oops / Maximum call stack size exceeded on macOS today, and captured a reproducible pattern that may help isolate root cause.

Observed failure pattern

• Crash happens after thread/resume succeeds, not at initial app bootstrap.
• In logs, sequence is consistently:

1. method=thread/resume ... conversationId=<id>
2. maybe_resume_success ... markedStreaming=true
3. ~2-4s later: errorMessage="Maximum call stack size exceeded" name=AppRoutes

• Reinstalling app did not fix it, because problematic state persisted under ~/.codex.

Example (latest run):

• codex-desktop-28ec94f2-cf9e-41a5-9651-49bfcf856050-11846-t0-i1-081948-0.log
• thread/resume for 019be50d-32f0-7fc0-a329-6a3f6534e631
• then stack overflow in AppRoutes

Additional evidence

Multiple conversation IDs triggered the same sequence on my machine across restarts/project switches:

• 019c8d4d-6156-7b63-8100-dbf85f29542d
• 019c0410-0a08-7100-a16e-c6159c5089cd
• 019c2148-a669-7062-9c03-d0e0425d4b75
• 019bfe31-956d-7cd2-85ed-d4863f7904e5
• 019be50d-32f0-7fc0-a329-6a3f6534e631
• 019c9381-dc5d-7fe2-b969-5557d1a4308a

One older resumed rollout for 019bfe31... had >4k items (Resumed rollout with 4074 items in TUI log), but I also saw crashes on smaller files, so this may be more than pure file size.

Temporary workaround that restored usability

• Quarantine offending session files from ~/.codex/sessions/**/rollout-*-<conversationId>.jsonl
• Remove corresponding session_id rows from ~/.codex/history.jsonl
• Rotate local index DB (~/.codex/sqlite/codex-dev.db)

After removing the set of IDs above, app started normally again.

---

Hypothesis: frontend route/render path is vulnerable to specific persisted thread payload/state during auto-resume, and recovery path keeps selecting another bad thread until all problematic sessions are removed.

energyplus_schema_fields.txt

After verifying multiple times, I found that the issue reproduces whenever the file mentioned above is present in the workspace. If I remove that file from the workspace, the problem no longer occurs.

Additionally, simply placing that file into a different workspace also triggers the same error.

I tried quitting the app, moving ~/.codex to ~/.codex.bak, starting, logging in again, opening same folder in which I was previously working. Same "Oops" issue when trying to run the same prompt in the same folder.

I'm experiencing the same issue: Starting new threads or opening existing ones repeatedly causes the error "Oops, an error has occurred Try again". The error happens in a specific project, while threads in other projects do not appear to be affected.

Renaming ~/.codex to ~/.codex.backup-{timestamp} and restarting Codex did not solve the issue. New threads in a specific repository / project keep leading to this error loop.

The latest logs also contain errorMessage="Maximum call stack size exceeded".

Last lines of latest logs:

2026-02-25T17:08:05.971Z info [ElectronAppServerConnection] response_routed broadcastFallback=false conversationId=019c95af-2c8c-7d10-8124-55ba781d5267 durationMs=29 errorCode=null hadInternalHandler=false hadPending=true method=thread/resume originWebcontentsId=1 requestId=1f49d142-f211-4bf9-ba17-35292378aa97 targetDestroyed=false
2026-02-25T17:08:05.972Z info [electron-message-handler] maybe_resume_success conversationId=019c95af-2c8c-7d10-8124-55ba781d5267 latestTurnId=019c95af-9c89-7561-90d7-e681bd1a29f7 latestTurnStatus=completed markedStreaming=true turnCount=1
2026-02-25T17:08:27.289Z info [ElectronAppServerConnection] response_routed broadcastFallback=false conversationId=null durationMs=60 errorCode=null hadInternalHandler=false hadPending=true method=mcpServerStatus/list originWebcontentsId=1 requestId=5fb63108-bf7c-4c36-a1fc-a72a8d402163 targetDestroyed=false
2026-02-25T17:09:02.452Z error [electron-message-handler] error boundary componentStack="\n    at xoe (app://-/assets/index-DYrX9Gof.js:2908:181)\n    at BTn (app://-/assets/index-DYrX9Gof.js:2933:17418)\n    at div (<anonymous>)\n    at div (<anonymous>)\n    at Activity (<anonymous>)\n    at div (<anonymous>)\n    at div (<anonymous>)\n    at div (<anonymous>)\n    at Tbn (app://-/assets/index-DYrX9Gof.js:2611:63658)\n    at div (<anonymous>)\n    at div (<anonymous>)\n    at $Ve (app://-/assets/index-DYrX9Gof.js:2611:79436)\n    at dD (app://-/assets/index-DYrX9Gof.js:2611:106160)\n    at div (<anonymous>)\n    at aqe (app://-/assets/index-DYrX9Gof.js:2611:96011)\n    at dqe (app://-/assets/index-DYrX9Gof.js:2611:105661)\n    at hD (app://-/assets/index-DYrX9Gof.js:2611:107681)\n    at div (<anonymous>)\n    at div (<anonymous>)\n    at PTn (app://-/assets/index-DYrX9Gof.js:2933:13929)\n    at $Tn (app://-/assets/index-DYrX9Gof.js:2933:19346)\n    at RYe (app://-/assets/index-DYrX9Gof.js:69:3356)\n    at ev (app://-/assets/index-DYrX9Gof.js:69:7198)\n    at div (<anonymous>)\n    at div (<anonymous>)\n    at div (<anonymous>)\n    at div (<anonymous>)\n    at b9t (app://-/assets/index-DYrX9Gof.js:260:82932)\n    at W6t (app://-/assets/index-DYrX9Gof.js:260:54195)\n    at v9t (app://-/assets/index-DYrX9Gof.js:260:82643)\n    at IOt (app://-/assets/index-DYrX9Gof.js:1626:142313)\n    at DOt (app://-/assets/index-DYrX9Gof.js:1626:143013)\n    at RYe (app://-/assets/index-DYrX9Gof.js:69:3356)\n    at ev (app://-/assets/index-DYrX9Gof.js:69:7198)\n    at rAn (app://-/assets/index-DYrX9Gof.js:2933:23607)\n    at RYe (app://-/assets/index-DYrX9Gof.js:69:3356)\n    at UYe (app://-/assets/index-DYrX9Gof.js:69:8225)\n    at sPn (app://-/assets/index-DYrX9Gof.js:2964:2853)\n    at aNn (app://-/assets/index-DYrX9Gof.js:2951:169317)\n    at ese (app://-/assets/index-DYrX9Gof.js:2366:2253)\n    at nNn (app://-/assets/index-DYrX9Gof.js:2951:159930)\n    at yIn (app://-/assets/index-DYrX9Gof.js:2951:71615)\n    at YPn (app://-/assets/index-DYrX9Gof.js:1626:184625)\n    at v (app://-/assets/shiki-highlight-provider-DIqPaiKF.js:1:142)\n    at Suspense (<anonymous>)\n    at uPn (app://-/assets/index-DYrX9Gof.js:2964:3595)\n    at c (app://-/assets/index-DYrX9Gof.js:216:4085)\n    at ZSe (app://-/assets/index-DYrX9Gof.js:260:29607)\n    at D6t (app://-/assets/index-DYrX9Gof.js:260:37354)\n    at jvt (app://-/assets/index-DYrX9Gof.js:260:160593)\n    at _In (app://-/assets/index-DYrX9Gof.js:2951:72417)\n    at e (app://-/assets/index-DYrX9Gof.js:212:6204)\n    at cNn (app://-/assets/index-DYrX9Gof.js:2951:170041)\n    at a (app://-/assets/index-DYrX9Gof.js:1622:203360)\n    at s (app://-/assets/index-DYrX9Gof.js:1622:202685)\n    at oDn (app://-/assets/index-DYrX9Gof.js:2951:114715)\n    at sDn (app://-/assets/index-DYrX9Gof.js:2951:113515)\n    at dNn (app://-/assets/index-DYrX9Gof.js:2951:173338)\n    at kIn (app://-/assets/index-DYrX9Gof.js:2951:76463)\n    at r9t (app://-/assets/index-DYrX9Gof.js:260:73319)\n    at ZDn (app://-/assets/index-DYrX9Gof.js:2951:151879)\n    at QDn (app://-/assets/index-DYrX9Gof.js:2951:154944)\n    at HYe (app://-/assets/index-DYrX9Gof.js:69:7387)\n    at zYe (app://-/assets/index-DYrX9Gof.js:69:6174)\n    at WZe (app://-/assets/index-DYrX9Gof.js:26:7222)\n    at JXe (app://-/assets/index-DYrX9Gof.js:69:58876)\n    at KNn (app://-/assets/index-DYrX9Gof.js:2958:2210)\n    at MIn (app://-/assets/index-DYrX9Gof.js:2951:78528)\n    at UNn (app://-/assets/index-DYrX9Gof.js:2958:558)" errorMessage="Maximum call stack size exceeded" errorName=Error errorStack="Error: Maximum call stack size exceeded" name=AppRoutes

Version 26.224.1209 (697)
macOS Tahoe 26.2
thread id: 019c95af-2c8c-7d10-8124-55ba781d5267

I use the codex command line interface as a rescue - that works on the same source tree that the app fails in. The app also fails when creating a new thread for that source tree.

I've run into exactly the same problem. Reinstalling the latest version of Codex still causes crashes.
It doesn't crash right after a fresh install if I do nothing, but as soon as I open a thread or create a new thread, it crashes immediately.

I'm having the same issue, it's completely due to the last update, can we roll back to the previous version?

Plus subscription. Same issue.

FWIW, It seems today's update - 26.226.940 (720)- is workig fine .. after this update the same threads which were causing crash yesterday, is working fine now.

It got resolved in a weird way. I continued with the project from CLI. Later I started the desktop app and it somehow stoped producing the error and got unblocked.

I'm having the same issue, it's completely due to the last update, can we roll back to the previous version?

nice, the new version released 5 hours later fixed this issue, although the project is still laggy, it no longer crashes

It’s Version 26.226.940 (720), and it seems the issue has been resolved.