What version of the Codex App are you using (From "About Codex" dialog)?
26.901.51231, Windows Desktop.
What subscription do you have?
Not applicable — observed via Desktop task APIs (create/list/wait/read thread).
What platform is your computer?
Windows 11 + WSL2 (Ubuntu 24.04). Agent environment: Windows-native.
What issue are you seeing?
Task registration loss: create_thread returns a client ID (client-new-thread:<id>), but the task never resolves — two subsequent authoritative list_threads checks found no task with the requested title and no usable server thread ID. No duplicate was created through the same path, so this is silent loss, not a race.
This is distinct from #16815 (creation fails with an AbsolutePathBuf error): here creation succeeds and registration is missing. No AbsolutePathBuf error text was observed anywhere in this flow.
What steps can reproduce the bug?
- In Codex Desktop on Windows, dispatch a task via
create_thread.
- Record the returned
client-new-thread:<id>.
- Run authoritative
list_threads checks (we ran two).
- Observe: no task with the requested title, no usable thread ID, and no duplicate.
What is the expected behavior?
The created task is visible to lookup (by title and by client ID), or creation fails loudly. Lookup should be idempotent: re-checking must never be the step that loses the task.
Additional information
Client ID available on request (truncated): client-new-thread:7c7c3a0d-…. Observed 2026-09-06 alongside empty-payload completions (see #28751), but as a separately reproduced failure — registration loss, not message loss.
What version of the Codex App are you using (From "About Codex" dialog)?
26.901.51231, Windows Desktop.What subscription do you have?
Not applicable — observed via Desktop task APIs (create/list/wait/read thread).
What platform is your computer?
Windows 11 + WSL2 (Ubuntu 24.04). Agent environment: Windows-native.
What issue are you seeing?
Task registration loss:
create_threadreturns a client ID (client-new-thread:<id>), but the task never resolves — two subsequent authoritativelist_threadschecks found no task with the requested title and no usable server thread ID. No duplicate was created through the same path, so this is silent loss, not a race.This is distinct from #16815 (creation fails with an
AbsolutePathBuferror): here creation succeeds and registration is missing. NoAbsolutePathBuferror text was observed anywhere in this flow.What steps can reproduce the bug?
create_thread.client-new-thread:<id>.list_threadschecks (we ran two).What is the expected behavior?
The created task is visible to lookup (by title and by client ID), or creation fails loudly. Lookup should be idempotent: re-checking must never be the step that loses the task.
Additional information
Client ID available on request (truncated):
client-new-thread:7c7c3a0d-…. Observed 2026-09-06 alongside empty-payload completions (see #28751), but as a separately reproduced failure — registration loss, not message loss.