Codex Desktop create_thread completes before model dispatch with no assistant output or error

What version of the Codex App are you using?

• Reproduced on ChatGPT/Codex Desktop 26.818.41509 (build 6962)
• Bundled Codex CLI/app-server at reproduction: 0.149.0-alpha.4.1
• Current installed Desktop: 26.818.61809 (build 7019), bundled CLI 0.149.0-alpha.4.3
• A fresh reproduction on the current build has not yet been performed.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

macOS on Apple Silicon. Current host version: macOS 26.6.2 (25G83).

What issue are you seeing?

Codex Desktop's create_thread control can successfully register a fresh local child task and accept its prompt, but the first turn then reaches completed within seconds without an assistant message, tool marker, model output, or explicit error.

A follow-up prompt in the same fresh task behaves identically. The defect reproduced in two different saved local projects with different skill catalogs, so it is not isolated to one project's instructions or skill inventory.

Sanitized local runtime evidence for the exact failed turns shows:

• the prompt was received;
• startup transport connected successfully;
• processing reached local context and skill-selection construction;
• no actual model request followed;
• the turn nevertheless completed without an error or assistant output.

The failure boundary therefore appears to be after local context/skill preparation but before model dispatch. The exact internal branch that converts this state into a silent completion is not exposed.

What steps can reproduce the bug?

1. In Codex Desktop, use create_thread to create a task in an existing saved local project.

2. Use a harmless prompt such as:

   Reply with exactly CREATE_THREAD_CANARY_OK. Do not use tools or access files.
   

3. Confirm that create_thread returns a valid task/thread identity.

4. Wait for the initial turn to finish, then read the exact task.

5. Observe that it reaches completed within seconds but has no assistant response, tool marker, or explicit error.

6. Send the same bounded follow-up to the existing fresh task.

7. Observe the same empty completion.

8. Repeat in a second saved local project; the same terminal behavior occurs.

The canaries did not inspect or modify files and did not use connectors, permissions, credentials, schedules, or external services.

What is the expected behavior?

After create_thread accepts a prompt and returns a valid task identity, Codex should either:

1. dispatch the prompt to the selected model and return the assistant response; or
2. surface a structured startup/model-dispatch error that explains why execution did not begin.

A task should not report completed when no model request occurred and no assistant output or error exists.

Impact

This creates a false-success state for local task orchestration:

• a parent task can believe the child completed even though no model work ran;
• follow-ups can be silently consumed in the same way;
• automated workflows cannot distinguish successful completion from pre-dispatch failure;
• users may retry or duplicate work because the product exposes neither output nor an actionable error.

The current safe workaround is to keep using already-active tasks and require an exact assistant-message readback before accepting a newly created task as commissioned.

Related but distinct issues

• #33231: create_thread returns a child that remains inProgress indefinitely with zero events. Here, the affected turn reaches completed within seconds.
• #19969: Scheduled automations create empty sessions. This report concerns an interactive create_thread task whose prompt is received.
• #40014: a completed answer is visible in the Desktop UI while read_thread returns empty. Here, no model request or assistant answer is observed at all.
• #38502: a Pro-mode chat turn completes without an assistant response. This report is specific to fresh local task creation and reproduces across separate saved projects.

These reports may share a broader lifecycle or projection family, but none currently establishes this exact pre-model-dispatch completion failure.

Additional information

The report intentionally excludes project names, private thread/task IDs, local paths, raw logs, screenshots, mailbox data, and private project content. Sanitized exact turn identifiers or bounded log excerpts can be supplied privately to OpenAI if maintainers need them.

Start at the create_thread entry point and trace the lifecycle through local context and skill-selection construction to model dispatch, then compare its state handling with read_thread and the related turn-completion path. Reproduce with the provided canary prompt and verify that a successful turn contains assistant output or that a pre-dispatch failure becomes a structured error rather than an empty completed turn.