codex cloud does not discover current Cloud environments

What version of Codex CLI is running?

codex-cli 0.160.0, the npm latest release at the time of this check.

Authentication

ChatGPT authentication. The CLI and desktop app use the same account. Token refresh succeeds. No API key is in use.

Platform

macOS, Darwin 24.6.0 arm64 arm. I ran these checks through a terminal PTY.

What issue are you seeing?

I can see two owned, Private environments in Settings > Codex Cloud. Neither has an Unpublished badge. The settings catalog returns both environments with current versions when requested with scope=user&omitDraft=true; it returns no further page. The workspace catalog returns zero environments. Legacy Codex Cloud shows “No cloud environments yet”.

On the same account, codex cloud shows only “All Environments (Global)” in its environment picker. I get the same result from a checkout with a GitHub remote and from /tmp.

An explicit submission exits 1 with:

Error: no cloud environments are available for this workspace

The CLI's catalog requests return HTTP 200. Its repository-specific lookup returns zero environments. codex cloud list --json returns {"tasks":[],"cursor":null}; I understand that this is an execution-task list, not an environment inventory.

What steps can reproduce the bug?

Use a ChatGPT account with current Cloud environments visible in Settings > Codex Cloud and no environments in Legacy Codex Cloud.
Authenticate the latest CLI with that account.
Run codex cloud, open the environment picker, and inspect the choices without submitting.
Compare the picker from the repository checkout and from /tmp.
Try codex cloud exec --env '<environment identifier>' --branch main --attempts 1 'Read-only environment canary; report pwd and git HEAD, then stop.'.

The submission above fails during environment resolution before creating a task. No canary has run.

What is the expected behavior?

The CLI should list accessible current Cloud environments and accept the supported identifier for fresh task dispatch. If this environment type requires a different CLI route, please document the command and identifier mapping.

The CLI documentation describes task submission through codex cloud exec --env, and the Cloud overview describes starting Cloud work from the CLI.

Diagnostic evidence

Current settings load /api/codex-cloud/v1/environment-configs?scope=user&limit=100&omitDraft=true. Its entries use provider=caas, stable IDs with an asenvcfg_ component, and version IDs with a cecfgver_ component.
CLI 0.160.0's environment discovery code queries /backend-api/wham/environments/by-repo/github/OWNER/REPO and /backend-api/wham/environments.
Its resolve_environment_id function rejects an empty catalog before matching --env. Replacing a version ID with a stable ID therefore cannot bypass this result.
I compared env_detect.rs in 0.160.0 and 0.162.0-alpha.3; the bytes match. I did not install or run the alpha release.
CODEX_CLOUD_TASKS_BASE_URL, CODEX_CLOUD_TASKS_MODE and CODEX_STARTING_DIFF are unset.
The existing doctor run passed installation/version, authentication, HTTP connectivity and the Responses WebSocket handshake. It also reported optional local MCP/state/terminal warnings; I have no evidence that they affect catalog discovery.

These observations suggest a mismatch between the current and legacy catalogs. Please confirm whether the released CLI supports the current environments and identify the supported repair or route.

Related: #49966 reports the new/legacy selection difference in the web UI. This report supplies CLI discovery and resolution evidence. #15544 concerns empty task-list reporting and was closed as not planned; this request concerns access to environments that exist in the current catalog.

I omitted account identifiers, environment identifiers, repository names, credentials and raw local logs.

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

Codex web only listing legacy environments. #49966

Powered by Codex Action

Still reproducible with the official codex-cli 0.162.0-alpha.7 Linux binary on NixOS/WSL2: codex cloud list --env <new-env-id> --json exits 1 with environment '…' not found, while existing tasks remain readable with the same login.

env_detect.rs is byte-identical to 0.160.0; no task submission was attempted.

+1, i had the same problem, can not make the new codex cloud work.

I can reproduce the same underlying environment-catalog mismatch on the web only, without the CLI or desktop app.

