Codex Desktop automations create empty threads but never start a turn on Windows

Open 💬 1 comment Opened May 28, 2026 by dmiedog

Summary

Codex Desktop automations on Windows create a new thread at the scheduled/manual trigger time, but the thread never receives a user turn and never starts running. The UI remains stuck showing only the automation prompt bubble. No assistant response or tool calls appear.

Environment

  • OS: Windows 11 Pro for Workstations, version 10.0.26200, x86_64
  • Codex Desktop client: 26.519.81530
  • Codex CLI/runtime: 0.133.0
  • Workspace: C:\Users\Z\Desktop\Folder\codex_file
  • Shell: PowerShell
  • Config includes:
  • sandbox_mode = "danger-full-access"
  • [windows] sandbox = "elevated"
  • project c:\users\z\desktop\folder\codex_file marked trusted

Automations Affected

Two local Codex automations reproduce the issue:

  • automation: "站会总结"
  • automation-2: "每日晨报与项目变化"

Both have:

  • kind = "cron"
  • status = "ACTIVE"
  • execution_environment = "local"
  • cwds = ["C:\\Users\\Z\\Desktop\\Folder\\codex_file"]

Expected Behavior

When the automation triggers, Codex should create a thread, submit the automation prompt as a user input/turn, and start executing with assistant output and tool calls.

Actual Behavior

The automation creates a thread, but it never submits a user turn. The UI shows only the initial automation prompt bubble and then stays idle.

Observed examples:

  • 019e6d76-c8f9-7cd2-a233-3a7128de3135: "每日晨报与项目变化"
  • 019e6d76-fa14-7660-a7c7-9d9a93b3828e: "站会总结"
  • earlier examples: 019e6d70-2688-7eb2-b57d-41ab82a357de, 019e6d71-4176-7093-bb7d-6a3d77d4c972

The corresponding rollout JSONL files contain only session_meta. There are no user/assistant/tool events after session creation.

Evidence From Local State

In C:\Users\Z\.codex\state_5.sqlite, affected automation threads show:

has_user_event = 0
first_user_message = ''
sandbox_policy = {"type":"read-only"}
approval_mode = on-request

In C:\Users\Z\.codex\logs_2.sqlite, affected automation threads show only thread startup and no active turn:

composing running thread resume response
active_turn_present=false
active_turn_id=None
active_turn_status=None

There is no corresponding op.dispatch.user_input for the automation threads.

Sandbox Note

An earlier run produced this Windows sandbox setup error:

failed to spawn ... codex-windows-sandbox-setup.exe: requested operation requires elevation. (os error 740)

After restarting Codex as Administrator, new sandbox setup logs show success:

WFP setup succeeded for CodexSandboxOffline with 12 installed filters
setup refresh: processed 2 write roots (read roots delegated); errors=[]

However, newly triggered automation threads still have has_user_event=0 and active_turn_present=false, so the remaining failure appears to be automation prompt dispatch/thread lifecycle, not sandbox initialization.

Additional Observations

  • The warning Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell appears on automation thread startup, but manual threads continue to run normally, so this does not appear to be the primary blocker.
  • Manual Codex interactions in the same workspace work.
  • Model requests work in normal threads.
  • Automations successfully create sidebar/session entries, but do not enqueue/submit the automation prompt as a turn.

Minimal Reproduction

  1. Create a local cron automation in Codex Desktop for workspace C:\Users\Z\Desktop\Folder\codex_file.
  2. Use a simple prompt, for example: "Reply with automation test succeeded."
  3. Trigger it manually or wait for schedule.
  4. Observe a new thread is created.
  5. Observe the thread remains idle with only the prompt bubble and no assistant response/tool calls.
  6. Inspect state DB: the new thread has has_user_event=0, empty first_user_message, and no active turn.

Request

Please investigate why Codex Desktop automations create a thread but do not submit the automation prompt as a user turn on Windows. The failure appears to happen after thread/start and before op.dispatch.user_input.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