Cloud task label obscures local Mac execution host and browser/plugin availability

What version of the Codex App are you using (From “About Codex” dialog)?

Installed macOS desktop bundle: ChatGPT 26.930.51102, build 13100, read from its Info.plist. The About-dialog display version was not independently inspected.

What subscription do you have?

Not collected for this report.

What platform is your computer?

macOS 26.5.2 reported by sw_vers. uname -mprs returned:

Darwin 25.5.0 arm64 arm

The user explicitly requested execution on a connected personal MacBook Pro. The exact hardware model could not be independently verified because the sandbox denied the hardware-model query.

What issue are you seeing?

A delegated task requested for a particular local Mac appears as a Cloud thread, while its tools actually execute against a Mac workspace and an existing local Chrome session. The UI/agent experience does not make the distinction between conversation backing and effective execution host clear.

The assistant initially told me that the thread was ready on my personal MacBook Pro. Later, I noticed that the UI identified it as Cloud and questioned whether the requested computer had actually been selected. The available evidence established Mac execution, but did not independently establish the exact requested device.

Observed evidence from the affected task:

Native thread metadata reports hostId: "durable".
The shell runs Darwin and reports a working directory under /Users/<redacted>/Documents/Codex/<date>/<task>.
cua.getState() lists a running local Google Chrome browser with provider type extension, alongside native macOS applications.
Existing browser tabs are accessible through the supported mcp__cua_repl.js interface; browser inspection and ordinary UI interactions succeeded.
I also reported that the Chrome plugin would not load in this thread. That specific plugin-loading failure was not reproduced or diagnosed. Working unified computer-use access does not prove that the separate Chrome plugin can load, nor establish why it would not.

This is misleading when a user explicitly asks for a local task on a named computer: “Cloud” does not tell me whether actions and files are local, which computer is actually affected, or which plugin capabilities the task receives. The assistant's initial device assurance was stronger than the verified evidence.

What steps can reproduce the bug?

Observed on October 5, 2026; a deterministic clean-install reproduction has not been established.

From a parent conversation/dot, explicitly request a new task on a connected personal Mac.
Open the delegated task in the desktop app.
Observe that the task is presented as Cloud (user observation), although the assistant initially confirms it is ready on the requested computer.
Ask the task to inspect its execution environment and browser availability using supported read-only tools.
Compare the durable thread host metadata with Darwin shell execution, a Mac workspace path, and an accessible Chrome extension session.
Try to determine from the task UI which exact computer executes actions and whether the separate Chrome plugin is supported for this task type.

What is the expected behavior?

Show conversation backing and execution location separately. For example, clearly identify a cloud-backed conversation with a connected Mac executor, and show the validated execution device and current connection status.

When the user explicitly requests a local Codex task on a particular device, either create that task type or clearly explain the different task type being created. The assistant should verify effective execution-device identity before claiming the requested Mac has been selected.

Display browser/plugin capability availability for this specific task type, and give an actionable explanation when a plugin cannot be loaded even though another computer-use integration works.

Additional information

This report does not establish that the task ran in a Linux cloud sandbox, that actions were executed on the wrong Mac, or that Chrome was entirely unavailable. The root cause and intended semantics of the Cloud label are unconfirmed. Please clarify whether this is expected cloud-conversation/local-executor behavior or a task-routing/labeling defect.

Related but distinct: #49482 concerns discovery and wrong-route diagnostics for continuing local Codex chats; #49458 concerns missing computer-use tools in dot-started Windows tasks. Here, unified computer-use tools are exposed and work, but execution identity and task-type labeling remain unclear.

No private account identifiers, task IDs, device IDs, precise paths, browser history, credentials, transaction details, or screenshots are included. No plugins were reset/reinstalled, security settings changed, or pending browser workflows discarded during diagnosis.

Follow-up: native local task creation succeeds, and differs from the original route

The user's intent was explicit: “create a thread on my MacBook Pro.”

In the original attempt, the assistant selected a cloud-managed creation route targeting the Mac and prematurely confirmed that the requested local thread was ready. Subsequent checks showed a durable/cloud-managed thread identity with Mac shell and browser execution. Mac execution alone did not establish that a native local Codex thread had been created.

A separate follow-up test used the native desktop app's create_thread operation with a projectless target:

Creation returned a ready task with hostId: "local".
An independent read of that task confirmed the local identity.
The test confirmed macOS execution and availability of a desktop-specific capability.

This establishes that the supported native local creation path worked in the tested setup. It also demonstrates an observable distinction between the original durable/cloud-managed task with a Mac executor and the new native local task. It does not establish that every plugin has identical availability across those task types.

Please improve both routing and reporting:

Route an explicit request for a native local thread on a connected Mac through the supported native creation operation.
Clearly display conversation/orchestration type, actual execution device, and available task-specific tools as separate properties.
Verify the returned task identity and effective host before telling the user that the requested local task was successfully created.
If a different task type is selected, explain that distinction before presenting it as fulfillment of the local-thread request.

The original report should therefore be understood as a task-routing and misleading success-confirmation problem as well as a labeling/discoverability problem. Native creation itself was successful in the follow-up test; no root cause for the original route selection or separate plugin-loading report has been established.

No claim is made that the separate Gmail authentication-code redaction behavior was fixed or that it shares this cause. Private task/device identifiers, account details, local paths, credentials, and unrelated transaction information are omitted.

Execution-location ambiguity observed on Windows with Codex 26.930.41038 and ChatGPT Pro 100.

Dot distinguishes between cloud tasks and tasks using a local computer, but both appear as cloud tasks in the desktop UI. The tooltip “Runs on your computer when available” provides a distinction that is not persistently visible.

To reproduce, compare a dot-created task targeting a cloud environment with one targeting a local computer, then inspect their tooltips.

Requested behavior: tasks requiring a local computer should appear as local chats, with a clear disconnected/unreachable status when appropriate. Alternatively, provide a persistent execution-location indicator, such as a distinct icon, without requiring a hover.

October 7 follow-up: previously available native tools are missing, and desktop project discovery now fails

Following up on the successful native local creation test above: the same delegated Mac context now has a different available tool surface, which blocks repeating that supported route.

Previously observed on October 5–6

Native mcp__codex_app__create_thread and list_projects were available, including projectless and saved-local-project creation targets.
The separate projectless creation test returned hostId: "local"; an independent read verified that identity, as documented in the earlier comment.

Observed on October 7

In the affected delegated Mac context, a broad search of the available tool catalog found no native create_thread, list_projects, or read_thread operations, nor the previously available computer-use/Node equivalents.
The selected MacBook Pro is still reported as connected and attached. Authorized shell access to the local repository continues to work.
The parent assistant does expose cloud_threads.create, list_projects, list_threads, read, and send_message. Its creation schema now includes an optional projectId, but the operation is described as creating a durable task. That alone does not establish equivalence with the previously verified native local creation route.
A read-only cloud_threads.list_projects call with the explicitly selected, connected desktop environment returned:

code: CONFLICT
type: desktop_projects_unavailable
Could not list local projects on the selected desktop. Update or reconnect the desktop and retry list_projects. Registered Remotes and cloud containers do not support desktop projects.

The selected target was the connected desktop, rather than a registered Remote or cloud container. This is a failed project-discovery call, separate from the absence of native tools in the delegated context.

Version observations and limits

Desktop bundle build changed from 13100 to 13417.
CLI changed from 0.160.0 to 0.162.0-alpha.2.
These changes are a possible correlation, not an established cause or a bisected regression.
Reconnecting or restarting has not been tested. A clean-install reproduction and the scope across other accounts/devices are unknown.
The user manually opened the desired task. No duplicate task was created to test the uncertain route.

Could the team clarify:

Has native project/thread capability exposure or routing intentionally changed for this delegated Mac context, or is this a regression?
What is the supported route now for creating a native local thread, both projectless and within an existing saved project?
Why does desktop project discovery return desktop_projects_unavailable while the selected desktop is connected and local shell execution works?
If cloud_threads.create(projectId=...) is intended to replace the native route, what returned metadata should be checked to establish the resulting task type and execution host?

