Windows Codex Desktop creates automation thread but never starts agent turn

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

• #17893
• #17840
• #18471

Powered by Codex Action

I reviewed the duplicate suggestions from the bot.

Related, but this does not look like an exact duplicate of the suggested issues:

• #17893: macOS heartbeat automation where next_run_at advances but last_run_at stays null and no automation_runs row is created. In this Windows repro, automation_runs rows and rollout files are created, but the rollout stops at session_meta + thread_name_updated with no submitted user_input / task_started / turn_context.
• #17840: macOS report that scheduled / run-now automations do not visibly run, but without the local rollout/log signature shown here.
• #18471: Windows first-turn UI/conversation-state issue where turn/started is received for an unknown conversation and the UI shows reconnecting. This may be adjacent, but the automation repro here does not get as far as a turn/started; local logs show only SetThreadName followed by active_turn_present=false active_turn_id=None active_turn_status=None.

So I am leaving this issue open as a more specific Windows automation dispatch failure: the thread is created/named and persisted, but the automation prompt is not submitted as a runnable turn.

I found a practical workaround on Windows that may help narrow the failing code path.

What works reliably for me:

• Update the automation so it runs as a heartbeat attached to an already-existing manual thread.
• In other words, do not let it create its own standalone automation thread.

What fails for me:

• Standalone cron automation path that creates a new thread for the run.

Concrete example:

• daily-bug-scan as a standalone cron automation created a new run/thread (019dbc00-aac0-71b3-87a4-a7f9a7be3f37), but the rollout only contained session_meta + thread_name_updated.
• That failed run had no task_started, turn_context, response_item, or submitted prompt.
• Desktop log for that thread showed thread/read, thread/resume, then latestTurnId=null, latestTurnStatus=null, turnCount=0.

By contrast:

• A heartbeat automation attached to an existing thread did post successfully into that thread.
• I was also able to work around the issue by updating Daily bug scan to run in an existing thread instead of creating its own automation thread.

So the current workaround/fix on my side is:

• convert affected automations from standalone cron jobs into thread heartbeat automations attached to an existing conversation.

This does not look like a true product fix; it looks like the existing-thread resume/post path is healthier than the new-thread first-turn dispatch path on Windows.

There may also be a separate timing bug in my environment: on 2026-04-23 both a 9:00 AM cron automation and a 9:00 PM heartbeat fired around 3:21 PM CDT instead of their configured local times. But independently of that timing issue, the important difference is:

• existing-thread heartbeat path can execute
• new-thread cron path can create an empty thread with zero turns

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

Update: the workaround I posted above is now causing a second failure mode.

I previously said that moving affected automations from standalone cron jobs into existing-thread heartbeat automations was a practical Windows workaround. That was only partially true. It avoids the original new-thread first-turn dispatch failure, but it is not stable when applied broadly.

After retargeting my real automations this way, I now have several ACTIVE automations with:

• kind = "heartbeat"
• a persisted target_thread_id
• no explicit cwds, executionEnvironment, or destination in the local TOML

The new failures I am seeing are:

• Could not start automation — Timed out waiting for MCP response to thread/resume
• Failed to resume chat — cannot resume running thread with mismatched path
• repeated resume/read/unsubscribe behavior around the linked target thread

So the failure appears to have two related paths:

1. Standalone cron/new-thread path: the automation thread can be created and named, but the saved automation prompt is never submitted as a runnable turn. This is the original issue here.
2. Existing-thread heartbeat path: when the automation is tied to an old target_thread_id, Desktop can get stuck trying to resume that old thread. If the target thread is already running, stale, archived, or associated with a different path/workspace context, the automation can fail before it starts with a thread/resume timeout or a mismatched-path resume error.

That means the heartbeat retarget workaround should not be treated as a product fix. In my environment it reduced one failure mode but introduced another one tied to persisted thread identity and resume state.

The safer mitigation on my side is now:

• pause the existing heartbeat/thread automations
• do not reuse old target_thread_id values
• recreate needed jobs as standalone fresh-run automations where possible
• move repo-only maintenance jobs to GitHub/Codex Cloud instead of Windows Desktop scheduling
• keep local Windows Desktop scheduling limited, especially for jobs that depend on Outlook/SQL/browser/image workflows

Expected product behavior would be that a scheduled automation can run without needing to resume a prior chat thread, and that an invalid/running/mismatched target_thread_id fails cleanly instead of causing a resume loop or blocking the automation start.

