Codex app crashes on macOS shortly after launch
Resolved 💬 13 comments Opened Feb 7, 2026 by jorgengk Closed Feb 12, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor)
responded on this thread — see the highlighted reply below.
What version of the Codex App are you using (From “About Codex” dialog)?
Versjon 260206.1448 (565)
What subscription do you have?
Pro
What issue are you seeing?
The Codex desktop app consistently crashes on macOS approximately 30-60 seconds after launch. The crash occurs regardless of whether the app is idle or actively used.
Reinstalling the application and restarting the machine did not resolve the issue. No crash dialog. The issue occoured after the latest update
What steps can reproduce the bug?
Install Codex desktop app on macOS
Launch the application
Wait ~30 seconds
App crashes (with or without user interaction)
What is the expected behavior?
Expected Behavior
The app should remain stable after launch.
Additional information
_No response_
13 Comments
Could you provide more details about what you see when it crashes? Do you receive any dialog box? Any stack crawl?
I wonder if there's some corrupt state in your
~/.codexdirectory that's causing this. You could try deleting (or temporarily renaming) that directory to see if it resolves the problem.I am having the same issue, CLI seems fine, but app enters a crash loop.
I tried to clear ~/.codex, it happens the same
I think it might have something to do with the size of the repo. When I remove the largest repo from the app, everything works fine. When I add that repo, the memory usage skyrocket and then the app crashes. Is the app trying to load things to the memory that's causing the issue?
https://github.com/user-attachments/assets/d8e230e8-da6e-416c-bff4-5e957283da03
this is a recording of what the crash loop looks like on my machine
Hey, I got some logs too, looks like it's indeed OOM kill
When the crash occurs, the entire app process exits abruptly after ~30 seconds.
There is no dialog box, no warning, and nothing visible in the UI beforehand.
From a user perspective it looks like a silent process termination.
So far I have observed:
No crash dialog from macOS
No visible stack trace or error message
App functions normally until it suddenly closes
I have already tried:
Reinstalling the app
Restarting the machine
I will try deleting or temporarily renaming the ~/.codex directory next and report back whether that changes the behavior.
Update: regression after update — crash triggered by adding large workspace
This appears to be a regression after a Codex Desktop update.
The same workspace worked fine previously, but after updating the Codex Desktop app, adding this workspace now consistently causes the app to exit silently after ~30–60 seconds.
Symptom
Codex Desktop launches normally.
After adding a specific workspace, the app closes abruptly after ~30–60 seconds.
No macOS crash dialog, no visible error message.
The app can be idle or active — the shutdown is time-based.
Codex CLI / terminal usage works fine.
Reproduction
Launch Codex Desktop.
Add the workspace.
Wait ~30–60 seconds.
Codex Desktop exits silently.
Removing the workspace prevents the crash.
What changed
This workspace worked correctly before the update.
The crash and heavy lag only started after updating Codex Desktop.
Findings from log + filesystem inspection (sanitized)
A Crashpad minidump is created at crash time, e.g.:
<HOME>/Library/Application Support/Codex/Crashpad/completed/<UUID>.dmp
No corresponding entry in:
<HOME>/Library/Logs/DiagnosticReports/
Codex app logs end abruptly without a clear fatal error:
<HOME>/Library/Logs/com.openai.codex/<DATE>/*.log
The workspace contains a very large data directory (~16 GB) with many large files (including large .ifc files).
After the update, Codex Desktop appears to scan/index/watch the workspace more aggressively.
Moving the large data directory completely outside the workspace root makes Codex Desktop stable again.
Even when stable, the app is significantly more laggy than before the update.
Confirmed workaround
Moving the large data directory out of the workspace → crash stops.
Re-adding it → crash returns.
This strongly suggests a workspace scanning / indexing / memory regression in the desktop app.
Secondary signals (may be unrelated)
Repeated ENOENT errors from stale workspace paths.
spawn gh ENOENT (GitHub CLI not installed) in breadcrumbs.
Questions
Is there a supported way to exclude directories from desktop indexing (ignore file or config)?
Is the desktop app expected to handle very large non-code data directories inside a workspace?
<img width="505" height="819" alt="Image" src="https://github.com/user-attachments/assets/ffd269ea-a4e8-48a1-a3e3-350e56572533" />
So, i've made a suboptimal workaround that in the end provoked the crash again. I removed the ProgramData folder (large file 18GB) out of the workspace folder, then startet the codex app, it was running, then moved the ProgramData back into the folder, it worked "fine" if you dont mind the lag, but then i pushed the diff-panel button, and the app crashed again.
same issue here
same issue here
same here, I remove the large workspace, then added it again and it stopped crashing
We think this issue has been fixed in the latest release. There might be additional problems that have similar symptoms. I'm going to close and lock this issue. If you are seeing similar behaviors with the latest release, please open a new issue and provide details.