codex - 💡(How to fix) Fix Codex Desktop macOS silently dies overnight with powerd ClientDied and no crash report

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

After relaunching Codex in the morning, there were also multiple stale Codex helper processes from previous app generations still running, including older Crashpad handlers, a bare modifier monitor, and an older codex app-server process. That may be a separate cleanup issue, but it seems relevant because the overnight failure leaves Codex in a state where the user-visible app is gone while helper/background processes can remain.

Code Example

CFBundleIdentifier = com.openai.codex
CFBundleName = Codex
CFBundleShortVersionString = 26.519.41501
CFBundleVersion = 3044

---

Darwin 24.5.0 arm64 arm
macOS 15.5 (24F74)
Apple Silicon

---

2026-05-25 23:47:20 +0200 Assertions PID 93154(Codex) Summary NoIdleSleepAssertion "Electron" 07:23:08
2026-05-26 00:01:57 +0200 Assertions PID 93154(Codex) ClientDied NoIdleSleepAssertion "Electron" 07:37:46
2026-05-26 00:02:20 +0200 Assertions PID 75232(Amphetamine) Summary PreventUserIdleSystemSleep "Amphetamine (Single-Use - System)" 12:03:57

---

reboot time: Tue May 19 15:16
incident time: Tue May 26 00:01:57 +0200

---

2026-05-25 22:00 | 146
2026-05-25 23:00 | 869
2026-05-26 07:00 | 89
2026-05-26 08:00 | 380

---

Submission op: Shutdown
Shutting down Codex instance
Agent loop exited

---

DiagnosticReports: no Codex/Electron crash report in the 2026-05-25 23:30 to 2026-05-26 00:30 window.
Crashpad: no pending/completed/new dumps for this incident.
SparkleUpdateLog: no Codex/Sparkle update activity around the incident.
Preferences: SUAutomaticallyUpdate = 0, SUEnableAutomaticChecks = 1.
Unified log search around 00:00:30-00:03:30: no relevant Codex SIGSEGV, launchd, runningboard, Sparkle, AMFI, crashpad, jetsam, or memorystatus event.

---

2026-05-26 00:01:57 +0200

---

Searched openai/codex for:
- "ClientDied Electron Codex macOS"
- "Codex Desktop macOS Electron ClientDied no crashdump overnight app stops"

Only my earlier #23845 looked related, but this incident has different evidence and no SIGSEGV/Sparkle/AppKit-close signature.

---

Current app bundle date added: 2026-05-21 00:07:39 UTC
Current app content change date: 2026-05-24 06:44:39 UTC
Current app last used date after relaunch: 2026-05-26 08:11:56 UTC
RAW_BUFFERClick to expand / collapse

What version of the Codex App are you using?

26.519.41501 (CFBundleVersion 3044)

Verification after relaunch:

CFBundleIdentifier = com.openai.codex
CFBundleName = Codex
CFBundleShortVersionString = 26.519.41501
CFBundleVersion = 3044

The currently running Crashpad handler also has _version=26.519.41501.

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 24.5.0 arm64 arm
macOS 15.5 (24F74)
Apple Silicon

What issue are you seeing?

Codex Desktop on macOS silently stopped overnight while the Mac was explicitly kept awake. The visible Codex/Electron app process died, but there was no macOS crash report, no Crashpad dump, no Sparkle/update log, no reboot, and no obvious unified-log crash/termination event.

The clearest local evidence is from pmset -g log: the app had an active Electron sleep assertion for hours, then powerd reported ClientDied for the Codex process at 2026-05-26 00:01:57 +0200.

Sanitized excerpt:

2026-05-25 23:47:20 +0200 Assertions PID 93154(Codex) Summary NoIdleSleepAssertion "Electron" 07:23:08
2026-05-26 00:01:57 +0200 Assertions PID 93154(Codex) ClientDied NoIdleSleepAssertion "Electron" 07:37:46
2026-05-26 00:02:20 +0200 Assertions PID 75232(Amphetamine) Summary PreventUserIdleSystemSleep "Amphetamine (Single-Use - System)" 12:03:57

So the machine was not simply going to sleep. Amphetamine and powerd were still preventing idle system sleep immediately after Codex died.

The system was also not rebooted:

reboot time: Tue May 19 15:16
incident time: Tue May 26 00:01:57 +0200

Codex's local sqlite logs also show a practical overnight gap after the process death. In local time there are normal logs before the incident, then no useful Codex activity until the morning:

2026-05-25 22:00 | 146
2026-05-25 23:00 | 869
2026-05-26 07:00 | 89
2026-05-26 08:00 | 380

The last detailed logs before the gap came from a background Codex instance shutting down around 2026-05-26 00:36:13 +0200:

Submission op: Shutdown
Shutting down Codex instance
Agent loop exited

That was after the Desktop/Electron process had already died according to powerd, which makes this look like the GUI/main process disappeared first and some background/app-server work outlived it briefly.

I checked for the usual crash/update causes and did not find them:

DiagnosticReports: no Codex/Electron crash report in the 2026-05-25 23:30 to 2026-05-26 00:30 window.
Crashpad: no pending/completed/new dumps for this incident.
SparkleUpdateLog: no Codex/Sparkle update activity around the incident.
Preferences: SUAutomaticallyUpdate = 0, SUEnableAutomaticChecks = 1.
Unified log search around 00:00:30-00:03:30: no relevant Codex SIGSEGV, launchd, runningboard, Sparkle, AMFI, crashpad, jetsam, or memorystatus event.

This is related to, but appears distinct from, my earlier issue #23845:

  • #23845 had a clear Sparkle auto-update failure and SIGSEGV on 2026-05-21 02:07:39 +0200.
  • #23845 also had a later AppKit/window-close SIGSEGV path.
  • This incident has no visible SIGSEGV, no Sparkle replacement attempt, no AppKit close sequence, no AMFI core-dump denial, and no Crashpad dump.

After relaunching Codex in the morning, there were also multiple stale Codex helper processes from previous app generations still running, including older Crashpad handlers, a bare modifier monitor, and an older codex app-server process. That may be a separate cleanup issue, but it seems relevant because the overnight failure leaves Codex in a state where the user-visible app is gone while helper/background processes can remain.

My current hypothesis is that this is in the Codex Desktop/Electron lifecycle layer on macOS:

  • the Electron main process exits or is terminated without producing a crash report;
  • the app-server/background helper lifecycle is not tied cleanly to the Desktop app lifecycle;
  • Codex does not leave enough persistent evidence to distinguish a clean app quit, an unhandled main-process exit, an OS kill, or an Electron/native crash without a dump;
  • stale helpers after relaunch suggest parent/child cleanup or single-instance ownership may be weak.

What steps can reproduce the bug?

This is not yet a deterministic minimal repro, but the observed repro path is:

  1. Launch Codex Desktop 26.519.41501 on macOS 15.5 (24F74) / Apple Silicon.
  2. Keep the machine awake overnight with Amphetamine or another active PreventUserIdleSystemSleep assertion.
  3. Leave Codex Desktop open with long-running/background Codex work active or recently active.
  4. After several hours, the Codex Desktop/Electron main process silently disappears.
  5. pmset -g log records ClientDied for Codex's NoIdleSleepAssertion "Electron".
  6. No macOS crash report, Crashpad dump, Sparkle log, reboot, or obvious unified-log termination reason is produced.
  7. Relaunching Codex later starts a new Desktop process, but stale Codex helpers from earlier app generations may still be present.

The relevant process-level timestamp for this occurrence is:

2026-05-26 00:01:57 +0200

This is a process/lifecycle failure rather than an issue tied to a specific prompt response. I am intentionally not posting local thread/session IDs publicly; I can provide them privately if needed. Token and context counts are not applicable to the process death itself.

What is the expected behavior?

Codex Desktop should not silently exit overnight while the machine is awake.

If the Desktop app does exit, Codex should leave a clear persistent reason that distinguishes at least:

  • user-requested quit;
  • intentional auto-update restart;
  • renderer/main-process crash;
  • OS termination;
  • app-server requested shutdown;
  • lost app-server or helper process;
  • failed crash reporting.

Expected behavior for this case:

  • the Desktop app stays open while the Mac is awake;
  • long-running/background work is either kept alive or clearly marked interrupted with a recoverable reason;
  • the app-server/helper processes do not remain orphaned across app generations;
  • Crashpad or another local diagnostic path captures a dump or exit reason;
  • on next launch, Codex surfaces that the previous Desktop process ended unexpectedly and offers enough diagnostic detail to report it.

Additional information

Duplicate/related issue search:

Searched openai/codex for:
- "ClientDied Electron Codex macOS"
- "Codex Desktop macOS Electron ClientDied no crashdump overnight app stops"

Only my earlier #23845 looked related, but this incident has different evidence and no SIGSEGV/Sparkle/AppKit-close signature.

Additional local observations:

Current app bundle date added: 2026-05-21 00:07:39 UTC
Current app content change date: 2026-05-24 06:44:39 UTC
Current app last used date after relaunch: 2026-05-26 08:11:56 UTC

Potentially useful instrumentation/fix areas:

  • log Desktop main-process startup/shutdown reason to a durable local file;
  • record app-server connection loss and Desktop parent PID loss explicitly;
  • add a watchdog or recovery path when the Desktop process disappears but app-server/helper processes continue;
  • reap stale Crashpad/native helper/app-server processes across app relaunches;
  • ensure Crashpad captures or at least records non-SIGSEGV native process exits;
  • surface previous-session abnormal termination in the UI on next launch.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Codex Desktop macOS silently dies overnight with powerd ClientDied and no crash report