macOS unified ChatGPT app hangs at launch (main process 100% CPU, no window) when an automation has an unsatisfiable RRULE

Open 💬 0 comments Opened Jul 16, 2026 by HamedMP

Summary

The unified ChatGPT macOS app hangs forever at launch — main process pinned at ~100% CPU, no window ever appears, no crash report — when ~/.codex/automations/ contains a scheduled task whose RRULE can never produce a next occurrence. The scheduler appears to loop indefinitely (via setImmediate) computing the next run time instead of bailing out after an iteration/time cap.

Because the hang happens before any window or error surfaces, it looks like the app is simply "broken after the update". Reinstalling doesn't help since ~/.codex survives reinstalls.

Environment

  • ChatGPT macOS app 26.707.72221 (unified ChatGPT + Codex build, bundle ID com.openai.codex)
  • Codex Framework 150.0.7871.115, app-server 0.144.2
  • macOS 26.5.2 (25F84), Apple Silicon (arm64)

Repro

  1. Create ~/.codex/automations/repro-task/automation.toml with an RRULE that is valid per RFC 5545 but unsatisfiable, e.g.:
version = 1
id = "repro-task"
kind = "cron"
name = "Repro"
prompt = "noop"
status = "ACTIVE"
rrule = "RRULE:FREQ=HOURLY;INTERVAL=4;BYHOUR=6,10,14,18,22;BYMINUTE=0"
execution_environment = "local"
created_at = 1782916984673
updated_at = 1782919577178

With FREQ=HOURLY;INTERVAL=4, occurrences only land on hours congruent to (DTSTART hour mod 4). If the anchor hour's residue doesn't match any BYHOUR value, the rule never fires. (In my case the task was created via the product UI/CLI — I did not hand-write it — so this state is reachable through normal usage.)

  1. Launch ChatGPT.app.

Result: main process spins at ~100% CPU indefinitely (left it >10 minutes), no window, not responding to Apple Events. codex app-server itself initializes fine (handshake succeeds via stdio); the hang is in the Electron main process.

Cleanup: remove the automation dir → app launches normally in ~10s.

Evidence

sample of the main thread during the hang — 100% of samples inside a setImmediate callback (uv__run_check → node::Environment::CheckImmediate) executing JIT'd JS in a tight self-rescheduling loop:

2169 Thread  DispatchQueue_1: com.apple.main-thread
  2169 main (in ChatGPT)
    2169 ChromeMain (in Codex Framework)
      ... -[NSApplication run]
        ... __CFRunLoopDoSource0
          ... uv_run → uv__run_check
            2169 node::Environment::CheckImmediate(uv_check_s*)
              2169 node::InternalMakeCallback(...)
                2169 ??? (JIT'd JS frames, deep recursion pattern)

A second, independent trigger on my machine was a task with rrule = "FREQ=WEEKLY;BYDAY=MO;BYHOUR=9;BYMINUTE=0;BYSECOND=0" (no RRULE: prefix, includes BYSECOND) that duplicated another task's name and schedule. Fixing the prefix and de-duplicating resolved it; I can't say which of the two aspects was the trigger.

Expected

  • RRULE evaluation should have an iteration/time bound (like python-dateutil's count/until safeguards) and treat "no next occurrence found" as an error for that task, not a reason to hang the whole app.
  • A malformed/unsatisfiable automation should be skipped with a logged warning; app startup should never be blocked on scheduler math.

Workaround for affected users

Move ~/.codex/automations aside (mv ~/.codex/automations ~/automations.bak), launch the app, then fix the offending task's schedule and restore.

View original on GitHub ↗