Windows Desktop 26.707.72221: invalid heartbeat target `thread` is accepted and retried every 4–5s, causing high CPU

Root cause correction and successful recovery

Further investigation found that the original /index.html route-parsing diagnosis was incorrect. The root route was present in the retry logs, but it was not the source of the literal thread value.

The invalid value originated from a heartbeat automation created in Codex session 019f5836-8afe-7091-956e-219f62f903b1 at 2026-07-15T14:57:52.246Z. The recorded tool call was:

automation_update({
  mode: "create",
  kind: "heartbeat",
  name: "monitor-pr-1299-review",
  rrule: "FREQ=MINUTELY;INTERVAL=10",
  status: "ACTIVE",
  targetThreadId: "thread"
})

The tool accepted the request and persisted:

id = "monitor-pr-1299-review"
kind = "heartbeat"
status = "ACTIVE"
rrule = "FREQ=MINUTELY;INTERVAL=10"
target_thread_id = "thread"

The tool schema available to the agent says to use destination="thread" for the current local thread instead of inventing or copying a raw thread ID. The agent emitted the wrong field/value, but the automation API did not validate that targetThreadId was a UUID before saving it.

On subsequent Desktop launches, the heartbeat scheduler loaded this automation, reported:

Heartbeat automation skipped: thread missing
automationId=monitor-pr-1299-review
targetThreadId=thread

and then repeatedly attempted thread/read and thread/resume for the invalid ID every approximately 4–5 seconds. This drove the Electron browser-main process to roughly one logical core and caused the memory churn reported above.

This indicates two product-side safeguards are needed:

1. Reject non-UUID targetThreadId values when creating or updating heartbeat automations.
2. Do not schedule an unbounded rapid resume/read retry loop after an invalid or missing target-thread failure.

Recovery confirmation

I changed only this automation to status = "PAUSED", corrected its persisted target to the actual UUID, and fully restarted Codex Desktop.

After restart:

• the new Desktop log contained zero conversationId=thread, threadId=thread, or matching automation retry lines;
• a 12-second CPU sample showed all Codex/ChatGPT processes at effectively 0% of one logical core after startup settled;
• browser-main private memory was approximately 215 MB and working set approximately 260 MB;
• the sustained high-CPU loop did not recur.

This successful recovery strongly confirms the malformed heartbeat automation as the cause of the original performance problem.

A brief visual flicker remained only during startup while the bundled plugin marketplace reconciled from 6 plugins to 5 and back to 6, including two transient missing Browser-plugin image warnings. It settled and did not reproduce the CPU loop; that appears to be a separate startup issue.

Additional independent Windows reproduction: literal current

I independently reproduced the same product-side validation/retry failure on Codex Desktop for Windows, but with the persisted heartbeat target set to the literal value current rather than thread. This suggests the issue is not specific to one placeholder value: arbitrary non-UUID heartbeat targets can be accepted and then retried indefinitely.

Environment

• Windows x64
• Affected Microsoft Store package: OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0
• Incident date: 2026-07-13 to 2026-07-14

Persisted automation state

The active heartbeat automation contained:

kind = "heartbeat"
status = "ACTIVE"
target_thread_id = "current"

Retry-loop evidence

Across the four Desktop log files belonging to one launch (ChatGPT.exe PID 15408), a sanitized recount found:

invalid session/thread operational log lines: 30,842
heartbeat_automation_resume_failed lines:       7,705
first matching error: 2026-07-13T12:53:47.256Z
last matching error:  2026-07-13T23:54:06.511Z
duration:             11.01 hours

The repeating sequence was:

method=thread/resume ... invalid session id ... threadId=current
heartbeat_automation_resume_failed ... threadId=current
method=thread/read ... invalid thread id ... conversationId=current
Failed to read thread metadata before resume ... conversationId=current

The app continued to report the main window as responsive, but the Electron main process accumulated substantial CPU time and the user experienced repeated stalls/interruption. System RAM and disk were not exhausted during diagnosis.

Recovery confirmation

Deleting the malformed heartbeat through the supported automation manager and restarting Codex stopped new invalid-ID errors. No raw automation file was edited, and no credentials, account identifiers, thread UUIDs, or full logs are included here.

This independent reproduction supports the two safeguards already proposed in this issue:

1. Reject any non-UUID targetThreadId at automation create/update time.
2. Stop retrying thread/read and thread/resume after a permanent invalid-target validation error.

I can provide additional redacted log excerpts if maintainers need them.

Independent confirmation on 26.730.8199.0: literal current, fixed live by rebinding

This was a naturally occurring incident; I did not attempt to reproduce it.

Environment

• Windows x64
• Microsoft Store package: OpenAI.Codex 26.730.8199.0
• Bundled ChatGPT.exe: 151.0.7922.71

Creation-path evidence

The heartbeat was created through the supported automation_update tool with the caller-supplied value:

targetThreadId: "current"

The call returned success and persisted an ACTIVE automation with:

target_thread_id = "current"

The tool guidance prefers destination="thread" for the current local thread, so the caller supplied the wrong field/value. However, the create boundary accepted and persisted the non-UUID target.

Observed behavior

The same Desktop process then repeatedly emitted:

• thread/read -> invalid thread id
• thread/resume -> invalid session id
• heartbeat_automation_resume_failed
• source: thread_hydration

In the completed desktop log, thread/read and thread/resume each failed 2,607 times. The retry sequence occurred approximately every 2 seconds.

A pre-fix sample of the stable main ChatGPT.exe PID showed:

• CPU time: 7.89 seconds over 15 seconds
• working set: approximately 1.19–2.00 GB
• working-set swing: approximately 810–820 MB
• continuous UI stutter during typing and task switching

There was no corresponding process restart or git.exe / taskkill.exe child-process storm.

Recovery/control

I changed only the heartbeat target to the UUID of its existing thread through the supported automation update path. The automation remained ACTIVE and retained its name, prompt, and daily schedule. No thread/history reset and no app restart were required.

Immediately after rebinding:

• invalid read/resume errors: 0 in the post-fix log window
• main-process CPU time: 0.61 seconds over 20 seconds
• working set: 272.8–274.8 MB
• working-set swing: approximately 2 MB
• the user confirmed that the UI stutter disappeared

This isolates the trigger to malformed heartbeat target metadata rather than the scheduled workload itself, and confirms that the validation/retry failure is still present in 26.730.8199.0.

Suggested safeguards:

1. Reject or normalize non-UUID heartbeat targets at create/update time.
2. Resolve the current-thread destination to a real thread UUID before persistence.
3. Treat an invalid/missing target as a permanent failure; use bounded retry/backoff or a circuit breaker.
4. Automatically pause/quarantine the broken automation and surface an actionable warning in Scheduled instead of retrying indefinitely.

This does not imply that every Windows performance report has the same cause, but it is an independently confirmed instance of this specific failure mode.

Independent reproduction on 26.803.5235.0: literal current, sustained CPU, and pointer stutter

This is another naturally occurring Windows reproduction. I have not modified the affected automation yet, so the measurements below are pre-recovery.

Environment

• Windows 11 Home 25H2, build 26200.8973, x64
• Microsoft Store package: OpenAI.Codex 26.803.5235.0 (package status OK)
• CPU: Intel Core i7-11700F, 16 logical processors
• RAM: 32 GB
• GPU: RTX 3070, NVIDIA 610.74
• Symptom: after every Codex Desktop launch, mouse-pointer movement becomes visibly choppy

Persisted automation state

An ACTIVE heartbeat created through the supported automation path was accepted and persisted with:

kind = "heartbeat"
status = "ACTIVE"
target_thread_id = "current"

No automation prompt, account data, local paths, or thread UUIDs are included here.

Natural before/after cutover in the same Desktop process

This incident provides a clean creation-time boundary:

• before the automation was created: 0 invalid thread/session ID events and 0 heartbeat_automation_resume_failed events
• the automation tool returned success at 2026-08-07T18:08:53.243Z
• the first invalid thread id error appeared at 18:08:53.272Z, 29 ms later
• after creation in that same process: 4,100 invalid-ID events and 1,025 heartbeat-resume failures

This strongly isolates the trigger to the malformed heartbeat metadata rather than a cold-start-only condition.

Reproduction across launches

The same loop is present in the most recent 15 Desktop launches. On the current launch:

• maybe_resume_started began about 4.4 s after launch
• invalid thread/session requests began about 5–8.5 s after launch
• over a 469-second window:
• 284 heartbeat_automation_resume_failed events (~36/min)
• 1,318 error-level log entries (~169/min)
• repeated thread/read -> invalid thread id
• repeated thread/resume -> invalid session id
• source: thread_hydration

Resource and process evidence

During a quiet 15-second sample:

• main ChatGPT.exe: 9.578 CPU-s / 15 s (~63.9% of one core)
• bundled codex.exe: 1.469 CPU-s / 15 s (~9.8% of one core)
• renderer: 1.250 CPU-s / 15 s (~8.3% of one core)
• WMI provider, Defender, DWM, and the measured GPU process were idle or near zero
• DPC/interrupt, disk latency, available RAM, USB/PnP, and Windows event logs showed no synchronized system fault

A separate 15-second process-start sample observed:

• 9 heartbeat failures
• 9 BrowserUseThreadConfig browser_use_runtime_paths_selected events
• 8 short-lived node.exe processes directly parented by the main ChatGPT.exe, with matching conhost.exe children

The timestamps align one-for-one within the sample window. I am reporting this as an observed correlation; I did not capture the short-lived Node command lines.

Expected behavior

1. Reject or normalize non-UUID targetThreadId values at create/update time.
2. Resolve the current-thread destination to a real UUID before persistence.
3. Treat invalid/missing targets as permanent failures with bounded retry/backoff.
4. Do not repeat Browser runtime discovery/process startup on each permanent heartbeat failure.
5. Pause/quarantine the malformed automation and surface an actionable warning.

I can add a post-rebind CPU/error/process comparison after applying the supported recovery path.

Recovery confirmation: deleting the malformed heartbeat stops the loop immediately

I deleted only the affected heartbeat through the supported automation manager. No raw automation file was edited, and the Desktop app was not restarted.

A 20-second post-delete control window showed:

• new heartbeat_automation_resume_failed events: 0
• new invalid thread id events: 0
• new invalid session id events: 0
• new BrowserUseThreadConfig runtime-selection events: 0
• processes started directly by the main ChatGPT.exe: 0
• Desktop main log growth: 3 lines total in 20 seconds

CPU comparison:

| Process | Before deletion | After deletion |
|---|---:|---:|
| main ChatGPT.exe | 63.9% of one core | 1.0% |
| bundled codex.exe | 9.8% | 0.8% |
| hottest renderer | 8.3% | 1.2% |

The automation file and directory were also removed by the supported manager. The retry/runtime/process churn stopped live, without a restart. This completes the natural before/after control and confirms the malformed ACTIVE heartbeat target as the cause of this incident.

Hi @Pluglug, I'm testing a local-first, read-only diagnostic tool (Codex Rescue Alpha5) against local session persistence and rollout anomalies. It evaluates schema compatibility, tool correlation, and state consistency without modifying the original rollout or SQLite databases.

If the affected session is still present locally, you can run:

pip install codex-rescue==0.1.0a5
codex-rescue doctor --latest

No raw data is needed; please redact any private repository paths before sharing results.