the part that breaks down is the assumption that 'create thread' and 'start turn' are the same operation across platforms. on macOS the parent context rides through both. on Windows the elevated sandbox path takes the thread creation but the IPC handoff to start the agent turn is a separate journey, and the rollout signature in this report (session_meta + thread_name_updated, no task_started or turn_context) is exactly what the second leg failing silently looks like. a hard timeout between SetThreadName and the first turn_context event would surface this as a startup failure rather than a skeleton rollout.

I’m seeing what looks like the same failure mode on Windows Codex Desktop.

Observed behavior:

• Scheduled automations and manual “Run now” both create a run/thread record, but no actual agent turn begins.
• The UI shows the automation as running/spinning.
• After force-closing Codex from Task Manager and reopening, those runs appear archived.
• The expected project outputs are never created.

Local evidence from Codex inspection:

• The newest manual “Run now” automation session JSONL was:

rollout-2026-05-18T13-59-12-019e3a4f-8ceb-7361-b2db-e30268969c4b.jsonl

• It contained exactly 1 line: session_meta only.
• It contained no automation prompt, no submitted user message, no assistant response, no tool call, no file edit, no error, and no completion event.
• The local Codex DB showed that run id as IN_PROGRESS while the UI spinner remained active.

Run id:

• 019e3a4f-8ceb-7361-b2db-e30268969c4b

Expected project outputs were missing:

• memory/current_week_plan.md was not populated
• reports/weekly/ remained empty
• tasks/queue.md remained unchanged

Control test:

• Running the exact same Weekly Planning prompt manually in a normal Codex project chat works correctly.
• It successfully populated memory/current_week_plan.md and reports/weekly/.

This strongly suggests the automation launcher creates the run shell but fails before dispatching the saved prompt into an executable agent turn.

I also submitted in-app /feedback for this and can provide the feedback/session ID if helpful:
[019e30fd-2702-73b3-b6be-a71bf4be7f3e]

Another reproduction on a newer Windows Codex build. This looks like the same broad Windows automation dispatch failure, with one additional data point: in my repro, both standalone scheduled automation and thread heartbeat automation failed to dispatch.

Environment

• Windows Codex app package: OpenAI.Codex_26.623.13972.0_x64__2p2nqsd0c76g0
• Codex CLI: codex-cli 0.142.5
• OS from codex doctor: Windows 10.0.26200 (Windows 11 Professional) [64-bit]
• Auth: ChatGPT auth configured
• Connectivity: websocket connected successfully in codex doctor
• Sandbox during test: filesystem unrestricted, network enabled, approval_policy = never
• Project: trusted local Windows project

Repro

1. Create a standalone scheduled automation a few minutes in the future.
2. Prompt it to perform an observable action, e.g. create a marker file.
3. Create a thread heartbeat automation scheduled a few minutes in the future.
4. Prompt it to reply in the existing thread.
5. Keep Codex Desktop open and the machine awake past both scheduled times.
6. Repeat with a daily-style schedule instead of a minutely one-shot schedule.

Actual behavior

• Both automation definitions were saved and remained ACTIVE.
• The standalone automation never created the marker file.
• The thread heartbeat never woke the thread or posted a reply.
• Retrying with daily-style schedules did not change the result.

This differs slightly from earlier reports where heartbeat sometimes worked as a workaround. On this build/environment, the heartbeat path also did not fire.

Control tests

Direct CLI execution works:

codex exec "<prompt>"

A Windows Task Scheduler task that launches the bundled Codex CLI also works and successfully starts a Codex run. So this does not appear to be an auth, filesystem, model, or general CLI execution problem.

Diagnostics

codex doctor reports the background server as not running:

Background Server
  app-server   not running (ephemeral mode)
  daemon state dir         ...\app-server-daemon
  settings                 ...\app-server-daemon\settings.json (missing)
  pid file                 ...\app-server-daemon\app-server.pid (missing)
  update-loop pid file     ...\app-server-daemon\app-server-updater.pid (missing)
  status                   not running
  mode                     ephemeral

Trying to start the daemon path on Windows fails:

codex app-server daemon start
codex remote-control start --json

Both return:

Error: codex app-server daemon lifecycle is only supported on Unix platforms

Suspected failing layer

The automation definitions can be persisted, but the scheduled dispatch layer does not wake and start a real turn. Since direct codex exec works and Windows Task Scheduler launching the bundled CLI works, the failure seems specific to the Windows Desktop automation runner / dispatch layer rather than the agent runtime itself.

The app-server daemon result may or may not be the direct cause, but it is a useful clue: the local background lifecycle path that would normally make unattended wakeups robust reports as unavailable on Windows, while the UI/tooling still exposes automations as if they should run.