›_ Codex Issues
Codex Issues / #29694

Codex desktop app only offers Local when continuing a visible Cloud task

Open 💬 2 comments Opened Jun 23, 2026 by andyprevalsky

What happened?

In the Codex desktop app on macOS, I can see a Codex Cloud task under a project/environment, but when I try to continue it from the desktop app composer, the only available destination is Local. There is no Cloud option.

The composer text says:

Create a new local task that references this cloud task

and the destination dropdown shows only:

Continue in
- Local

This makes it look like the desktop app can view/reference the cloud task, but cannot continue it in Cloud.

Expected behavior

When viewing a Codex Cloud task in the desktop app, I expected to be able to continue/follow up in the same Cloud environment, or at least choose Cloud in the destination selector.

Actual behavior

Only Local is offered. Continuing from the desktop app creates a local task that references the cloud task instead of continuing the cloud task in Cloud.

Evidence / checks

  • The same Cloud environment is visible and works in the web app.
  • The desktop app sidebar shows the project/environment and the Cloud task.
  • codex cloud list on the same machine can see the task successfully.
  • CLI output shows the task as [READY], environment label rose, with no diff.
  • codex cloud --help is available locally.

Redacted CLI/task detail:

codex-cli 0.128.0
codex cloud list
https://chatgpt.com/codex/tasks/task_e_[redacted]
  [READY] Hello
  rose  •  ~20m ago
  no diff

Environment

  • Platform: macOS
  • Surface: Codex desktop app
  • CLI version: codex-cli 0.128.0
  • Cloud environment label: rose
  • Branch shown in web app: main

Related/possibly adjacent

I found a similar/adjacent issue about desktop app Cloud task availability, but this case is different because Cloud auth works and the task is visible in both the web app and CLI; only desktop follow-up routing is limited to Local.

View original on GitHub ↗

2 Comments

demiurg92 · 1 month ago

Additional data point: I can reproduce a similar issue on a second Windows machine as well.

On that Windows machine:

  • Cloud environment is configured
  • GitHub repository is connected
  • The Desktop app no longer exposes the quick commands/actions for running tasks from the configured environment
  • I also no longer see a way to send work to Codex Cloud from the Desktop app

So this does not look macOS-specific. It appears to affect the Desktop app UI/workflow across at least macOS and Windows after a recent update.

On my macOS machine:

  • Codex Desktop: 26.623.101652
  • Bundled CLI: codex-cli 0.142.5
  • codex cloud list works
  • Local state shows Codex Cloud access enabled and an existing Cloud environment
  • But Desktop only exposes the local path instead of the expected Cloud workflow

Impact:
This blocks using Codex Desktop for hosted Cloud tasks even when Cloud access and environments are configured. The workaround is to use Codex web or CLI, but the Desktop UI no longer exposes the expected Cloud launch path.

Ayanmullick · 1 month ago

I can reproduce a closely related issue on Windows using Codex Desktop 26.715.8383.0.

Unlike the original report, this occurs when creating a new task from an existing Cloud project, rather than when continuing an existing Cloud task.

Expected behavior

Creating a task from the configured Cloud project should start a task in its associated Cloud environment.

Actual behavior

Codex Desktop creates a local, projectless task. The resulting task metadata records:

  • environment_id = "local"
  • workspace_kind = "projectless"
  • A local working directory under C:\Users\<USERNAME>\Documents\Codex\…

At the same time, the application state indicates:

  • Cloud access is enabled
  • Work run location is set to Cloud
  • A valid Cloud project is selected
  • The configured Cloud environment is writable

There is no Cloud submission or rejection error—the client appears to create the task as Local from the outset. The Cloud selector and /cloud-environment command are also unavailable.

This appears consistent with the Desktop Cloud-to-Local routing problem described in this issue, but through the new-task flow.