Related tool-exposure/project-routing reports exist (including #42973, #44170, and #50158), but those concern different host/build configurations and do not establish a shared cause here. I am keeping these observations on this issue because they directly affect reproducing its previously successful native-creation path.

Private paths, project/task/device identifiers, emails, credentials, unrelated personal data, and raw logs are omitted.

Additional Windows reproduction of the project-discovery failure reported above.

The desktop is reported as connected, attached, and authorized. The parent dot now has cloud_threads.list_projects and create(projectId), but list_projects for that desktop repeatedly returns desktop_projects_unavailable:

“Could not list local projects on the selected desktop. Update or reconnect the desktop and retry list_projects.”

This prevents obtaining the projectId needed to create a task in an existing saved project. Native codex_app tools are also absent from an existing delegated task, while commands in that task have worked after a direct user message. This does not prove that local project discovery works.

The owner-reported app version is 26.1002.51308; I have not independently verified the installed build or a complete restart. No connection to proxy settings or the current update incident has been established.

Which desktop version/capability is required, and what is the supported recovery procedure? Could this error distinguish unsupported capability, transport failure, and registry failure?

Updated to 26.1002.52244, but cloud_threads.list_projects still returns desktop_projects_unavailable while the desktop remains connected, attached, and authorized.

Additional Windows reproduction on desktop app version 26.1002.52244.

The selected desktop, Hachimi, is connected, attached, and authorized for tasks. Local Codex can see the saved projects normally, and the target project itself is valid.

From the parent Dot conversation, cloud_threads.list_projects fails with:

DesktopProjectsUnavailableError: Could not list local projects on the selected desktop.

error_code: CONFLICT
error_data.type: desktop_projects_unavailable

Supplying a known-valid local projectId directly to task creation also fails with:

DesktopTaskProjectUnavailableError

error_data.type: local_project_unavailable
task_created: false

However, the Dot can successfully create a local task on the same desktop when no project is specified. I then passed the same valid projectId to that projectless local task, and the local task was able to use the project successfully.

This suggests that the desktop connection, authorization, local project registry, project itself, and projectId are all valid. The failure appears specific to the parent Dot / cloud_threads path when resolving or attaching a local desktop project.

Rebooting Windows did not change the behavior.

Hola. Agrego una prueba realizada en Windows el 7 de octubre. App: ChatGPT, Powered by Codex & OWL, versión 26.1002.52244, publicada el 07-10-2026.

Con el escritorio conectado y autorizado, cloud_threads.list_projects sigue devolviendo DesktopProjectsUnavailableError tras actualizar y reiniciar.
Las tareas de dot revisadas aparecen sin proyecto y sin la opción «Proyecto»; los chats locales normales sí la tienen.
Usando las herramientas de la app local, list_projects → create_thread, con proyecto y entorno local explícitos, logramos crear una tarea dentro del proyecto correcto, confirmado visualmente.
send_message_to_thread → wait_threads → read_thread permitió enviar una prueba y recuperar su respuesta. Sin embargo, la instrucción apareció como mensaje del usuario, en vez de la presentación de una delegación.
cloud_threads.read sobre esa tarea local falló con «unsupported placement format version 3». No verificamos notificación automática a la conversación padre.

¿Pueden revisar la compatibilidad entre ambas rutas y cómo identificar correctamente las instrucciones enviadas desde dot? La prueba no demuestra que ambas rutas sean equivalentes.

October 10 macOS retest: project discovery still fails, and reading the previously verified native-local thread rejects placement format v3

Following up with fresh read-only diagnostics on October 10, 2026. These results extend the October 7 observations above.

Current installed versions

Desktop app bundle: 26.1002.52244, build 13536.
Bundled CLI: 0.162.0-alpha.2; separately installed global CLI: 0.160.1.
macOS 26.5.2 (25F84), ARM64.

The installed app bundle was inspected; the running GUI build and whether this is the latest available release were not independently verified. The earlier build 13417 should not be treated as the current installed build.

Fresh parent-dot test results

At approximately 16:16 UTC, the selected desktop was reported connected, attached, and authorized.
At 16:17 UTC, cloud_threads.list_projects for that desktop still returned DesktopProjectsUnavailableError, code CONFLICT, type desktop_projects_unavailable.
At approximately 16:12 UTC, cloud_threads.read targeting the same native-local test thread whose hostId: "local" had previously been independently verified failed with:

AppServerBackendRequestError:
Client specified an invalid argument:
post-cutover thread ID [REDACTED] has unsupported placement format version 3

Control: cloud_threads.list_threads(children_only=false) succeeded. This does not establish that its results include every native-local thread.
Control: reading an existing cloud-managed task with a Mac executor succeeded; sending it a follow-up was accepted, and the task subsequently returned diagnostics.

The native-local identity is historical verified evidence. The current failed read returned no content and cannot re-verify that thread's present state. These controls show different outcomes for the tested targets, without establishing the underlying cause.

Delegated Mac tool surface
The existing cloud-managed Mac diagnostic task enumerated 1,095 available tools. It found no native codex_app thread/project operations and no supported replacement for the previously successful native-local creation route in that context. This observation is scoped to that task's tool surface, not every desktop context.

No new native test thread was created because the supported native entry point was unavailable. This diagnostic pass did not restart the app, reconnect the desktop, reinstall anything, or change settings.

The same placement-v3 read symptom was already reported on Windows in this comment; #51722 also tracks the existing-local-thread support/continuation question. A common root cause has not been established.

The October 5–9 release notes describe broader Codex thread continuation, but do not specify which native-local thread types are supported. Could the team clarify:

Which native-local and cloud-managed thread types can a dot discover, read, and continue, and what eligibility or attachment steps apply?
Is the placement-v3 rejection expected for this route, or a compatibility defect? What is the supported recovery path?
Which desktop capability/version is required for project discovery, and how can this error distinguish unsupported capability from transport or project-registry failure?
What is the supported route for creating a native-local thread in an existing saved project when native tools are absent and parent project discovery fails?

Private task/device/project identifiers, local paths, account details, conversation contents, and raw logs are omitted.

October 11 macOS retest: discovery and native creation work again, but the parent still cannot read the native-local thread

Fresh checks on October 11, 2026 establish a partial recovery since the October 10 report:

At approximately 23:11 UTC, the selected Mac was reported connected, attached, and authorized.
Parent cloud_threads.list_projects now succeeds.
Native codex_app.list_threads is available and succeeds in the Mac executor context.
Native codex_app.create_thread was called once and returned a new task with hostId: "local". A separate native codex_app.read_thread call read that task and confirmed kind: "codex", hostId: "local".
At approximately 23:26 UTC, parent cloud_threads.read against that same newly created native-local task failed with:

AppServerBackendRequestError: Client specified an invalid argument: post-cutover thread ID [REDACTED] has unsupported placement region 4
error_code: UNKNOWN

A parent read of the older native-local test thread still returns "unsupported placement format version 3".

For clarity, the successful create/read above use the native Mac tools. They do not establish that the parent's cloud_threads route can read or continue that same task. Parent cloud_threads.list_threads(children_only=false) also succeeds, but the target was not among the first 20 returned results; this was not an exhaustive listing, so it does not establish absence from the parent listing.

The existing cloud-managed diagnostic task with the Mac executor still reports hostId: "durable". Its working native tools do not change its own backing type.

Runtime OS: macOS 26.5.2 (25F84). The desktop app version was not rechecked today; the installed 26.1002.52244/build 13536 observation in the previous comment is dated October 10.

Could the team investigate the parent read route's placement-format/region compatibility and clarify the supported way for a parent dot to read and continue a native-local task it has created through the desktop tools? Native creation and reading work in this test, while direct parent reading remains blocked. The error suggests a compatibility boundary, but the root cause is not established.

Private thread/device/project identifiers, hostnames, paths, account details, and conversation content are omitted.

October 12 macOS follow-up: forwarded approval rejected; direct approval succeeds

This is an additional approval-context symptom; a connection to the routing/read errors above is unconfirmed. The observations below are chronological; the final update records successful creation and completion.

An existing cloud-managed task using the Mac had originally been limited to read-only diagnosis. The owner later explicitly requested a new task that would make scoped changes.
The task requested approval to trust the relevant folder. The owner supplied that approval, and the parent forwarded the request and approval.
The task then reported that native task creation had been rejected because of the original diagnostic restriction. It said the first attempt returned no thread ID or admission, and announced one retry.
The visible history subsequently contains another request to authorize the same local task. It does not expose the actual review response or a separate retry result, so successful admission of the latest attempt remains unverified.
Parent discovery currently finds the connected, authorized Mac and the correct saved local project. Reading the coordinator still returns inProgress, error: null, and the pending question. Follow-up messages were accepted as steering messages, but repeated reads have not shown the question resolved.

The parent also has a supported cloud-managed creation route targeting the Mac. That route has not been attempted for this pending request while the denial and possible retry admission remain unresolved, to avoid duplicate creation or bypassing a restriction.

Could the team clarify how a later owner-authorized scope change should supersede an earlier task-specific read-only restriction, and how the parent should resolve or answer this pending approval request? The available evidence does not establish a backend permission defect or its cause.

Private identifiers, paths, project names, transaction data, and conversation contents are omitted.

Update after the coordinator completed: the two native mcp__codex_app__create_thread calls are confirmed failed, rather than hanging. Both returned isError: true from automatic approval review. The first response cited private source context, the original prohibition on creating further tasks, and absence of a trusted user message authorizing the new task. The identical retry was rejected as unauthorized for the same scope conflict.

Neither call returned a thread ID; a fresh thread listing found no matching worker. Folder trust was accepted, the local project was registered, and native project/list/read operations worked. The later approval relayed by the parent was therefore not recognized as sufficient by the review; why remains unconfirmed. This establishes an approval-review block, without establishing a Mac routing failure or a backend propagation defect.

Creation remains paused while fresh, explicit approval covering the new task and its private source context is sought. No further creation attempt or alternate-route workaround has been made. This update supersedes the earlier uncertainty about whether the retry was still pending or had admitted a task.

21:42 UTC update: after the owner gave fresh explicit approval in the parent conversation, that approval was forwarded and one new native creation attempt was made. It again returned isError: true. This response specifically said the requested task would transmit private source context and authorize consequential app writes, but that the apparent approval was embedded in untrusted transcript evidence rather than a trusted user instruction.

This identifies the immediate rejection reason: forwarded authorization was treated as untrusted. Whether that distinction is intended behavior or an approval-propagation defect remains unconfirmed. No thread ID was returned, no task was admitted, and no app records were written. Execution stopped after that rejection.

The parent is asking the owner to provide the instruction directly inside the existing task; no alternate-route workaround has been attempted. Please clarify the supported way to convey owner approval from a parent conversation to a delegated task.

Outcome update, 21:54 UTC: the owner entered authorization directly inside the existing Mac coordinator conversation. Native task creation then succeeded. At approximately 21:47 UTC, a separate native read verified the new task with hostId: local and the intended repository. The scoped work completed and its saved results were verified by approximately 21:54 UTC.

This narrows the observed difference to recognition of forwarded parent approval versus direct owner approval in this reused diagnostic conversation. It does not establish whether that distinction is intended, nor demonstrate a general routing or parent-read fix. The earlier rejection evidence remains above for investigation.

October 13 follow-up: tasks visible on MacBook Pro are missing from iOS Remote, including “All”

On October 13, 2026, three tasks successfully ran on my MacBook Pro. I then confirmed that those same tasks are visible in the desktop app.

In iOS Remote, however, I cannot find these tasks with either the MacBook Pro filter or “All” selected.

Expected: the same existing tasks should be discoverable in the appropriate task lists across these clients, or the interface should clearly explain any intentional visibility limitation.

Actual: the tasks work and are visible on the Mac, but are missing from both of the checked iOS Remote views.

Please investigate this cross-client task-list visibility discrepancy. Successful execution and desktop visibility are confirmed; a synchronization root cause has not been established.

No screenshots, project names, private identifiers, paths, or task contents are included.

Navigation Menu

Repository navigation

Cloud task label obscures local Mac execution host and browser/plugin availability #51197

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Follow-up: native local task creation succeeds, and differs from the original route

October 7 follow-up: previously available native tools are missing, and desktop project discovery now fails

October 10 macOS retest: project discovery still fails, and reading the previously verified native-local thread rejects placement format v3

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Cloud task label obscures local Mac execution host and browser/plugin availability #51197

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

johnsilvavlogs commented on Oct 5, 2026

Follow-up: native local task creation succeeds, and differs from the original route

dean1012 commented on Oct 6, 2026

johnsilvavlogs commented on Oct 7, 2026

October 7 follow-up: previously available native tools are missing, and desktop project discovery now fails

unrespect commented on Oct 7, 2026

0923yukimi commented on Oct 7, 2026

0923yukimi commented on Oct 7, 2026

Manya-84 commented on Oct 8, 2026

johnsilvavlogs commented on Oct 10, 2026

October 10 macOS retest: project discovery still fails, and reading the previously verified native-local thread rejects placement format v3

johnsilvavlogs commented on Oct 11, 2026

johnsilvavlogs commented on Oct 12, 2026

johnsilvavlogs commented on Oct 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions