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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Jun 23, 2026
2. demiurg92 commented on Jul 3, 2026

   

   demiurg92

   on Jul 3, 2026

   More actions

   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.

   👍React with 👍1Reacted by Ayan Mullick
3. Ayanmullick commented on Jul 22, 2026

   

   Ayanmullick

   on Jul 22, 2026

   Last edited by Ayanmullick

   More actions

   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.
4. wenyuanyu commented on Sep 8, 2026

   

   wenyuanyu

   on Sep 8, 2026

   More actions

   Reproduced on macOS with desktop version 26.901.51231 (bundled app-server reports 0.153.4).

   The existing Cloud task loads successfully in the desktop app and has a cloud icon in the sidebar. However, the “Run follow-up in” dropdown contains only Local; Cloud is absent. The same task can be continued on the web, and a live codex cloud status check succeeds and reports READY. This is not evidence of an expired or inaccessible task.

   Reproduction

   1. Open an existing Codex Cloud task in the desktop app.
   2. Use a desktop context where the follow-up composer does not resolve a local Git repository.
   3. Open the follow-up location dropdown.
   4. Observe that only Local is offered, although the original cloud task is accessible on the web.

   Implementation evidence from the installed build

   Read-only inspection of the installed frontend identifies the follow-up location component in composer-utility-bar-731e84ddf1fb.js:

   • It obtains a desktop execution context and queries Git metadata for that context's directory.
   • It renders the Cloud choice only when the Git metadata contains a repository root.
   • After metadata loading finishes without a repository root, an effect switches the composer mode to Local.

   This appears to couple continuing an existing Cloud task to local Git discovery, rather than to the existing task's cloud environment. The observed menu matches this branch. The precise runtime directory was not captured, so the remaining question is why Git discovery does not resolve a root for this task.

   There is also a desktop warning for the affected task: “No owner repo found for remote task”. Inspection shows this warning can occur when resolving the task's environment label to environment repository metadata fails. It does not by itself prove that the environment was deleted or that the local clone is missing.

   The persisted desktop Cloud-access state is enabled (cached state, not a live entitlement check). No credentials, cache, configuration, or application files were modified during diagnosis.

   Expected behavior

   Allow an existing Cloud task to continue in its cloud environment without requiring a local Git checkout. If cloud continuation is unavailable for another reason, show that reason explicitly instead of silently hiding Cloud and switching to Local.

   This confirms the behavior on the version above; it does not establish which release introduced it. Task identifiers and unrelated screenshot content are omitted for privacy.
5. Raskolnikov-kai49 commented on Oct 5, 2026

   

   Raskolnikov-kai49

   on Oct 5, 2026 – with ChatGPT Codex Connector

   More actions

   I am seeing a closely related regression in the current Codex Cloud workflow, with an additional continuity problem that makes iterative PR work difficult.

   Observed behavior:

   1. I start a new Codex Cloud task. The initial Cloud task does not show a model picker.

   2. After the Cloud task completes, I try to send a follow-up.

   3. At that point a model picker appears, but the continuation flow is Local-oriented rather than continuing the same Cloud task/workspace.

   4. More importantly, the original Cloud task is no longer reopenable/resumable from the UI in a way that allows another Cloud turn.

   5. As a result, I cannot use the previous workflow of:

      Cloud task -> implement -> PR -> CI feedback -> same Cloud task -> update same PR

      while preserving the Cloud task's context/workspace.

   6. To continue using Cloud, I effectively have to start a new Cloud task. That loses the previous task/session context and makes iterative work on an existing PR substantially more cumbersome; in practice it pushes the workflow toward one bounded Cloud task per iteration instead of repeated updates from the same Cloud session.

   The model-picker behavior also suggests that the follow-up composer may be routing into a new Local continuation rather than resuming the original Cloud execution context: the picker is absent for the initial Cloud task but appears only when attempting the follow-up that is Local-oriented.

   Expected behavior:

   • A completed Cloud task should remain reopenable/resumable.
   • Follow-up should allow another turn in the same Cloud task/workspace.
   • The same Cloud task should be usable for iterative development on the same branch/PR, including responding to CI failures and updating the existing PR without reconstructing task context from scratch.
   • If Local handoff is offered, it should be optional rather than the only continuation path.

   This is especially disruptive for longer-lived engineering work where a PR is refined over several CI/review cycles. The issue is not merely losing chat history: the practical regression is loss of Cloud task/workspace continuity between iterations.
6. Raskolnikov-kai49 commented on Oct 5, 2026

   

   Raskolnikov-kai49

   on Oct 5, 2026 – with ChatGPT Codex Connector

   More actions

   Update: Cloud continuation has become available again for me, but the underlying iterative-PR problem remains.

   I tested continuing work from the same Cloud session. The session itself can now accept another Cloud turn, but it cannot update the existing branch/PR created by the earlier turn. To continue the work, I am effectively required to create a new PR.

   That means the practical workflow is still roughly:

   Cloud task/session -> PR A -> follow-up in same Cloud session -> cannot update PR A -> create PR B

   This is not materially better than starting a brand-new Cloud session for the next iteration, because the normal engineering loop I need is:

   Cloud task -> implement -> PR -> CI/review feedback -> same task/session -> push to same branch -> update same PR

   Expected behavior:

   • A resumed Cloud task/session should retain or recover the original branch/worktree association.
   • A follow-up should be able to commit/push to the same branch and update the existing PR when that is the user's intent.
   • Creating a new PR should be optional, not required for every follow-up iteration.

   So Cloud-session continuity appears partially restored, but branch/PR continuity is still broken. For iterative development, this remains a significant regression.