Dot cloud_threads: create returns UNKNOWN and send_message returns CloudThreadNotFoundError for readable Codex Cloud task #50168

Summary

Dot can list/read Codex Cloud tasks, but the exposed cloud_threads write path fails for both task creation and follow-up messaging.

This is a cloud-to-cloud Dot → Codex Cloud interoperability failure, not a local Desktop-thread case.

Observed on October 1, 2026.

Actual behavior

1. New cloud task creation returns UNKNOWN

Multiple bounded attempts to create a Codex Cloud task in an existing, known-working cloud environment returned an app-server/backend failure with error_code: UNKNOWN and no usable thread/turn identity.

Observed request IDs:

• 1ad351e2-2ea8-4d8e-8752-2a32f5d1032d
• 9956d813-5db8-4878-ace3-312d0aff2922
• ad785b9a-5dc6-475c-b2f1-3aace5608948
• 131ae4b2-7427-40fd-8785-9e6ad568b946

Because no usable thread/turn identity was returned, the caller cannot reliably determine whether admission occurred.

2. Follow-up messaging to a verified healthy cloud thread returns NOT_FOUND

A Codex Cloud task was created manually in the same working environment and completed normally.

Dot could locate/read that healthy cloud task, but a single cloud_threads.send_message attempt to the exact known thread returned:

CloudThreadNotFoundError
NOT_FOUND
cloud_thread_not_found

Request ID:

b41550e7-8a01-4771-9b46-9926861a7eca

The target thread itself was valid and readable. No retry was performed after the failure.

Control evidence

• Manual Codex Cloud execution in the same environment succeeded.
• The manual health-check task returned the expected result.
• Dot can list/read cloud tasks.
• The failure is specifically on the Dot-side write path: cloud_threads.create and cloud_threads.send_message.
• No local Desktop project/thread is required to reproduce this affected workflow.

Expected behavior

1. cloud_threads.create should either:

   • create the cloud task and return a usable thread/turn identity; or
   • return a specific actionable failure that makes admission state unambiguous.

2. cloud_threads.send_message should be able to message a valid Codex Cloud thread that the same Dot context can already locate/read, assuming the user has authorized the operation.

3. If a routing/placement/backend boundary prevents the write, the error should identify that boundary instead of reporting the existing readable cloud thread as not found.

Impact

This blocks the natural orchestration flow:

Dot
→ Codex Cloud task
→ result
→ Dot follow-up / steering
→ Codex Cloud task

The user is forced back to manual message copying even though the task is in the same OpenAI account and the cloud thread is readable.

Related reports

These appear related but do not exactly describe this cloud-to-cloud write failure:

• DOT: UNKNOWN task creation, stale disconnect notifications, ambiguous task reads, and Luna schema failures #50127 — Dot task creation can return UNKNOWN with no usable identity.
• Dot cannot create or follow up with local Codex tasks in saved projects #49729 — Dot cannot follow up with certain project-scoped/local Codex tasks.
• Desktop / Dot: native thread communication is asymmetric between local and cloud-backed conversations #49788 — asymmetric native communication between local and cloud-backed conversations.
• Windows: dot lacks native tools to read or message an existing local Codex conversation #49862 — Dot lacks native tools for an existing local Codex conversation on Windows.

This report is narrower: Dot can read a valid Codex Cloud task, but cannot write to it, while new Codex Cloud task creation through the same cloud_threads interface also returns UNKNOWN.

Privacy

Private thread IDs, repository names, environment IDs/config IDs, local paths, credentials, tokens, prompts, and conversation contents are intentionally omitted.

The request IDs above are included only to help OpenAI trace the failed backend operations.