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

Open 💬 2 comments Opened Aug 24, 2026 by omarpinarecords
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

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

  1. Confirm that create_thread returns a valid task/thread identity.
  2. Wait for the initial turn to finish, then read the exact task.
  3. Observe that it reaches completed within seconds but has no assistant response, tool marker, or explicit error.
  4. Send the same bounded follow-up to the existing fresh task.
  5. Observe the same empty completion.
  6. 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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 days ago

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

  • #Issue #40269

Powered by Codex Action

omarpinarecords · 3 days ago

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:

  • #40269 reports a turn that remains in progress indefinitely while a second world-state build is pending.
  • This report reaches completed within seconds with no explicit error, assistant output, or observed model request.
  • The same silent completed-empty result occurred on a follow-up and across two saved local projects.
  • I do not have evidence that the #40404 turns were blocked on the duplicate world-state-build path or that the local fix described in #40269 would change this terminal transition.

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.