Desktop heartbeat automations advance next_run_at but never execute

Additional local diagnostics:

As of 2026-04-15 12:42:09 CST, the automation is still in this state locally:

• automations.status = ACTIVE
• automations.created_at = 2026-04-15 11:58:46 CST
• automations.last_run_at = NULL
• automations.next_run_at = 2026-04-15 12:42:09 CST
• automation_runs count for this automation = 0
• inbox_items count = 0

So the scheduler continues advancing next_run_at, but nothing ever records as executed and nothing gets delivered to the thread or inbox.

I also confirmed the target thread still exists locally, and I had already tried restarting and reinstalling the app before filing this issue.

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

• ##16938
• ##17840
• ##16994

Powered by Codex Action

yeah

Following up with a concrete question:

For this specific case on macOS with Codex Desktop 26.409.20454 (1462), is there any known user-side workaround to restore built-in heartbeat automations?

My repro is narrower than the general sandbox/network issues:

• heartbeat automation is created successfully
• next_run_at advances every minute
• last_run_at stays NULL
• automation_runs stays empty
• inbox_items stays empty
• nothing is ever delivered to the target thread

So this looks like the scheduler is advancing time, but execution never starts at all.

If there is a known workaround inside Codex Desktop itself (specific setting, feature flag, automation type, thread requirement, version, etc.), that would be very helpful.

If not, a confirmation that this is currently a known broken path for heartbeat automations on macOS would also help.

I encountered the same issue.

Active automations on Codex App for Windows are not actually executing for me. Next run advances to the next interval as expected, but Last ran stays empty/null, no thread message is posted, and no visible run is created. This is reproducible across multiple intervals, so it is not just a missed first run.

Environment:

• Windows 10 Pro (build 19045)
• Codex App: OpenAI.Codex_26.409.7971.0_x64__2p2nqsd0c76g0
• Not using WSL or a network drive
• Thread ID: 019d91c6-12d0-7892-bc33-ded5fee60f0a

Example:
It shows Next run = 11:09, does not run, then changes to 11:14. Last ran remains null and no run/thread message is created.

Don't want to create too much extra noise but also wanted to confirm seeing the exact same issue here:

• MacOS 26
• Codex desktop Version 26.409.20454 (1462)
• Scheduled to run every three minutes
• Next run at advances but last run at remains null
• If I manually click the "Run now" button it does run and last run updates, but it then doesn't run again on schedule

After the update today (April 17), I noticed an additional prompt on Heartbeat: "Pin the chat first, then Heartbeat will be available." After pinning the chat, Heartbeat was successfully triggered.

I’m seeing what looks like the same underlying problem on macOS, but in a slightly more intermittent form.

In my case, threaded heartbeat automations do sometimes execute, but they are not reliable enough to trust. The main pattern is:

• the automation remains ACTIVE
• next_run_at continues to advance
• some heartbeat runs do post into the thread
• but other expected runs are skipped entirely
• when that happens, the next scheduled time can drift forward instead of staying aligned to the original cadence

Concrete example from my setup:

• heartbeat rule: every 3 hours
• intended anchor was around 8:00 AM GMT
• one actual run happened around 8:25:35 AM GMT
• the next expected run should therefore have been around 11:25:35 AM GMT
• that run never happened
• later, next_run_at had advanced to around 1:18 PM GMT instead

So in my case this is not a “never runs at all” issue, but it does look like the same family of bug:

• scheduling state advances
• actual execution is missing or inconsistent
• the cadence becomes unreliable over time

From my side, this looks like a desktop heartbeat scheduler / execution bug.

Adding a cross-link from the Windows automation reports because this may be part of the same scheduler/delivery family, but the details differ.

I originally found that existing-thread heartbeat automations could run in cases where standalone cron/new-thread automations created empty sessions. That led me to retarget several real automations as heartbeats with persisted target_thread_id values.

That workaround is now causing problems of its own:

• multiple ACTIVE heartbeat automations with target_thread_id
• Desktop attempts to resume/read the linked target threads
• failures like Timed out waiting for MCP response to thread/resume
• failures like cannot resume running thread with mismatched path
• repeated resume/read/unsubscribe behavior around target threads

This lines up more with #19563 for heartbeat target-thread resume thrash, while #19011 / #19969 / #20076 are the cron/new-thread empty-session failure mode.

So for anyone using the “pin the chat / heartbeat attached to existing thread” workaround: it may help with delivery in simple cases, but I would be cautious about scaling it to several automations or reusing old target threads. In my current setup I am pausing those heartbeats and not reusing the old target_thread_id values.