codex - 💡(How to fix) Fix Desktop automations on Windows create thread but never submit automation prompt [1 comments, 2 participants]

What version of the Codex App are you using?

Codex Desktop on Windows. The automation-created rollout metadata shows:

cli_version: 0.128.0-alpha.1
originator: Codex Desktop
source: vscode

Platform

Windows 10 Home Single Language
WindowsVersion: 2009
Workspace shell: PowerShell
Workspace timezone: Asia/Calcutta

Issue summary

Codex Desktop automations on Windows create and name a thread at the scheduled time, but the automation prompt is never submitted as a model turn. The resulting thread has no user event, no first user message, no model, and tokens_used = 0.

This is different from a prompt/script failure. The task never reaches model execution.

Reproduction

1. Create a cron automation in Codex Desktop against a local workspace.
2. Schedule it a few minutes in the future.
3. Use a trivial prompt, for example: fetch the current AQI for Delhi and reply with source/category/timestamp.
4. Wait for the scheduled time.
5. Observe that Codex creates a thread titled with the automation name, but there is no model response and no task execution.

I reproduced this with both a real automation and a trivial AQI test, which rules out Gmail/Make/Telegram/script/network dependencies from my original task.

Expected behavior

At the scheduled time, the automation should:

• create or reuse the scheduled automation thread/run;
• submit the configured automation prompt as a user/model turn;
• execute the prompt normally;
• show output or a concrete failure from the prompt/runtime.

Actual behavior

The scheduled automation creates and names a thread, but no prompt is submitted.

For a trivial automation named Delhi AQI Trigger Test, scheduled for 2026-05-06 15:30 Asia/Kolkata, the session file was created here:

C:\Users\<user>\.codex\sessions\2026\05\06\rollout-2026-05-06T15-30-09-019dfcbb-0851-70e0-a4a0-31d74a0b0ba4.jsonl

It contained only:

{"type":"session_meta", ... "cli_version":"0.128.0-alpha.1", "originator":"Codex Desktop", "source":"vscode"}
{"type":"event_msg","payload":{"type":"thread_name_updated","thread_id":"019dfcbb-0851-70e0-a4a0-31d74a0b0ba4","thread_name":"Delhi AQI Trigger Test"}}

There was no task_started, no user message, and no model output.

The local thread state for this automation-created thread showed:

title: Delhi AQI Trigger Test
has_user_event: 0
tokens_used: 0
first_user_message: ""
model: null
reasoning_effort: null
sandbox_policy: {"type":"read-only"}

The logs around the scheduled time showed only thread creation/name-setting activity:

thread/start
WARN Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell
Submission ... op: SetThreadName { name: "Delhi AQI Trigger Test" }

There was no corresponding user_input_with_turn_context event. By contrast, manually sending a message in a normal thread does produce op.dispatch.user_input_with_turn_context, session_task.turn, websocket response activity, and token usage.

Additional reproductions

A separate daily automation named Daily Gmail Expense Importer reproduced the same pattern at 2026-05-06 15:16 Asia/Kolkata:

thread created: rollout-2026-05-06T15-16-38-019dfcae-aa84-7723-aa0e-ea1a772fc74f.jsonl
has_user_event: 0
tokens_used: 0
first_user_message: ""
model: null
reasoning_effort: null

Earlier tests at 2026-05-06 01:00 and 2026-05-06 02:05 also created/named threads without submitting the automation prompt. One of those later appeared to run only after I manually typed into the thread, which caused it to behave like a normal manual prompt rather than a scheduled automation run.

Why this appears app-level

• A trivial AQI prompt fails the same way as a real expense-import automation.
• The run never reaches model execution: tokens_used = 0.
• The configured prompt is not present in the rollout/session file.
• The logs show SetThreadName, but no user_input_with_turn_context.
• Manual prompts in the same Codex install work.

This suggests the scheduler is successfully creating/naming a thread, but the automation prompt handoff into the turn dispatcher is not happening.

Related issues

This looks related to, but more specific than:

• #16938
• #16994

Those issues report automations not starting/materializing correctly on Windows. This report includes the observed intermediate state where the thread is created, but the configured prompt is never submitted.