Setup:

ChatGPT Plus
macOS
Firefox, latest version
No Codex CLI installed
No Codex desktop app installed

Reproduction:

Go to https://chatgpt.com/settings/codex-cloud.
Create and publish a new Codex Cloud environment.
Confirm that the environment appears in the Codex Cloud settings page.
Switch to Codex in the ChatGPT web UI.
Open the environment selector above the “What should we build?” prompt.

Expected:
The newly published Codex Cloud environments should be available for selection.

Actual:
The selector only shows my older/legacy cloud environments. The newly created environments from Settings → Codex Cloud do not appear at all.

Additional observations:

The new environments are definitely present and editable under Settings → Codex Cloud.
The environment menu in the Codex web composer appears to be backed by a different, legacy environment catalog.
https://chatgpt.com/codex/cloud redirects to https://chatgpt.com with Codex selected and shows the same composer. It does not expose a separate Work in → Cloud flow or a selector containing the new environments.
This occurs entirely in the browser, so the issue is not specific to the CLI or desktop client.

This looks like the same catalog/backend split described here, and also matches the symptoms in #49966.

I can report that as of this morning, I can now see the new cloud environment task selector in the Codex web interface.

Merge pull request #349 from ndunl075/docs/g7-codex-blocked

Quick follow-up: I reproduced this today with the official 0.162.0-alpha.18 Linux binary on NixOS/WSL2 (release checksum verified), using the same existing ChatGPT login as 0.160.1.

codex cloud list --env <new-env-id> --json still exits 1 with environment '…' not found in both versions.
The unfiltered list still returns older tasks, and a known existing task remains readable with status READY.
A completed new Cloud thread is accessible in the desktop app (hostId=durable), but absent from the CLI list. codex resume --all <thread-uuid> exits with No saved session found.

A cloud status <thread-uuid> probe still routes to /backend-api/wham/tasks/<uuid> and returns HTTP 404 / Invalid task ID. I’m not assuming a new thread UUID is valid for that task API; this just confirms the route being used.

I also checked the new Rust codex-cloud-client. Its README requires a native gRPC origin but doesn’t provide a production endpoint, so I haven’t tested it live.

Could you clarify the supported CLI path and ID mapping for the new Cloud? If the Rust client is the intended route, is there a documented public endpoint we can test?

G7: Codex cloud is blocked on openai/codex#50182 [skip ci]

I have the same issue.

CLI: codex-cli 0.161.0, npm installation.
Host: macOS 26.6, arm64.
Account: ChatGPT Pro, personal workspace. I confirmed the CLI account and personal workspace match the account owning the published environment.

We’re seeing the same issue on macOS with both 0.160.0 and the latest stable 0.162.0. The published new Cloud environment is visible in the app, but the CLI returns zero environments in both repository-specific and global discovery. We verified that the CLI is signed into the same ChatGPT account. Updating to 0.162.0 did not resolve it.

If it can help someone, I found a temporary trick, while we're waiting the fix: just make an agent on both sessions and create a MCP relay between them. 😏

+Additional reproduction on 12 October 2026 with the official stable codex-cli 0.162.1, ChatGPT Pro and a Personal workspace:

A private published environment ran a real coding task through the web interface, including a file edit, five passing assertions and a returned diff.
The Mac and remote Linux CLI account/user/default-workspace metadata match; the web profile agrees.
The CLI's global environment catalogue returns HTTP 200 with [], and repository discovery returns zero environments.
Filtered listing exits 1: "Error: no cloud environments are available for this workspace".
Unfiltered listing succeeds with {"tasks":[],"cursor":null}, omitting the completed web task.
Testing the correct GitHub origin and an isolated official 0.162.1 install did not repair discovery. Credentials and configuration were not changed.

Does the released CLI currently support environments published through the new Codex Cloud interface, or only the Legacy catalogue? If the new interface is supported, what exact supported command/version and identifier should launch a task AND retrieve its result? Is there a tracked fix or rollout for this catalogue discrepancy?

Please suggest a route that preserves the existing environment and authentication, without private endpoints or approval/sandbox bypass. Account, repository, environment and thread identifiers are intentionally omitted.

I am having the same issue.

Additional reproduction on October 23, 2026, on macOS using codex-cli 0.163.0.

A published current Codex Cloud environment is visible in Settings > Codex Cloud. A read-only lookup using the environment ID previously saved for our orchestration app:

codex cloud list --env <saved-environment-id> --limit 1 --json

exits 1 with:

Error: no cloud environments are available for this workspace

This blocks Bumble, our orchestration app, from launching parallel Codex Cloud workers through codex cloud exec. The legacy environment settings link redirects to ChatGPT's home page on this account, so we could not reach a legacy environment creation screen either. No task was submitted during this check.

Could the Codex team confirm a supported programmatic route for submitting tasks to current published cloud environments, checking status, and retrieving results? Is there a target fix version or rollout ETA for this discovery issue?

Account details, repository identifiers, credentials, and the actual environment ID are omitted.

+1, same issue on codex-cli 0.164.0. Our envs were created in the new Codex app, and codex cloud exec --env <new env> just says "not found". Would really like CLI support for the new environments. Any ETA? Thanks!

We're seeing this too. On the latest CLI, codex cloud only lists our legacy environments and rejects the new environment's ID, so our automation is stuck on the legacy env. Our main reason for wanting the new environments is runtime secret delivery: it would let cloud tasks push their own branches. Supporting current environments in codex cloud (listing them and submitting to them) would help.

Same issue on Windows 11 Pro (x64) with ChatGPT auth (Pro, personal workspace only, no API key). OpenAI support case 18493702 pointed me here.

Versions: codex-cli 0.162.0-alpha.2, 0.164.0-alpha.11.1 (bundled with the desktop app 26.1021.3705.0 and the VS Code extension), and 0.165.0 (npx). All three give the same result.
One private environment, created and published from the Codex desktop app, is visible in Settings > Codex Cloud with no Unpublished badge. Cloud tasks started from the web/desktop composer run fine in it.
codex cloud exec --env <name> and --env <asenvcfg composite id> both fail with Error: no cloud environments are available for this workspace. codex cloud list returns No tasks found.
I deleted a leftover Unpublished duplicate and republished, as support suggested. No change.
The CLI's account/read reports the same chatgptAccountId that prefixes the web environment's config id, with no workspace override. So it is the same account and workspace.
The 0.164 binary only contains /wham/environments and /wham/environments/by-repo/github/. The web picker uses /api/codex-cloud/v1/environment-configs.
Feedback session id: no-active-thread-01a181a8-7373-7611-bacd-d927d487310b

CLI support for current (environment-configs) environments would let us dispatch cloud tasks from scripts again.

Published Codex Cloud environment absent from CLI discovery

The current web/desktop Codex Cloud experience can launch tasks from a published private GitHub environment. Those tasks have the prepared repository, tools, and dependencies. The documented CLI cannot discover or select that environment.

Reproduction

On macOS, signed in with ChatGPT Pro, run:

codex login status
codex cloud list --json
codex cloud exec --env '<published environment name>' --branch '<default branch>' '<read-only environment check>'

Observed on CLI 0.162.1 and freshly invoked CLI 0.165.0:

Login uses ChatGPT. CLI and desktop account IDs independently match; their account-limit and credit snapshots also match. No credentials or authentication configuration were changed.
Task listing succeeds and returns an empty tasks array.
The repository URL is correctly recognized as a GitHub repository. Both repository-specific and global environment-discovery requests complete with HTTP 200.
Submission exits 1: no cloud environments are available for this workspace. No task URL is returned.
In the published 0.165.0 source, environment discovery must return a row before an explicit ID or name can match. The failure precedes task creation.
Supported setup/runtime tools expose a reusable source_config_id and a published source_config_version_id, but no CLI mapping, explicit owner-workspace metadata, or supported task-launch export. The setup label matches the requested name.

The newer published environment is usable through the normal Codex Cloud task picker. This result does not establish whether the problem is environment visibility, owner-workspace selection, entitlement behavior, or compatibility between the current environment system and the CLI. API endpoint names alone do not prove that the CLI targets only Legacy environments.

Clarification requested

Does the current codex cloud exec support the published environments described in the current cloud-environment guide? If so, what supported workspace selection and environment identifier should be used when discovery returns no rows? If it supports only another environment system, please document the distinction and the supported noninteractive launch path for current environments.

Official guides: cloud environments, CLI cloud commands, and Legacy environments.

Primary CLI source: environment selection and environment discovery.

No repository names, environment IDs, account IDs, user paths, contact information, credentials, private source, or cloud logs are included in this report. Posted as an additional reproduction on 29 October 2026.

Additional reproduction on Linux ARM64 with ChatGPT OAuth: observed on codex-cli 0.163.0 and reproduced after updating through the original global npm installation to 0.166.0.

The owner sees the repository environment as ready in the Codex app. The checkout remote was independently verified to match the intended GitHub repository. OAuth login succeeds; repeating device login did not resolve discovery.

One RUST_LOG=debug discovery run on each version reports:

env_tui: by-repo OWNER:REPO -> 0 envs
env_tui: global list -> 0 envs

OWNER:REPO is redacted here. Both lines occurred again after opening Set Env. The TUI exposes only All Environments (Global) and retains a Loading indicator. Captured diagnostics contained no HTTP status codes, timeout or parsing errors, so we are not claiming a particular HTTP response or root cause.

On 0.163.0, explicit submission using the unchanged app-level saved configuration ID failed with exit 1:

Error: no cloud environments are available for this workspace

Command shape:

codex cloud exec --env "<account-id>~asenvcfg_<id>" --branch master --attempts 1 "<task prompt>"

The account/configuration identifier is withheld from this public comment for privacy; its format is preserved above. No task launched. After upgrading to 0.166.0 we repeated discovery once, not submission.

Can maintainers confirm whether app saved environmentConfigId values are supported by codex cloud exec --env, and why global discovery reports zero while the app exposes the ready configuration? Is a supported current-environment selection route available in the released CLI? No credentials, authorization headers or raw private logs are included.

Still reproduces on codex-cli 0.167.0 (latest on npm as of 2026-11-07), Linux x86_64, ChatGPT login via codex login --device-auth.

The environment is published and usable from the ChatGPT web app (several cloud tasks ran successfully today).
codex cloud list --json returns {"tasks": [], "cursor": null} even though those web tasks exist.
codex cloud exec --env <any id or label> "..." fails with Error: no cloud environments are available for this workspace.
Same result with a fresh CODEX_HOME and a fresh login.

Same issue here.

codex-cli 0.167.0, Windows (Git Bash)
codex login status → Logged in using ChatGPT (personal workspace)
Environment exists in web, linked to the repo, web tasks run fine
Running from the repo checkout (origin matches)
codex cloud exec --env env_b64_… "…" → Error: no cloud environments are available for this workspace
codex cloud list --json → {"tasks": [], "cursor": null}
Debug log: auth mode=ChatGPT, list_tasks env= items=0
ChatGPT-Account-Id header is identical in CLI and web (checked via browser devtools)

Let me get this straight...

OpenAI has virtually unlimited inference, solves novel math problems and does ground breaking cyber research... but... they can't fix this?

they just don't GIVE A F*CK

I switched to Claude & I have no regrets. Their cloud sessions actually work - unbelievable.

BTW, I commented on this issue 1 month ago today.

I signed up for openai using a one-month promotional program to see how everything works. I've been a claude max/ultra subscriber for 6 months.

