Codex Desktop hangs when enabling paused heartbeat automation on Windows

What version of the Codex App are you using?

Codex Desktop package/build observed in local logs and Windows Error Reporting:

• Package: OpenAI.Codex_26.429.8261.0_x64__2p2nqsd0c76g0
• WER application version: 2429.0.0.0
• Codex desktop app version in logs: 0.128.0-alpha.1
• CLI/app server version in recent local thread state: 0.128.0-alpha.1

Platform

Windows 11 / Windows NT 10.0.26200.2.0.0.256.48 x64.

Issue

Codex Desktop hung while enabling a paused heartbeat automation through the automation update path. The update did not persist to the automation TOML file, and there is no evidence that the heartbeat actually started. Windows Error Reporting recorded a real application hang (MoAppHang) for Codex.exe.

This seems distinct from the existing heartbeat execution issues because the failure occurs while changing the automation state from PAUSED to ACTIVE, before the file is updated and before the automation run starts.

Related but not the same as:

• #17893 - heartbeat automations advance but do not execute
• #20517 - Windows path-prefix mismatch when resuming heartbeat target threads
• #19563 - resume/unsubscribe thrash with multiple heartbeat target threads
• #19685 - broader Windows Store app hang

Steps to reproduce

1. On Windows Codex Desktop, have a pinned thread with a heartbeat automation attached to it.
2. Keep the heartbeat automation paused in ~/.codex/automations/<id>/automation.toml.
3. From an agent/tool call, view the automation first. This returned successfully and rendered the automation card.
4. Call the automation update path to preserve the existing fields but change only status from PAUSED to ACTIVE.
5. Codex Desktop becomes unresponsive and Windows closes/restarts the app.

The mutating update attempted to keep the existing kind/name/prompt/rrule/target thread and set:

status = "ACTIVE"

Expected behavior

Codex Desktop should either:

• update the heartbeat automation to ACTIVE and return normally, or
• fail the update with a clear error without hanging the desktop app.

A failed update should not freeze the entire Codex Desktop process.

Actual behavior

• The app froze and had to be restarted.
• Windows logged a MoAppHang for Codex Desktop.
• The automation file remained unchanged and still had status = "PAUSED" after restart.
• The file LastWriteTime was earlier than the crash time, so the mutating update did not persist.
• I did not find evidence that the heartbeat scheduler/run actually started.

Evidence

Windows Event Log / WER:

TimeCreated: 2026-05-07 15:18:22
ProviderName: Application Hang
Id: 1002
Message: The program Codex.exe version 2429.0.0.0 stopped interacting with Windows and was closed.

WER report excerpt:

EventType=MoAppHang
TargetAppId=U:OpenAI.Codex_26.429.8261.0_x64__2p2nqsd0c76g0!App
TargetAppVer=26.429.8261.0_x64_!2026//04//06:20:19:48!0!Codex.exe
Sig[2].Name=Application Version
Sig[2].Value=2429.0.0.0
Sig[4].Name=Hang Signature
Sig[4].Value=76a1
Sig[5].Name=Hang Type
Sig[5].Value=134217728
UI[3]=Codex is not responding

Automation file state after restart:

slack-workday-pulse           PAUSED  LastWrite=2026-05-07 13:40:23
method-my-pr-babysitter       PAUSED  LastWrite=2026-05-07 13:40:38
method-team-pr-review-watcher PAUSED  LastWrite=2026-05-07 13:58:27

Desktop log timeline around the attempt:

2026-05-07T19:16:54.685Z Sending server response ... "Rendered automation card in the app."

That was the successful view call. There was no corresponding successful response for the mutating update before the Windows MoAppHang at 2026-05-07T19:18:22Z.

Additional context

The affected automation was a heartbeat attached to an existing pinned thread, scheduled every 5 minutes during work hours. Its prompt is long enough to be a realistic production heartbeat prompt, but not unusually large for an automation. The crash reproduced while enabling it, not while executing its Slack/Method work.

A prior separate issue on the same machine also hit the Windows path-prefix heartbeat resume mismatch described in #20517, but this report is specifically about the desktop hang during the enable/update operation.