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(build6962) - Bundled Codex CLI/app-server at reproduction:
0.149.0-alpha.4.1 - Current installed Desktop:
26.818.61809(build7019), bundled CLI0.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?
- In Codex Desktop, use
create_threadto create a task in an existing saved local project. - Use a harmless prompt such as:
``text``
Reply with exactly CREATE_THREAD_CANARY_OK. Do not use tools or access files.
- Confirm that
create_threadreturns a valid task/thread identity. - Wait for the initial turn to finish, then read the exact task.
- Observe that it reaches
completedwithin seconds but has no assistant response, tool marker, or explicit error. - Send the same bounded follow-up to the existing fresh task.
- Observe the same empty completion.
- 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:
- dispatch the prompt to the selected model and return the assistant response; or
- 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_threadreturns a child that remainsinProgressindefinitely with zero events. Here, the affected turn reachescompletedwithin seconds. - #19969: Scheduled automations create empty sessions. This report concerns an interactive
create_threadtask whose prompt is received. - #40014: a completed answer is visible in the Desktop UI while
read_threadreturns 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.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I reviewed the automated duplicate suggestion, #40269. It is related at the pre-sampling boundary, but it is not an exact duplicate on the evidence currently available:
completedwithin seconds with no explicit error, assistant output, or observed model request.They may share a broader pre-sampling lifecycle defect. If maintainers confirm from internal traces that the same branch causes both states, I am happy for this issue to be marked duplicate. Until then, the
completed-without-dispatch terminal state remains the distinguishing behavior.