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

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

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.
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.
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.

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

Cloud task visibility and read/send behavior differ across desktop, web, iOS, and dot #50136
DOT: UNKNOWN task creation, stale disconnect notifications, ambiguous task reads, and Luna schema failures #50127

Powered by Codex Action

Adding another reproduction from October 3, 2026. All times below are UTC.

06:28–10:21: repeated cloud_threads.create calls returned AppServerBackendRequestError, error_code UNKNOWN, with no thread ID. The saved cloud environment appeared normally in list_environments. Requested settings were gpt-6.1-sol, xhigh, service_tier=default.
Task listings before subsequent retries showed no newly created task. list_environments, list_threads and read generally worked, apart from one list timeout around 08:10.
07:44: send_message to an existing cloud session also returned UNKNOWN.
Around 10:40: manually launching a chat in the same named cloud environment worked. Its UI showed 6.1 Sol / Low, so this wasn’t an identical model-settings comparison. It returned a conversational response; repository/shell execution wasn’t tested.
10:41: the manually created thread could be listed and read through the dot tools, but a harmless send_message to that exact thread returned CloudThreadNotFoundError / NOT_FOUND.

We also received repeated environmentDisconnected notifications for older tasks whose latest turns were already completed, similar to #50127. We haven’t established whether that’s related.

This workflow worked the previous day. First observed failure was 06:28; the actual regression time is unknown. No environment configuration changes were made during these checks. The status page reported fully operational at 07:46 and 08:48.

Representative failed-create request IDs:

06:28: wfr_01a100727979757aad8301749d4b66e5
10:21: wfr_01a10136042f7ef6964e27a3b4c31cb3

Could you investigate why a cloud thread is readable but not messageable, and how to determine whether a failed create call admitted a task when it returns no ID? We can’t confirm the root cause from these errors.

Additional cloud-only reproduction on 2026-10-03 at approximately 18:11 UTC: from the same Dot context, cloud_threads.read successfully read an existing Codex Cloud task and returned an inProgress status, while cloud_threads.send_message using the identical task ID returned CloudThreadNotFoundError / NOT_FOUND / cloud_thread_not_found. No successful send admission or recipient acknowledgment was obtained.

This adds a still-running readable cloud-task case to the completed/manual-task examples above. It is separate from the unsupported placement format version 2 error observed when addressing a native Windows task in #50171; no shared cause is established. This update reproduces the cloud follow-up messaging failure only, not the create failure.

Please clarify the supported continuation boundary or return a specific actionable reason when a readable cloud task cannot be messaged. Private task identifiers are omitted.

-DOTS

Additional reproduction on October 3, 2026, comparing how cloud tasks were created:

An existing user-created Codex Cloud chat can be read through cloud_threads.read. Sending to that same chat through cloud_threads.send_message returned CloudThreadNotFoundError / NOT_FOUND.
A task created by dot in a saved cloud environment supports creation and follow-up messaging through the dot tools.
A harmless follow-up sent through the web UI to the user-created Cloud chat received the expected response. This proves the UI route works in that test, not that the direct API is repaired. The owner reports that the UI message appears under their identity and adds manual UI steps, so it is not an equivalent dot-messaging workflow.

Could you clarify the supported direct continuation route for user-created Cloud chats, or return an actionable scope/access explanation when a readable chat cannot be messaged? This observation concerns follow-up messaging; it does not reproduce the create failure reported above. Private identifiers, projects, repositories, paths, prompts, and screenshots are omitted.

Readable-but-not-messageable behavior was reproduced with a user-created Codex Cloud chat through the Windows desktop app.

The user provided dot with a cloud chat link. Dot could read that chat, but sending to the same known target returned:

CloudThreadNotFoundError: The cloud thread was not found.

No successful two-way communication was established. The cloud chat could locate and read the dot conversation, but reported no callable cross-chat messaging tool and did not attempt a reverse-direction send. That is separate from dot's NOT_FOUND response.

This corroborates the follow-up messaging failure only; it does not establish the cause or reproduce the task-creation failure described in this issue.

Recovery update for my October 3 reproduction: #50168 (comment)