I'm now, uh, 3 hours into trying to get this to work and its kind of amazing. Between the clunky workspace setup (i can't invite my second seat - email invites are missing and there's no other way to figure it out), being gaslit by both the online support bot and chatgpt sol (they make up documentation, make up settings steps i need to do to fix this stuff, make up urls that aren't correct), AND not being able to get the cloud cli to work at all - i'm pretty frustrated lol. It's amazing that the models themselves don't seem to know how their own tooling works. I've never had this issue with Claude but that's a separate thing.

So - I have an environment (and like 5 "chats" to edit them?) that seems to be published, but can't access it from anywhere externally - exactly the situation that this task is documenting. It's kind of wild.

I will continue to try and get this working but as a new user it's really rough - I have no idea if I'm doing something wrong and have to continuously figure out what the docs and models are trying to tell me to do, and it turns out it's just a bug in the base functionality. Ugh frustrating hah.

Additional verified reproduction — Linux, ChatGPT authentication (November 11, 2026)

I have confirmed that an existing environment is published and visible in the current Codex web interface. The CLI still does not expose it. The owner has now verified that web and CLI are signed in with the same ChatGPT account email (the CLI email was returned by the officially documented App Server account/read method with refreshToken: false; the owner compared it privately to the web account). Workspace identity remains unverified because the CLI response did not expose a workspace label, stable workspace identifier, or workspaceRouting field.

Installed CLI (read-only diagnostics):

Platform: Linux.
codex-cli 0.155.1, installed through npm in the user account.
codex login status: Logged in using ChatGPT.
App Server account/read: authentication type chatgpt; account email matches the web account email, verified privately by the owner. The actual email is withheld. No comparable workspace identifier was returned.
codex cloud list --json --limit 1: {"tasks":[],"cursor":null}. This is an empty task list, not an environment inventory.
Interactive Cloud environment picker: only All Environments (Global); no named published environment. A terminal PTY cursor-position issue on the initial diagnostic attempt was resolved on a second attempt.
No Cloud task/canary was submitted. No authentication changes, CLI replacement, private API requests, or local execution fallback.

Official source check (inspection only; 0.167.1 was not installed or run):

