Codex Desktop scheduled automations create empty sessions with no prompt or task turn

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

• #19011

Powered by Codex Action

I can reproduce the same issue on Windows ARM64.

Environment:

• Codex App on Windows ARM64
• Codex CLI observed locally: 0.125.0
• Codex Desktop session version observed in failed run files: 0.126.0-alpha.8
• Shell: PowerShell
• Execution environment: local
• Project path: local Windows project folder
• CLI codex exec can write files locally
• Normal Codex App threads can write files locally
• Codex App integrated terminal can write files locally

Automation configuration:

• automation.toml exists and is ACTIVE
• kind = "cron"
• execution_environment = "local"
• cwds points to the correct local project folder
• The automation prompt is a simple diagnostic write test

Observed behavior:

• Clicking Run now creates a new session/thread.
• The UI shows the run under “Previous runs” with a spinner indefinitely.
• The expected output file is not created.
• The created session .jsonl contains only metadata, including session_meta and thread_name_updated.
• There is no submitted user prompt, no model response, no tool call, no error, and no completion event.

State DB evidence from the failed run:

• tokens_used = 0
• first_user_message = ""
• model = null
• reasoning_effort = null
• sandbox_policy = {"type":"read-only"}
• cwd is correct
• source = "vscode"

This matches the issue described here: the automation run/session is created visually, but the saved automation prompt is never injected/submitted as an agent turn.

This does not appear to be a workspace permission or local filesystem issue, because the same project can be written to successfully from:

• CLI codex exec
• normal Codex App thread
• Codex App integrated terminal

Related issue: #19011

This matches the Windows empty-session signature I reported in #19011.

The common pattern across #19011, #19969, and #20076 appears to be:

• automation run/session is created
• cwd can be correct
• session contains session_meta / thread_name_updated
• no saved automation prompt is injected
• no model/reasoning state is set
• no user message, assistant message, tool call, token event, or task completion exists
• UI may continue showing the run as in progress because there is no real turn to complete or fail

I initially worked around this by converting some jobs to existing-thread heartbeat automations, but that is not a stable general workaround. Once several heartbeats have persisted target_thread_id links, Desktop can start failing earlier in the resume path with thread/resume timeouts or cannot resume running thread with mismatched path errors. That newer target-thread failure seems related to #19563 / #20317.

So my current read is that there are at least two automation lifecycle bugs:

1. cron/new-thread dispatch creates an empty or skeleton run without injecting the prompt
2. heartbeat/existing-thread dispatch can get stuck resuming stale or mismatched target threads

Both happen before the user’s automation prompt actually runs.

it's been like this for two weeks now, it is maddening

Me, too.

I can reproduce this automation-dispatch family on macOS, with a variant that gets further than the empty-session reports above: the prompt is submitted and a turn starts, but Desktop falsely completes it before any model response.

• macOS 15.7.7 (24G720), arm64; Australia/Perth
• Desktop release at failure: 26.707.62119; bundled Codex CLI 0.144.2
• standalone local cron; model gpt-5.6-sol, reasoning high
• scheduled 2026-07-14 08:00; thread created 08:01:17 +0800
• thread 019f5ded-8e30-7d82-9972-aec2d46ee9d5
• failed turn 019f5ded-9a10-7262-89c9-0dc50d955596

The rollout contains thread_settings_applied, task_started, correct turn_context, the full saved prompt as both response_item role=user and user_message, then:

2026-07-14T00:01:21.886Z token_count info=null
2026-07-14T00:01:21.896Z task_complete duration_ms=1482 last_agent_message=null

There is no assistant message, reasoning item, tool call, explicit error, or non-null token usage. The Scheduled preview still said Last run: never, and no requested output was created.

At 11:10:28 +0800, a manual follow-up in the same thread started immediately; the first assistant message arrived at 11:10:32.966 and normal token usage/file changes followed. The model, project cwd, and write scope were the same. The app had auto-updated at 10:22 from 26.707.62119 to 26.707.71524, so the manual control was on the newer build.

Sleep is ruled out: macOS power logs show no sleep/wake transition around 08:00, and the Electron process held a no-idle-sleep assertion before and after the run.

One possible clue: the failed null token event used rate-limit context limit_id=premium, no plan type, zero credits; the successful manual turn used limit_id=codex, plan_type=pro, with normal usage. This may be unattended entitlement routing, but that is only an inference.

This appears to be a scheduler/execution lifecycle bug after prompt injection and before model dispatch. Even if dispatch fails, Desktop should record an explicit error rather than task_complete with last_agent_message=null and stale Last run: never bookkeeping.