Automations don't run not scheduled and not run now

[sedghi]

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.409.20454 (1462)

What subscription do you have?

Plus

What platform is your computer?

Darwin 24.6.0 arm64 arm

What issue are you seeing?

Automations does not work.

When i hit test now, it shows automation started but nothing else
Also my daily scheduled automations don't run

What steps can reproduce the bug?

I have this as automation

look at the commits in the past 24 hours merged inside Cornerstone3D and do a review. summarize the changes, and whether there are new bugs introduced 
- Do NOT invent bugs; if evidence is weak, say so and skip.
- If you feel like something is a mistake at the end make a table and tell what is a mistake
- If breaking changes is introduced and is not actually documented in docs, flag it 

Always pull the latest main before doing your task

and the following setup. I've tried the local as well and still nothing happens

What is the expected behavior?

automations run and shows up

Additional information

No response

[github-actions]

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

• Automation marked Active but does not run or create a thread #16938
• Desktop automations on Windows/WSL create automation runs but no rollout materializes, then resume fails with 'no rollout found' #16994

Powered by Codex Action

[jkronika-octane]

Confirmed on macOS after updating the app: this is still reproducible and appears to fail before execution/thread creation.

Environment

• Codex Desktop version: 26.415.30602 (build 1773)
• macOS desktop app
• Workspace automation type: cron automation in a local project

What I reproduced

1. Click Run Now on an existing automation (for example Daily Standup Update (v2)).
2. The app shows the popup Automation started.
3. No new chat/thread is created in the project.
4. No inbox item appears.

Local evidence
In ~/.codex/sqlite/codex-dev.db the automation row is updated, but execution never starts:

• automations.last_run_at advances when I click Run Now
• automation_runs does not get a new row
• the newest automation_runs rows remain old archived runs from 2026-04-07
• no new inbox items are created

Example from my local DB after a manual run on 2026-04-17:

• automation id: daily-standup-update-v2
• last_run_at advanced to 2026-04-17 12:36:38 local
• newest automation_runs row is still daily-jira-update from 2026-04-07 08:00:02 local

Regression boundary

• Last known successful automation-created thread in this project was Automation: Daily Jira Update
• thread id: 019d6875-2a3f-7d51-be65-e3d2b32bbe25
• recorded cli_version: 0.117.0-alpha.24
• created on 2026-04-07

Additional notes

• Recreating the automations as new v2 copies did not help.
• Updating the desktop app did not help.
• Inspecting the packaged app code suggests a real run should insert a pending row into automation_runs before thread creation. On these failing manual runs, execution never appears to reach that point.

This looks broader than a scheduling-only bug: scheduled runs and manual Run Now both fail to cross the same execution boundary.

[scottbarbag-ux]

I found a related Windows Desktop failure in #19011, but the local state can distinguish a few different automation-start failure points.

In the reports linked from here, I’m seeing at least three variants:

• no automation_runs row and no new thread/inbox item, even though last_run_at or next_run_at advances
• an automation run/session is created, but the session is empty except for metadata like session_meta and thread_name_updated
• heartbeat automations tied to old target_thread_id values get stuck earlier in thread/resume, sometimes with resume timeouts or mismatched-path errors

The practical diagnostic I’d suggest is checking whether automation_runs gets a new row after Run now, and if a rollout/session file exists, whether it contains any submitted user prompt / task_started / turn_context.

Recreating the automation and updating the app did not fix the empty-session variant for me. Also, converting everything to heartbeat/target-thread automations is not a safe general workaround; it can introduce the target-thread resume problem tracked in #19563.