On October 4, 2026 (all times UTC):

07:08–07:10: a fresh cloud_threads.create call succeeded in the same saved cloud environment, with the same requested settings: gpt-6.1-sol, xhigh, service_tier=default. The task completed a shell command (pwd, exit 0). A subsequent cloud_threads.send_message to that newly created task was admitted and completed a second pwd command with exit 0.
07:18: a new coding task was created successfully. It subsequently investigated tickets and opened a PR, with review, tests and CI work progressing.

No local or environment setting changes were made between the failed and successful attempts.

Creation and follow-up messaging to a newly dot-created cloud task are working again in these tests. This is observed recovery in my environment; I don't have confirmation of a global fix. Messaging a user-created cloud chat has not been retested, and the separate desktop computer-use issue #49458 has not been retested by these checks.

Additional reproduction on October 5, 2026 (UTC), using a Pro account through dot on iOS and the web on macOS. Exact client builds were not captured; this was not a Codex CLI test.

An existing, manually created Codex Cloud task appears in dot's account-wide task listing. Reading its transcript and current status succeeds.
Sending a follow-up to that same task repeatedly returned CloudThreadNotFoundError / NOT_FOUND, at approximately 07:10, 15:35, and 15:54 UTC.
Pasting the follow-up directly into the task as the user works. Attaching the task for display in the dot conversation did not fix dot's messaging failure.
Separately, list_environments returned environments: [] and codingEnvironments: []. A manually created cloud session exists, but that alone does not establish that a saved coding-environment configuration should be discoverable. No shared root cause is established.

The impact is that dot can inspect the ongoing task but cannot steer it, leaving manual copying as the working route.

Please clarify whether continuation of user-created cloud tasks is supported by this interface, or is intentionally restricted to dot-created tasks. If supported, please investigate the read/send routing mismatch; if unsupported, an actionable ownership/scope error would be more useful than "not found." It would also help to clarify how the environment catalog relates to manually created cloud sessions and how users can configure a supported dot-driven cloud workflow.

There was additional setup friction: an assistant-provided cloud-environment creation link returned 404, and Codex settings were unavailable in the attempted iOS Safari flow. These observations do not establish account ineligibility or the cause of the messaging failure.

OpenAI's support bot suggested reporting this in openai/codex but did not confirm a support ticket or engineering escalation. If this UI/integration belongs with another team, please route it appropriately. This corroborates the readable-but-not-messageable behavior also described in #50136; it does not reproduce the task-creation failure in this issue or establish a backend diagnosis.

Private task/session identifiers, email, project names, code, and local paths are omitted.

I’m seeing what appears to be the same issue, with a fairly clear transition from working to failing.

Timeline

All times below are JST (UTC+9), on October 7, 2026.

~06:41 — A recovery-kit/check operation completed normally with exit code 0.
~06:45 — Sending a new instruction to an existing Game1 Codex Cloud task still worked. The task started successfully and performed a browser check.
- The browser check itself later encountered a connection error to the game URL, but the important point is that the instruction was accepted and the Codex task started normally.
~09:40 — First confirmed failure when sending a new instruction to the same existing task.
- Error: AppServerBackendRequestError
- Reading the task history still worked.
- Retrying after reading the history failed again.
~13:09 — Creating a new task from the existing saved Game1 Cloud environment also failed.
- Error: AppServerBackendRequestError
- Error/request ID: c3e6e95a-3e50-4185-b0d7-a00031c7d559

I was not continuously testing between 06:45 and 09:40, so the exact start time of the failure is unknown. The regression appears to have started sometime within that window.

What still works

The Cloud environment itself does not appear to be gone or unusable.

I can still:

list the saved Game1 environment
read existing task history and status
inspect previously completed task results
run commands in Codex Cloud through a separately working task
access the repository and code
confirm the latest Game1 version
run git status
confirm that the working tree is clean

What fails

I tested three different start/write paths:

Send a new instruction to an existing long-running Game1 task
- Reading its history succeeds.
- Sending a new instruction fails with AppServerBackendRequestError.
Create a new task from the existing saved Game1 Cloud environment
- The saved environment is listed correctly.
- The repository/ref information is available.
- Creating a very simple task (only checking things such as git status) fails before execution begins.
- Error: AppServerBackendRequestError.
Send an instruction to another existing Cloud setup task
- Reading that task’s history succeeds.
- The history shows that commands such as git status had run successfully.
- Sending a new instruction to that same task fails with CloudThreadNotFoundError.

The third case is especially interesting because the task/thread is readable, but the send operation reports that the Cloud thread cannot be found.

Expected behavior

If a saved Cloud environment or existing Cloud task is readable and valid, I would expect:

sending a new instruction to the existing task to start a new run, or
creating a new task from the saved environment to return a new task/thread ID and start normally.

Actual behavior

Read/list operations continue to work, while create/send operations fail before any repository command, build, or test is started.

This makes it look less like a repository/code problem and more like a failure somewhere in the Cloud task create/send path, task/thread association, permission check, or backend routing.

The key regression window is:

Last confirmed successful send: ~2026-10-07 06:45 JST
First confirmed failed send: ~2026-10-07 09:40 JST

I can provide the specific task IDs privately if they would help with backend log investigation.

I’m seeing a similar task-messaging issue on macOS, with a different error:
RuntimeError: The invoking thread is not attached to an active Aeon
ChatGPT App Version: 26.930.61225

The assistant can read the existing task conversations, and my Mac is shown as connected, attached and authorized. But sending follow-up instructions to those same tasks fails consistently. If I open a task and send the instruction myself, it works and starts a new turn.
Restarting the app didn’t resolve it. I first observed this around 15:09 UTC on October 7, 2026, and it still occurred after restarting around 15:49 UTC.
Could you investigate whether the parent conversation’s task association is getting lost? I can provide task identifiers and diagnostics privately.

For the exact The invoking thread is not attached to an active Aeon error reported in this comment: clicking my dot's name in the upper-left corner, then Reboot, restored computer discovery, new task creation, and Chrome access on Windows 26.1002.52244 today (October 7).

At that check, local commands still failed with helper_unknown_error: setup refresh had errors. This workaround is confirmed in my session; I haven't verified a fix for the original CloudThreadNotFoundError. Full results.

Update, October 7, after 18:48 UTC: following my reported Windows x64 rollback, an existing dot-created task successfully ran Get-Location, a directory listing, and git --version; the setup-refresh error was absent. The installed app version was not independently read. Full verification, limitations, and the official-hosted rollback package. This Windows-only community workaround does not establish recovery of other symptoms in this thread. Back up local data before a rollback; the newer update may be offered again.

Additional reproduction from another user on 2026-10-09 (China Standard Time), confirming the Dot → Codex Cloud creation/read asymmetry.

Dot native tool observations

cloud_threads.list_environments: success; previously published environment returned.
cloud_threads.create with the returned environmentConfigId and a read-only diagnostic prompt: failed.
Error code: UNKNOWN
Error: AppServerBackendRequestError: Something went wrong.
Request ID: 960d7762-db7e-48c5-af1e-4b6117d07521
No thread ID or task URL returned. Subsequent list did not confirm creation.
cloud_threads.list_threads: success; a manually created web task was visible.
cloud_threads.read: success; content and command results of that web task were accessible, without error.
cloud_threads.send_message: not tested in this reproduction.

Independent Codex Web control

User created and executed a read-only task in Codex Web successfully.
Workspace contained the mounted Git repository and intended project directory; Git branch was main. Commands succeeded when run from the actual repository directory.
No project files, credentials, permissions, or environment settings were changed during testing.

Impact: Dot can discover and read Codex Cloud tasks, but cannot create a new cloud task through its native tool, preventing automated orchestration. This appears consistent with this issue and #52374, although root cause is unknown.

Please investigate the backend trace for the request ID above and provide a non-destructive remediation. Repository name, environment identifier, and private thread ID are intentionally omitted.

Additional reproduction on October 9, 2026 (UTC), using ChatGPT web on Windows with a saved Codex Cloud environment.

Saved-environment discovery and reading cloud tasks succeed.
Creating a minimal read-only task through cloud_threads.create returns AppServerBackendRequestError: Something went wrong, error_code UNKNOWN. This also occurs when explicitly selecting gpt-6.1-sol. No usable task/turn ID is returned; subsequent listings do not confirm a new task. Invisible partial creation cannot be ruled out.
As a control, a separate task created manually through the Cloud UI successfully executes working-directory and Git-branch checks.
Sending a harmless progress request to an existing, readable coding task returns CloudThreadNotFoundError / NOT_FOUND / cloud_thread_not_found. The exact same task ID was successfully read immediately before the send. This was reproduced again at approximately 13:45 UTC.

Separately, a ten-minute review schedule in the assistant conversation successfully ran a repository check. The coding conversation reported different scheduling capabilities and did not create its requested repair schedule. This is a separate observation, not evidence of a shared root cause.

This leaves reading and manual execution available while assistant-mediated creation and continuation fail, requiring repeated manual relaying. Please clarify the supported continuation scope for user-created cloud tasks and provide a non-destructive recovery procedure, including how to verify whether a failed request admitted any work.

No root cause is established. Private project, account, thread and environment details, credentials, prompts and diagnostic request IDs are omitted from this public comment.

Adding a related reproduction on October 10, 2026 (UTC) from ChatGPT web on Windows. The exact web/client build was not captured. This is the Dot → saved Codex Cloud environment path, not a local desktop executor.

Observed with two distinct published saved cloud environments, around 01:43 UTC and 02:55–02:57 UTC:

Saved-environment discovery succeeds and returns the published configuration metadata.
cloud_threads.create targeting the saved configuration fails with -32603: Internal error.
A subsequent list_threads shows a newly created empty thread. Reading it returns latestTurn: null and items: []. No code execution was established for these failed attempts.
Attaching the persisted task for display succeeds.
Attempting to continue that same readable thread through send_message returns CloudThreadNotFoundError / NOT_FOUND. Attaching it did not restore messaging.

This adds a partial-creation/state-consistency case to the reports above: the failed create is followed by a listed/readable thread, but without an admitted turn, and continuation says it cannot be found. The error signature differs from the original UNKNOWN; a shared backend cause is not established.

At approximately 03:14 UTC, I manually created a new task through the UI. Dot could then read a nonempty user prompt and an inProgress turn for that manually created task. This verifies UI task admission and readback only: repository mounting, command execution and completion had not yet been independently verified when this comment was prepared. It is not a controlled same-model/settings comparison.

Please investigate creation/admission reconciliation and the list/read/attach versus send routing or ownership boundary. It would help to return a clear task/turn admission result and an actionable recovery path that avoids duplicate work, rather than leaving an empty readable task that cannot be continued. No HTTP status or diagnostic request ID was available in the captured error, so none is inferred here.

Private task/environment identifiers, repository names, prompts, account details, credentials and raw logs are omitted. Prepared with AI assistance at my request.

Adding a related partial-creation case from October 10, 2026, 13:46–13:51 UTC, using a connected Windows desktop executor.

The closest match is the -32603 / empty persisted thread behavior in this comment. Our route used environmentId plus an existing projectId; that comment used a saved Cloud environmentConfigId. Continuation also behaved differently in our test, so a shared root cause is not established.

Observed sequence:

At 13:46 UTC, cloud_threads.list_environments showed the Windows desktop connected, attached and authorized.
A control task created with environmentId and no projectId succeeded and executed a read-only Windows command.
The parent’s cloud_threads.list_projects(environmentId) succeeded and returned the existing project.
At 13:50 UTC, cloud_threads.create targeting that desktop and existing projectId returned MCP -32603: Internal error.
An immediate list_threads found a newly persisted thread. Reading it returned latestTurn: null and items: []. We did not repeat the create call.
Attaching that same persisted thread succeeded. A subsequent send_message to the same thread admitted a turn, which completed at 13:51 UTC with a real read-only command, exit code 0.

The command’s working directory was C:\Users\<user>\Documents\Codex\2026-10-10\task-2, rather than the selected project’s root, D:\<workspace>\<project> (paths redacted). The sidebar/project association was not independently verified, so the working-directory result alone does not establish where the task appeared in the UI.

Separately, the local task’s native codex_app/list_projects returned MCP -32000: Codex app tool request failed, even though the parent-side project listing and local command execution worked. This resembles the native-tool symptoms in #52063 and #50551; its relationship to the create failure is unknown.

Environment: Windows NT 10.0.26200.0. The desktop app version was not captured. No project files or settings, proxy/security configuration, or restart were involved in this test.

This confirms a failed create response followed by a readable empty thread and successful continuation in this local-project case. It does not reproduce the saved-Cloud NOT_FOUND continuation failure. Could you clarify whether this local-project route should be tracked separately, how callers should reconcile partial creation without creating duplicate tasks, and which sanitized diagnostics would help?

October 11, 2026 — controlled cloud-task-origin comparison (same Dot, same `send_message` tool)

Adding a bounded reproduction that separates a working Dot-created-task write path from failing user-created-task writes. The same Dot/client context performed these checks; no Cloud environments were rebuilt.

Positive control — a task created by the Dot

cloud_threads.create targeted an existing saved Cloud environment configuration. It returned admissionOutcome: started, isError: false, and a usable task/turn identity.
Its first turn executed pwd successfully: /workspace, exit 0 (execution chunk 4ee3db).
After reading that same task, cloud_threads.send_message({threadId, prompt}) returned admissionOutcome: started, isError: false, and a new turn ID.
The second turn demonstrably executed git status --short (chunk b6f687), exit 128 with fatal: not a git repository (or any of the parent directories): .git. This was a deliberate harmless shell-execution check: /workspace was not a Git checkout, so the command's nonzero exit confirms execution rather than messaging failure. The read API returned execution reports/receipts, not raw shell events.

Negative controls — two separately existing, user-created Cloud orchestration tasks

Each task was visible and readable with an active inProgress turn.
Using cloud_threads.send_message against those exact readable task IDs returned CloudThreadNotFoundError, error_code: NOT_FOUND. Neither produced an accepted steer receipt or new turn ID.
Post-attempt reads confirmed the same original turns remained inProgress. The user could steer those tasks directly in Codex.
No replacement swarms/tasks, configuration changes, or production edits were made.

Observed distinction: The Dot can create and send a follow-up to its own Cloud task, but cannot send to these two user-created Cloud tasks, despite being able to read them. This suggests a task-origin, authorization/scope, or routing distinction, not a proven root cause. It narrows the broader create/write failure described above: create and same-task follow-up do work in this particular control.

Important limit: The successful send_message started a new turn after the first turn completed. We have not established that steering an actively executing turn works, nor that all Dot-created/user-created tasks behave this way.

Request to maintainers: Is direct Dot cloud_threads.send_message to an existing user-created Codex Cloud task intended to work? If so, please investigate why read and write resolve the same ID differently. If task provenance/scope restrictions apply, please expose an actionable permission_denied / unsupported-target signal instead of NOT_FOUND. A supported non-destructive way to attach/authorize a Dot to existing Cloud tasks would help. Exact private task/turn IDs and complete sanitized receipts can be provided through a private support channel for correlation.

Related: #52374. Posted with AI assistance at the user's request.

Following up on our earlier report. In our October 11 check, dot could read an active user-created Codex Cloud task, but one direct cloud_threads.send_message attempt returned CloudThreadNotFoundError / NOT_FOUND. The send was not admitted, and a subsequent read showed no new response.

Successful continuation of dot-created tasks is a separate observation; we have not verified recovery for user-created tasks or established the cause.

Could you clarify whether direct messaging from dot to existing user-created Codex Cloud tasks is supported, and whether there is a supported continuation route or scope requirement we should use? Thanks!

Adding a fresh reproduction of the readable-but-not-messageable Cloud task behavior on October 13, 2026. This adds an exact timestamp and client version for the follow-up messaging failure only.

App version: 26.1007.30912 (user-reported).
Target: an existing Codex Cloud task created through the native app's Cloud picker, using General, on October 12.
Caller: the main dot conversation using its built-in cloud_threads tools.

Observed sequence:

cloud_threads.read successfully read the target immediately before the send. Its latest turn was completed, with error: null.
The account-wide cloud_threads.list_threads result (children_only: false) included the same exact threadId.
At 2026-10-13 19:11:55 UTC (12:11:55 PDT), one authorized cloud_threads.send_message attempt to that exact threadId returned:
- CloudThreadNotFoundError: The cloud thread was not found.
- error_code: NOT_FOUND
- error_data.type: cloud_thread_not_found
No request ID was returned with this failure. The exposed send schema offered threadId, prompt, model and thinking, with no alternate link-ID or host-selector field.

Expected: dot should be able to continue an authorized, eligible Cloud task that it can list and read, or receive an actionable explanation of the supported scope and continuation route. This currently blocks direct follow-up and requires manual relaying.

This reproduction does not test the create failure in the original issue or establish a backend cause. Separately observed browser attachment/focus failures and a native-route approval-context denial are not evidence of the cause of this Cloud send error. A native host label alone also does not establish the task's execution location.

Private in-app feedback was submitted earlier at 12:03 PDT, before this timestamped reproduction; it should not be treated as a trace captured for the 12:11:55 attempt. Private task and feedback identifiers can be provided to OpenAI Support. They, account details, project links, conversation contents and raw logs are omitted here.

Could you clarify whether direct dot messaging to existing user-created Cloud tasks is supported, and provide a non-destructive recovery route or a more specific scope/error signal?

Posted with AI assistance at the affected user's request.

Follow-up to my October 13 reproduction: a bounded, user-authorized Cloud-only comparison produced a working control. All times below are UTC on October 13, 2026.

Existing UI-created Cloud task: list/read succeeded, but direct dot send returned CloudThreadNotFoundError / NOT_FOUND at 19:11:55.
New dot-created Cloud test using the same published General configuration: creation and the initial turn succeeded at approximately 19:21.
Three direct follow-ups to the new task were admitted and completed with acknowledgments: a simple acknowledgment at approximately 19:22, read-only access checks for an existing Page and document at approximately 19:23, and a delayed context-retention check after idle time at approximately 19:35.
At 19:35:39, list_environments explicitly reported the laptop offline. No local computer or browser was used for this comparison.
Read metadata for both the old and new tasks showed parentThreadId: null, so that field alone does not explain the different outcomes.

The existing task was left unchanged. This verifies creation and repeated continuation for this one dot-created Cloud task; it does not establish repair of the existing task, universal reliability, or a backend root cause. The difference may help task-origin/scope/routing triage, consistent with the earlier controlled comparison in this issue. Please clarify the supported scope for continuing existing UI-created Cloud tasks.

Private task/configuration identifiers, document details and contents are omitted.

Navigation Menu

Repository navigation

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

Summary

Actual behavior

1. New cloud task creation returns UNKNOWN

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

Control evidence

Expected behavior

Impact

Related reports

Privacy

October 11, 2026 — controlled cloud-task-origin comparison (same Dot, same `send_message` tool)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Actual behavior

1. New cloud task creation returns UNKNOWN

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

Control evidence

Expected behavior

Impact

Related reports

Privacy

Activity

github-actions commented on Oct 2, 2026

jgilfoil commented on Oct 3, 2026

grtninja commented on Oct 3, 2026

NaturalMatchaKing commented on Oct 3, 2026

dean1012 commented on Oct 4, 2026

jgilfoil commented on Oct 4, 2026

xrl commented on Oct 5, 2026

ImashiruGames commented on Oct 7, 2026

deaddeadbeef commented on Oct 7, 2026

ve6btc commented on Oct 7, 2026

token-kill commented on Oct 9, 2026

wspotu01 commented on Oct 9, 2026

iamtornado commented on Oct 10, 2026

rhuang19 commented on Oct 10, 2026

joshyorko commented on Oct 11, 2026

October 11, 2026 — controlled cloud-task-origin comparison (same Dot, same send_message tool)

NaturalMatchaKing commented on Oct 11, 2026

familycoyne commented on Oct 13, 2026

familycoyne commented on Oct 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

October 11, 2026 — controlled cloud-task-origin comparison (same Dot, same `send_message` tool)