OpenAI is building a new Codex Cloud service that separates from the existing offering and adds agent-led environment setup, private-network access through Tailscale, proxy-delivered secrets, and cloud workload identities. The unreleased system, found in production desktop build 9922, sits behind a feature gate and shows active development but no confirmed launch timeline.
The new path appears alongside the current service, now labeled "Cloud (Legacy)." It would let Codex conduct an onboarding conversation, inspect selected repositories, and prepare an environment draft for developer review - a workflow that shifts more of the security boundary to OpenAI and requires enterprises to trust its handling of reusable network keys and agent-proposed configurations.
A parallel cloud path with agent-led setup
Build 9922 contains separate run-location entries for "Cloud" and "Cloud (Legacy)." The new option is described as a cloud-hosted Codex task without access to the user's computer. Both the runner and a redesigned environment catalog remain behind feature gate 375130565, which establishes active development but not public availability.
When the gate is enabled, Codex can start a cloud task without an active local or remote project. The client stores a local, cloud, or remote execution preference for each account and project. References to the cloud prototype jumped from eight occurrences in build 9275 to 31 in build 9922, with the newer build adding the selectable interface, legacy labels, and preference storage that make the prototype a more distinct service.
OpenAI's public Codex Cloud documentation still tells developers to connect a source repository, manually create an environment, and configure its dependencies, tools, variables, and secrets before starting a task. The code in build 9922 points to a new generation of that workflow, not a confirmed migration or shutdown.
Codex discusses the environment before drafting it
The new workflow begins with repository selection and a request to create a private environment. Its default network policy is restricted to package-manager access, while an onboarding flag tells the server to begin an environment-setup conversation. A server response can supply an environment ID, a conversation thread, and an onboarding skill. Codex then opens a dedicated "Cloud environment setup" thread rooted at /workspace and /tmp.
If the server does not provide an onboarding skill, the fallback instruction tells Codex to first ask what the developer wants to get running, discuss any required details, and wait for the response before setting up the environment. The exact questions are generated at runtime and do not appear in the client package.
The interface tells developers that Codex will explore the selected repositories and prepare a draft for review. Client states include "Preparing environment draft" and "Prepared environment draft," along with failure states. That review step gives the developer a checkpoint before accepting the proposed configuration.
Tailscale, network secrets, and cloud identity
Build 9922 includes controls for reusable Tailscale authentication keys. A Tailscale key could allow an OpenAI-managed Codex environment to join an approved private network rather than requiring the developer to expose internal services publicly. The interface validates the tskey-auth- prefix and provides controls for attaching, replacing, and removing a key. Tailscale warns that reusable authentication keys can be dangerous if stolen and recommends keeping them in a purpose-built secrets vault.
Network secrets use a different model. The proposed system keeps a secret value outside the environment and gives code a placeholder. A proxy substitutes the credential only when a request is sent to an approved HTTPS domain. The environment editor also controls allowed domains and HTTP methods. OpenAI's current cloud environment guide says conventional secrets are available only to setup scripts and are removed before the agent starts, with outbound traffic passing through an HTTP/HTTPS proxy.
The identity panel tells users that agents can access cloud resources without stored credentials. Azure configuration uses a Microsoft Entra tenant ID and application client ID, an OIDC setup intended to let a workload obtain short-lived access without storing long-lived Azure credentials in the environment. AWS accepts an IAM role ARN and region, while Google Cloud uses a workload identity provider and service-account email. The client labels both AWS and Google Cloud "Configuration only for now" and does not allow either to be attached to a cloud environment in the observed interface. Azure follows an attachment path, making it the furthest-developed cloud identity option visible in this build.
A different boundary from self-hosted runners
Anthropic already documents self-hosted environments for Claude Code, a capability in public beta for Team and Enterprise organizations. That system places session runners inside infrastructure operated by the customer while Anthropic retains its hosted control plane, session orchestration, and model inference. Coder also announced Claude Code support for Agent Relay on September 15th and said the integration was built with support from the Claude Code team.
The Codex code points to a different operating boundary: an OpenAI-managed environment that reaches approved private resources through Tailscale, proxy-delivered credentials, and workload identity. That managed model may simplify adoption compared with self-hosted runners, but gives customers less direct control over execution infrastructure.
Why this matters for IT and development leaders
If this ships, environment setup and access control become part of the coding agent itself, reducing the manual work required to deploy Codex against private repositories, networks, and cloud resources. Teams evaluating AI Agent Courses for internal upskilling should watch how managed versus self-hosted execution boundaries evolve. The trade-off is clear: faster onboarding against private infrastructure in exchange for trusting OpenAI with network keys, proxy-injected secrets, and agent-proposed configurations. For operations and security leads, the unanswered questions around key storage, node removal, and rotation controls will determine whether this model is viable for regulated environments.
Your membership also unlocks:
