Codex Desktop macOS spins at 100% on launch from one ACTIVE heartbeat automation RRULE

[Mohammad-Orabi]

What version of the Codex App are you using?

Codex Desktop 26.623.31921, build 4452

Bundled app-server / CLI: codex-cli 0.142.2

What platform is your computer?

macOS 26.5.1 (25F80), Apple Silicon / arm64

What issue are you seeing?

Codex Desktop became unusable on launch: after force quit and relaunch, the main desktop process pegged one CPU core at about 99-100% and the UI never reached a usable state.

This reproduced after reboot as well. It was not an OpenAI service outage and did not require an app update to trigger.

I isolated the root cause to one active heartbeat automation file under:

~/.codex/automations/<redacted-automation-id>/automation.toml

Moving only that automation directory aside made Codex Desktop launch again with the same account, state DB, logs, plugins, and desktop global state intact.

Culprit automation shape

The automation prompt, id, and target thread are intentionally redacted, but the relevant non-private scheduling shape was:

version = 1
kind = "heartbeat"
status = "ACTIVE"
rrule = "FREQ=HOURLY;INTERVAL=3;BYDAY=MO,TU,WE,TH,FR;BYHOUR=9,12,15,18;UNTIL=20260626T150000Z"

The issue was observed on 2026-06-26, so the UNTIL value was on the same day as the launch failure.

Isolation / evidence

I bisected local state using temporary CODEX_HOME profiles and reversible file moves:

1. Clean HOME launched normally.
2. Real HOME with clean CODEX_HOME launched normally.
3. Real ~/.codex reproduced the launch spin.
4. Moving auth.json aside did not fix it.
5. Moving .codex-global-state.json variants aside did not fix it.
6. Moving the local state DB (state_5.sqlite*) aside changed behavior but did not identify the root cause; copying the real state DB into a temp profile launched normally.
7. Moving the large log DB (logs_2.sqlite*) did not fix it.
8. Moving the legacy ~/.codex/sqlite folder did not fix it.
9. A minimal temp profile with real config.toml, state_5.sqlite*, auth.json, and .codex-global-state.json launched normally.
10. Adding the full automations directory to that temp profile reproduced the 100% CPU launch spin.
11. Testing automations one by one isolated the issue to a single active heartbeat automation TOML.
12. A plain recreated copy of that TOML in a temp profile still reproduced the spin, so this was not caused by extended attributes or directory metadata.
13. Setting that same automation to inactive made startup normal.
14. Using a simpler RRULE like FREQ=HOURLY;INTERVAL=3 made startup normal.
15. Moving the culprit automation directory aside from the real profile fixed Desktop launch.

Observed startup signature:

• main Codex desktop process: about 99-100% CPU
• app-server process mostly started/connected successfully
• logs stopped around the app-server connection becoming connected
• after removing the culprit automation, the main window reached ready-to-show and app routes mounted normally

Expected behavior

One malformed, expired, edge-case, or otherwise problematic heartbeat automation should not be able to spin the Electron main process at 100% during app launch.

Codex Desktop should either:

• ignore/quarantine the problematic automation and continue launching,
• mark it inactive with an actionable error,
• or evaluate the RRULE asynchronously with timeout/backoff so the desktop UI remains responsive.

Actual behavior

The entire desktop app became unusable on every launch until the specific automation directory was moved out of ~/.codex/automations.

Workaround

Move the offending automation directory aside:

mv ~/.codex/automations/<redacted-automation-id> ~/.codex/automations/<redacted-automation-id>.disabled

After that, Codex Desktop launches normally. Other active automations continued to exist and did not reproduce the issue.

Related issues

This looks related to other automation / heartbeat startup-spin reports, but the isolated root cause here is different:

• Similar macOS startup 100% CPU symptom, but isolated to global-state heartbeat permissions: Codex App: stale heartbeat-thread-permissions-by-id in global-state spins the main process at ~100% CPU on launch (UI frozen, persists across restarts) #27298
• Heartbeat automation hang while enabling paused automation on Windows: Codex Desktop hangs when enabling paused heartbeat automation on Windows #21578
• RRULE edit corrupting persistent automation state on Windows: Desktop: editing automation RRULE crashes mid-write, leaves persistent corrupt state surviving uninstall + reinstall #24597

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Codex Desktop on macOS 26.5.1 launches with 100% CPU but creates 0 windows #28684

Powered by Codex Action

[javenfang]

I hit a very similar issue on a newer build, and this case may add useful
coverage because it does not require an UNTIL RRULE edge case.

Version / platform

• Codex Desktop: 26.623.61825, build 4548
• Bundled CLI / app-server: codex-cli 0.142.3
• macOS: 26.5.1 build 25F80
• Architecture: Apple Silicon / arm64

Symptom

Codex Desktop became unusable after a normal user input in an existing thread.
The app entered macOS "Not Responding" state. After force quit and relaunch,
startup repeatedly reproduced a main Desktop process spin at about 99-100%
CPU while the app-server process stayed mostly idle or connected normally.

The app recovered only after moving the ACTIVE heartbeat automation directories
out of ~/.codex/automations.

Isolation result

I bisected local state with temporary CODEX_HOME profiles and reversible file
moves:

1. Clean CODEX_HOME launched normally.
2. Temp profile with real auth.json, config.toml, state DB, global state,
   plugins, skills, memories, logs, and high-risk session files launched
   normally.
3. Real ~/.codex reproduced the 100% CPU startup spin.
4. Moving all ACTIVE automation directories out of ~/.codex/automations
   fixed launch with the same account, state DB, desktop global state,
   plugins, remote state, and sessions intact.
5. Restoring only automation A reproduced the startup spin.
6. Removing automation A and restoring only automation B also reproduced the
   startup spin.
7. Moving both automation directories out again restored normal launch.

This suggests the failure is not a generic heartbeat automation feature failure,
but one or more local ACTIVE heartbeat automation records / target-thread state
can trigger a Desktop UI/main-process busy loop.

Automation shape

Both culprit records were version = 1, kind = "heartbeat",
status = "ACTIVE", and used the same ordinary workday RRULE shape:

rrule = "FREQ=HOURLY;INTERVAL=2;BYDAY=MO,TU,WE,TH,FR;BYHOUR=1,3,5,7,9"

Neither automation TOML had explicit model or reasoning fields.
Each had a different target_thread_id.

One target thread was an automation-specific thread titled
Automation: <redacted>.

The other target thread was an older, large, normal project conversation
repurposed as a heartbeat target. Its local session transcript is about 36.7 MB.

Log clue before the original hang

The first hang happened immediately after a normal turn/start and automation
card render. The app log then showed two failed automation_update validations:

Rendered automation card in the app.
automation_update received invalid arguments: reasoningEffort: Invalid option: expected one of "none"|"minimal"|"low"|"medium"|"high"|"xhigh"|"max".
automation_update received invalid arguments: model: Invalid input: expected string, received undefined.

That may indicate a UI/update path handling old or incomplete automation model /
reasoning metadata incorrectly. This is an inference from local logs, not a
confirmed root cause.

Process / sample evidence

Observed signature during the bad state:

• Main Codex Desktop process: about 99-100% CPU.
• codex app-server: mostly idle / not the hot process.
• Main-thread samples show Chromium / Node / V8 frames, including uv_run and
  repeated v8::Promise::Resolver::Reject frames.
• macOS generated a cpu_resource.diag.

Local evidence paths on the affected machine:

/Library/Logs/DiagnosticReports/Codex_2026-06-29-155948_jMacPro2025-3.cpu_resource.diag
/tmp/codex-gui-16988-20260629-160033.sample.txt
/tmp/codex-gui-32482-20260629-181116.sample.txt
/tmp/codex-gui-52224-20260629-182126.sample.txt
~/Library/Logs/com.openai.codex/2026/06/29/codex-desktop-273ab3a9-3ee3-402b-a9d1-1beeb4efc502-16988-t0-i1-074244-0.log

I am not attaching raw session transcripts or raw automation prompts because
they may contain private project information.

Workaround

Move the offending ACTIVE heartbeat automation directories out of
~/.codex/automations:

mkdir -p ~/.codex-quarantine/heartbeat-automation-hang
mv ~/.codex/automations/<automation-id> ~/.codex-quarantine/heartbeat-automation-hang/

After that, Codex Desktop launched normally and remained responsive with the
same global state, state DB, plugins, remote connection state, and sessions.

Expected behavior

A malformed, stale, old-schema, or otherwise problematic ACTIVE heartbeat
automation should not be able to spin the Electron main process and make the
entire Desktop app unusable.

The app should quarantine or mark the problematic automation inactive, surface
a recoverable error, or evaluate the startup automation state asynchronously
with timeout/backoff.

[membphis]

I had the same issue

[shaanmajid]

I am still seeing this exactly as described on app version 26.623.141536.

In this case the culprit was also exactly one ACTIVE heartbeat automation, but the RRULE did not include UNTIL:

rrule = "FREQ=HOURLY;INTERVAL=2;BYDAY=MO,TU,WE,TH,FR;BYHOUR=16,18,20,22;BYMINUTE=0"