Stable tag rust-v0.167.1 (env_detect.rs): environment discovery continues to use the older repository/global catalog routes: https://github.com/openai/codex/blob/rust-v0.167.1/codex-rs/cloud-tasks/src/env_detect.rs#L307-L375
cloud-tasks/src/lib.rs: explicit --env ID resolution depends on the discovered catalog, so an empty result prevents dispatch: https://github.com/openai/codex/blob/rust-v0.167.1/codex-rs/cloud-tasks/src/lib.rs#L178-L247
These source findings do not demonstrate that newer task creation, task monitoring, or complete native execution-log retrieval works. Related reports (codex cloud: CLI cannot discover new-generation cloud environments, and cloud exec silently ignores model / reasoning-effort overrides #56350, codex cloud exec: POST /wham/tasks returns HTTP 500 for current caas environment IDs (asenvcfg_*) #56995) describe separate lifecycle gaps.

Request to maintainers: Is there a documented, supported ChatGPT-subscription-authenticated CLI/SDK route to (1) discover/select existing current-generation published Cloud environments, (2) dispatch against a specific Git repository and immutable commit, (3) monitor/list the resulting task, and (4) retrieve native execution evidence, including checkout provenance and effective model settings? If not, is there a tracked fix or release milestone covering the full lifecycle rather than discovery alone?

Account identifiers, environment identifiers, private repositories, credentials, and raw diagnostic logs intentionally omitted.

Additional reproduction on Windows with codex-cli 0.167.0-alpha.3.2: the desktop environment-list tool returns the same Default environment (asenvcfg_base) twice, both ready and runnable: true. In the same local workflow, codex cloud exec --env asenvcfg_base … exits with Error: no cloud environments are available for this workspace; codex cloud list --limit 5 --json returned no tasks. The separate desktop Codex Cloud dispatch returned no task ID before cancellation. Please verify whether current and legacy environment discovery differ on this version, whether the duplicate default row and desktop dispatch problem are related, and identify a supported launch path. This reproduction does not establish an account restriction.

Clarification to my Windows reproduction: the user-facing impact is that Codex Cloud was shown as available and runnable, but the user could not use the feature to launch work. The customer is asking OpenAI to verify whether Codex Cloud was not provisioned under their paid plan or was blocked at the account/workspace level, and to restore access if it should be included. The earlier comment emphasized environment discovery and did not lead with this impact. Please verify the cause and explain how to get a supported launch.

Confirmed again with codex-cli 0.168.0 on Windows using an isolated installation and successful ChatGPT authentication. Our published private environment is visible in current Codex Cloud web settings, but codex cloud list --env --limit 5 --json returns environment not found. The CLI environment picker still shows only Global and our Legacy environment. Same result as 0.167.0; no Cloud configuration changes were made.

Same failure on codex-cli 0.166.0 (macOS, signed in with ChatGPT personal workspace). Unlike the original report, this is with a non-empty --env.

There's one Cloud environment visible in Settings > Codex Cloud, and tasks submitted to it from the web UI run normally.

codex cloud list runs and returns "No tasks found."

Using the environment name:

codex cloud exec --env <environment name> --branch main --attempts 1 "Read-only test: list the top-level folders. Change nothing."

fails before any task is created:

Error: no cloud environments are available for this workspace

The same command with the ccarenv_b64_... identifier that a Cloud task reports fails with the identical error. That identifier seems to change per task, so it may not be the environment ID, but I couldn't find any other identifier for the environment in the web UI.

With RUST_LOG=debug set, the output is only that one line. No other log lines appear before the failure.

So on 0.166.0, neither the environment name nor its identifier resolves for an environment that works from the web UI. Is there a supported identifier format, or a different command, for current Cloud environments?

Navigation Menu

Repository navigation

codex cloud does not discover current Cloud environments #50182

codex cloud does not discover current Cloud environments

What version of Codex CLI is running?

Authentication

Platform

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Diagnostic evidence

7 remaining items

Published Codex Cloud environment absent from CLI discovery

Reproduction

Clarification requested

Additional verified reproduction — Linux, ChatGPT authentication (November 11, 2026)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

codex cloud does not discover current Cloud environments #50182

Description

codex cloud does not discover current Cloud environments

What version of Codex CLI is running?

Authentication

Platform

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Diagnostic evidence

Activity

github-actions commented on Oct 2, 2026

servrox commented on Oct 2, 2026

dustin-pham2511 commented on Oct 3, 2026

mauritium commented on Oct 4, 2026

mauritium commented on Oct 6, 2026

servrox commented on Oct 7, 2026

jim-eaton-home commented on Oct 8, 2026

wx-alfred commented on Oct 9, 2026

Lcfvs commented on Oct 12, 2026

Eurostrokes commented on Oct 12, 2026

mariusmcl commented on Oct 14, 2026

7 remaining items

heymoosh commented on Oct 23, 2026

kevinsslin commented on Oct 26, 2026

joshsmith722 commented on Oct 26, 2026

davidjone1014 commented on Oct 28, 2026

aioli3 commented on Oct 29, 2026

Published Codex Cloud environment absent from CLI discovery

Reproduction

Clarification requested

joacorma commented on Nov 3, 2026

dracula911 commented on Nov 7, 2026

maximilianwayand commented on Nov 10, 2026

eyueldk commented on Nov 10, 2026

booherbg commented on Nov 10, 2026

NaughtySwege commented on Nov 11, 2026

Additional verified reproduction — Linux, ChatGPT authentication (November 11, 2026)

an87key-bot commented on Nov 13, 2026

an87key-bot commented on Nov 13, 2026

dantbh commented on Nov 13, 2026

aelb66 commented on Nov 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions