Desktop automations on Windows/WSL create automation runs but no rollout materializes, then resume fails with 'no rollout found'

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

• #15854
• #16872
• #16938

Powered by Codex Action

Follow-up after local reset:

I renamed ~/.codex/sqlite/codex-dev.db and relaunched Codex Desktop.

Results:

• existing chats were still visible after relaunch;
• normal session rollouts were created again under ~/.codex/sessions/...;
• but automations are still broken in the same way.

A new automation run is inserted into automation_runs, but no matching rollout/session file is created on disk, and the app again fails with:

Failed to resume task
no rollout found for thread id ...

As a temporary mitigation, I paused the affected automations locally to stop the retry loop.

So the DB reset was safe for chat history on my machine, but it did not resolve the automation-specific failure.

I get the same issue. Thead id: 019d7612-4131-7833-8988-cb4eac71a821

Draft prepared with Codex assistance; details verified by me.

I have another Windows desktop automation repro that looks like the same bug family, but with a more specific failure signature.

Environment:

• Codex Windows desktop app
• Version shown in the About Codex screen: 26.409.61251
• Store package path shows OpenAI.Codex_26.409.7971.0_x64__2p2nqsd0c76g0
• Rollout/session metadata on this machine shows cli_version: 0.119.0-alpha.28
• Windows host
• Reproduced with both a WSL-hosted repo path and a Windows-native repo path

Observed behaviour:

• A scheduled automation creates a thread/run record
• The created thread is empty
• The rollout file contains only session_meta and no turns
• The app then resumes the thread as turnCount=0
• The local automation_runs row remains IN_PROGRESS even though the desktop log says the scheduled run failed

The key desktop log error is:

Scheduled run failed automationId=hello-world errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"

I reproduced this twice with a simple automation using:

• prompt = "hello world"
• execution_environment = "local"

I then repeated the test against a separate Windows-side clone at:

C:\Users\<redacted>\projects\codex-windows-test

and pointed a fresh automation at:

C:/Users/<redacted>/projects/codex-windows-test

That still failed with the same AbsolutePathBuf deserialized without a base path error.

Concrete artefacts from this repro:

• the WSL-path runs failed at 2026-04-15T18:22:09Z and 2026-04-15T18:28:44Z
• the Windows-path run failed at 2026-04-15T18:47:31Z
• in all three cases, the corresponding rollout/session file contained exactly one line: a session_meta record and no user/assistant turns

The strongest clue is that the failed Windows-path run wrote a malformed cwd into the rollout/session file:

/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.409.7971.0_x64__2p2nqsd0c76g0/app/resources/C:/Users/<redacted>/projects/codex-windows-test

So in this repro the failure is not only “no rollout found” later on. The scheduled-run path appears to be constructing or deserialising an invalid absolute path during task creation, which leaves behind:

• an empty rollout/session file
• an empty thread
• an automation_runs row still marked IN_PROGRESS

Related issues that seem relevant:

• #16815 for the exact AbsolutePathBuf deserialized without a base path error
• #16525 for malformed concatenated cwd values on Windows desktop

I’m seeing what looks like the same automation lifecycle bug on Windows Codex Desktop, but with a simpler local repro.

Environment

• Codex Desktop app version: 26.17.415
• Session cli_version: 0.122.0-alpha.13
• Platform: Windows
• Project path: C:\CodexAutomationSmoke
• Originator from transcript: Codex Desktop
• Source from transcript: vscode
• In-app feedback id: 019db1fe-6e3c-7923-a7da-81ce1eb79ce1
• Smoke-test session id: 019db1fb-10ac-77c2-8bd3-06158e1714f5

Repro

1. Created a local folder:

```text
C:\CodexAutomationSmoke

I’m seeing a very similar failure on Windows with Codex Desktop automations in worktree mode, with one extra detail: the run is auto-archived almost immediately and never gets a real thread/session.

Environment:

• Codex Desktop: 26.415.4716.0
• Codex runtime/CLI recorded locally: 0.122.0-alpha.1
• Platform: Windows
• Automation kind: cron
• Execution environment: worktree
• Target cwd: local Windows path, not WSL

Observed local state for a new automation created today:

automation id: standup-summary
run created: 2026-04-22 11:32:08 Europe/Oslo
run updated: 2026-04-22 11:32:08 Europe/Oslo
status: ARCHIVED
thread_id: pending:58bc8c58-548f-4e51-b971-42ba6c7b096e
archived_reason: auto
archived_user_message: null
archived_assistant_message: null
inbox_title: null
inbox_summary: null

Additional verification:

• automation_runs contains the row above.
• inbox_items has no row for the run.
• The main threads table has no corresponding real thread.
• No matching rollout/session file appears under .codex/sessions/YYYY/MM/DD/.
• The run flips from creation to ARCHIVED in roughly 325 ms.
• The UI shows the previous run as archived, but there is no accessible result/output.

This looks like the same lifecycle gap described here, but in this case the user-visible symptom is “automation ran and immediately placed the output directly into archive,” while locally there appears to be no output/thread to recover.

I have a related Windows Desktop repro in #19011 that looks like the same automation lifecycle family, with one additional distinction.

In my case the rollout/session file does get created, but it is only a skeleton:

• session_meta
• thread_name_updated
• no submitted user_input
• no task_started
• no turn_context
• no response_item
• no tool calls

So #16994 and #19011 may be adjacent failure points in the same startup pipeline:

1. automation run/thread record is created
2. rollout/session artifact may be missing entirely (#16994), or may exist as a metadata-only skeleton (#19011)
3. Desktop then tries to resume/read a run that has no real agent turn to resume

One workaround I previously tried was converting affected cron automations into existing-thread heartbeat automations. That avoided the new-thread first-turn failure in some cases, but it introduced a second failure mode once several automations had persisted target_thread_id links: Desktop can time out on thread/resume or fail with a mismatched-path resume error. That seems related to #19563 and #20317.

So the workaround I would not recommend broadly anymore is “convert everything to heartbeat with target_thread_id.” It can trade the missing-rollout / empty-turn issue for stale target-thread resume problems.

the typical failure mode here is that automation_runs and rollout/session files are written by separate code paths. interactive sessions write the rollout when the thread opens. automation runs create the run row upfront but the rollout only materializes after the runner connects and emits its first event. WSL workspace setups are where this fails silently, since path translation between windows desktop and the WSL-side runner happens at that exact connection step. runner-side logs around when the run id was assigned vs the rollout open call usually surface the gap.

My repro is similar to #16994, but I’m seeing an even earlier failure mode on Windows + WSL: in my case the automation often never dispatches a turn at all. For cron tests I observed named thread shells with only session_meta; for heartbeat tests the target thread received no second automation-owned submission beyond my manual probe turn. So this may be the same lifecycle bug family, but failing before automation_runs -> rollout materialization -> resume.

I am seeing a closely related automation lifecycle failure on Windows Codex Desktop.

In my case, clicking Run now creates automation runs and creates associated session JSONL files, but the sessions are only skeletons and no actual turn is submitted.

Observed:

• two automation runs were created after clicking Run now
• the runs were left IN_PROGRESS
• corresponding session JSONL files existed
• the session files contained no user prompt
• no turn_context
• no assistant response
• zero token usage
• local inspection showed active_turn_present=false

This differs slightly from the “no rollout materializes” case because a rollout/session file does appear, but it never becomes a real executable task.

I also tried simplifying the automation prompt and model, but the same behavior occurred. This appears to fail before the agent receives the prompt, so it does not look prompt-specific.

Expected:

• Run now should create a valid executable turn containing the automation prompt; or
• fail visibly with an actionable error instead of leaving a skeleton session / stuck run.

Environment:

• Windows Codex Desktop
• local workspace automation
• paths, thread IDs, and workspace names redacted for privacy

Draft prepared with Codex assistance; findings verified locally by me.

I have a Windows-native Codex Desktop repro that appears to be the same automation lifecycle bug family as this issue, but with a tighter isolation result: on this machine, the failure is specific to the managed worktree automation handoff, not to the repo itself, not to plain Git worktree creation, and not to starting a thread from a worktree path in general.

Environment

• Codex Desktop package: OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0
• Runtime/app version observed in local logs: app.version=0.133.0-alpha.1
• Platform: Windows 10 Pro, build 26200, x64
• Automation kind: cron
• Original execution environment: worktree
• Target workspace: local Windows repo path (not WSL)

Original symptom

All affected automations remain ACTIVE and continue to schedule, but their runs do not become real threads.

Local DB pattern in ~/.codex/sqlite/codex-dev.db:

• thread_id = pending:<uuid>
• status = ARCHIVED
• archived_reason = auto
• inbox_title = NULL
• inbox_summary = NULL
• archived_user_message = NULL
• archived_assistant_message = NULL

The runs flip from created to archived within a fraction of a second.

Isolation work

I created four canary automations against the same repo:

1. worktree + plain Windows repo path
2. worktree + \\?\ Windows repo path
3. local + plain Windows repo path
4. local + a manually precreated worktree path under ~/.codex/worktrees/...

Result A: both worktree canaries failed in the same way

Both of these produced only placeholder pending thread ids and were auto-archived immediately:

• source_cwd = C:\GitHub\<repo>
• source_cwd = \\?\C:\GitHub\<repo>

Example rows:

thread_id: pending:d6062f00-ff79-466e-9380-d36e8c91d859
status: ARCHIVED
archived_reason: auto
created_at: 1779522955839
updated_at: 1779522956364

thread_id: pending:1af48380-71dd-4a83-846c-11bf49ca07bc
status: ARCHIVED
archived_reason: auto
created_at: 1779523015858
updated_at: 1779523016381

This rules out the \\?\ path prefix as the primary cause.

Result B: local automation against the same repo path succeeded

A canary with:

• execution_environment = local
• cwd = C:\GitHub\<repo>

created a real automation thread and advanced the run to PENDING_REVIEW.

Example row:

thread_id: 019e53da-763e-7bc1-9a70-7e460654aa35
status: PENDING_REVIEW
inbox_title: Canary thread confirmed
inbox_summary: Reached real thread on dev in <repo>

Result C: manual Git worktree creation succeeded

I manually reproduced the same Git worktree creation pattern Codex appears to use, including config overrides that disable hooks/fsmonitor and LFS filters. git worktree add --detach ... dev succeeded both:

• under a scratch path
• under a Codex-style path inside ~/.codex/worktrees/...

So plain Git worktree creation itself is not failing.

Result D: local automation against an already-created worktree path also succeeded

A canary with:

• execution_environment = local
• cwd = <precreated worktree path under ~/.codex/worktrees/...>

also created a real automation thread and advanced to PENDING_REVIEW.

Example row:

thread_id: 019e53e1-53bf-72a1-934d-a6fbd5b2717f
status: PENDING_REVIEW
inbox_title: Canary worktree thread confirmed
inbox_summary: Live thread reached; checkout is detached HEAD

This rules out ?Codex cannot start a thread inside a worktree path? as the root cause.

Most likely failure boundary

Given the above, the remaining failure boundary seems to be:

1. automation run placeholder row is created
2. Codex enters the worktree automation path
3. something fails during or immediately after the managed-worktree creation/handoff
4. no real thread id is ever persisted
5. the placeholder run is auto-archived

In other words: the Windows failure on this machine is not scheduler-wide, not repo-specific, not a raw Git failure, and not a general inability to run in worktree directories. It is specifically the ?managed worktree -> start automation thread in it? path.

Extra local clue

The failing worktree canaries did not leave behind new managed worktree directories registered by Codex, while the manually created worktree and the successful local-against-worktree canary behaved normally. That suggests the failure may be occurring before the managed worktree is fully materialized or before the thread start can bind to it.

Practical workaround confirmed locally

On this machine, changing the automation to execution_environment = local is a viable workaround for at least read-only/reporting automations.

I did not broadly convert all real automations to local, because some of them may make code/project-management changes and would then operate directly against the main local repo instead of an isolated worktree.

If it helps, I can provide the exact canary automation definitions and the matching local DB rows, but the key result is the isolation above: local succeeds, managed worktree fails, manual Git worktree add succeeds, and local on a precreated worktree succeeds.