codex - 💡(How to fix) Fix Desktop thrashes resume/unsubscribe when >4 heartbeat automations have target_thread_id [5 comments, 3 participants]

What version of the Codex App are you using?

Codex Desktop 26.422.30944 (CFBundleVersion 2080)

Bundled CLI observed during the investigation: codex-cli 0.125.0-alpha.3

What platform is your computer?

macOS 26.0.1 (25A362), Apple Silicon / arm64

What issue are you seeing?

Codex Desktop can enter a persistent local CPU/Energy loop when more than four heartbeat automations have a linked target_thread_id.

The Desktop repeatedly cycles completed heartbeat target threads through:

thread/read -> thread/resume -> maybe_resume_success -> thread/unsubscribe

The suspicious detail is that the turns are already completed, but the resume path still marks the conversation streaming:

maybe_resume_success ... latestTurnStatus=completed markedStreaming=true

The cleaner finding is that this does not require giant histories, pinned threads, stale Chronicle state, memory backfill, or actual automation execution. It reproduces with fresh tiny target threads when the fifth linked heartbeat automation is enabled.

In the original real-world case, large histories made the impact much worse:

Codex main CPU: up to ~190-224%
Renderer CPU: up to ~63-108%
App server CPU: up to ~36-69%
phys_footprint during loop: ~4.9 GB
phys_footprint_peak: 9.2 GB

What steps can reproduce the bug?

A clean repro from the same machine:

1. Create five heartbeat automations.
2. Give each one a target_thread_id pointing to a target thread.
3. The target threads can be fresh and tiny; each only had one trivial turn like user say ok, assistant ok.
4. Enable the fifth linked heartbeat automation.
5. Leave Desktop idle and watch ~/Library/Logs/com.openai.codex/... plus Activity Monitor / process CPU.

When the fifth linked heartbeat was enabled, Desktop entered the resume/unsubscribe loop across all five fresh target threads.

Approximate one-minute log counts from the clean repro:

thread/read: 1,424
thread/resume: 1,423
thread/unsubscribe: 1,423
maybe_resume_success: 1,423

The loop was evenly distributed across the five heartbeat target threads. Each showed latestTurnStatus=completed markedStreaming=true and turnCount=1.

A negative-control case did not reproduce:

Five active cron automations with no linked target thread:
- no CPU/Energy explosion
- no sustained resume/unsubscribe loop

So the narrowed trigger looks like:

more than 4 heartbeat automations with target_thread_id

It does not appear to be:

pinned threads
large thread histories
stale plugins
malformed old automation state
actual automation execution
no-thread cron automations
runaway model calls

automation_runs remained 0 during the loop, and token-count events appeared only for actual thread/heartbeat turns, not for each resume/unsubscribe cycle. This looks like a local Desktop subscription/resume loop rather than runaway token usage.

Additional real-world mitigation evidence

In the original affected Desktop state, the loop involved five heartbeat automation target threads:

4 PAUSED heartbeat automations with target_thread_id
1 ACTIVE heartbeat automation with target_thread_id

That means paused automation target links were still enough to keep completed target threads in the UI/subscription/resume set.

I commented out only the target_thread_id lines for the four PAUSED heartbeat automations, leaving the automation files present and still paused. The active heartbeat was left unchanged.

Immediately after detaching those paused target threads:

Codex main CPU: ~224% -> ~0.9%
app-server CPU: ~25% -> ~0.1%
renderer CPU: ~28% -> ~0.0%
codex_chronicle: ~2.5%

A fresh 8-second log window after the detach had no new entries for:

thread/resume
maybe_resume_success
inactive_thread_unsubscribed

This suggests the trigger is the Desktop handling of linked heartbeat target threads, not the heartbeat jobs actually firing.

Code-path clue from the packaged app

From the local packaged app (/Applications/Codex.app/Contents/Resources/app.asar), the behavior lines up with a subscription state-machine loop:

• The inactive owner stream cap is 4 (maxInactiveOwnerThreads).
• The resume success path calls the equivalent of markConversationStreaming(...) and setConversationStreamRole(... { role: "owner" }) even when the latest turn is already completed.
• The inactive cleanup path then unsubscribes completed inactive owner threads and sets them back to a needs_resume state.

That appears to create this cycle once there are five linked heartbeat targets:

resume completed target -> mark streaming/owner -> exceed inactive owner cap -> unsubscribe -> needs_resume -> resume again

What is the expected behavior?

• Completed heartbeat target threads should not be repeatedly resumed and marked streaming while Desktop is idle.
• Paused heartbeat automations should not keep their target threads in a hot resume/subscription loop.
• If Desktop needs target-thread metadata for the automations UI, it should use a cheap metadata path rather than repeatedly hydrating/resuming completed conversations.
• More than four linked heartbeat automations should not cause sustained multi-core CPU usage or multi-GB memory footprint spikes.

Additional information

This is separate from #19516. That issue is about an orphaned codex_chronicle process surviving a killed Desktop app and holding the Chronicle lock. The bug reported here reproduces without an orphaned Chronicle process, with Chronicle and memory disabled, and with fresh tiny heartbeat target threads.

Related issues:

• #19516: separate orphaned Chronicle lock-wait loop after killing Desktop.
• #10952: includes a similar maybe_resume_success ... latestTurnStatus=completed markedStreaming=true symptom, but appears framed around one desynced thread after request_user_input in Default mode.
• #16271: crash/resume loop around interrupted threads and missing rollout files on Windows.

Possible fix directions:

• Do not call markConversationStreaming in the resume path when the latest turn status is already completed.
• Add a guard/backoff around repeated thread/resume for completed idle target threads.
• Keep paused heartbeat target threads out of the hot subscription/resume set.
• Treat inactive unsubscribe state transitions carefully so resumeState=needs_resume does not immediately re-trigger hydration for non-active completed target threads.
• Add a cheap metadata path for automation target-thread lists that does not require full conversation snapshots.