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

[wibaek]

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.224.1209 (697)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.2.0 arm64 arm

What issue are you seeing?

When I open a workspace folder containing 8 Python projects (each is a separate project directory), Codex shows “Oops, an error has occurred” and the UI crashes.
The logs show an error boundary with:
errorMessage="Maximum call stack size exceeded" name=AppRoutes

What steps can reproduce the bug?

1. Launch Codex app
2. Press Cmd+O
3. Select/open folder:
   • This folder contains 8 Python project subfolders
4. Codex immediately shows “Oops, an error has occurred” and becomes unusable

What is the expected behavior?

No response

Additional information

• Repo Total size: 241M

error log

2026-02-25T08:13:17.040Z info [electron-message-handler] [desktop-notifications] service starting
2026-02-25T08:13:17.156Z info [electron-message-handler] Handled 'ready' message, sent ide-context-updated
2026-02-25T08:13:17.188Z info [ElectronAppServerConnection] response_routed broadcastFallback=false conversationId=null durationMs=111 errorCode=null hadInternalHandler=false hadPending=true method=experimentalFeature/list originWebcontentsId=1 requestId=d2413c0a-4c2e-47ff-8bf6-28becd0852be targetDestroyed=false
2026-02-25T08:13:17.216Z info [ElectronAppServerConnection] response_routed broadcastFallback=false conversationId=null durationMs=94 errorCode=null hadInternalHandler=false hadPending=true method=mcpServerStatus/list originWebcontentsId=1 requestId=1f6b09c8-b91b-4269-a1b8-30b79d2b6892 targetDestroyed=false
2026-02-25T08:13:17.849Z error [electron-message-handler] error boundary componentStack="\n    at xoe (app://-/assets/index-DYrX9Gof.js:2908:181)\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 yr (app://-/assets/index-DYrX9Gof.js:260:50320)\n    at div (<anonymous>)\n    at TCn (app://-/assets/index-DYrX9Gof.js:2911:21001)\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

Additionally, when I click/select that project folder in the app (or in the folder picker), the UI noticeably lags/freezes for a while. This happens even though my system still has plenty of available RAM and CPU headroom at the time.

Additionally, this issue only reproduces when I actually enter/open the problematic folder (i.e., navigate into it). Simply having the folder present isn’t enough—the crash happens only after I go into that folder.

[monrg]

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.

[wibaek]

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.

[tylerkahn]

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.

[larscarl]

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

[smoe]

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.

[liuyejinghong]

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.

[Joshua19858]

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

[Nek]

Plus subscription. Same issue.

[bhargavaankur]

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.

[Nek]

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.