OpenAI is preparing a new Codex Cloud with Tailscale and Azure workload identity

OpenAI's production Codex desktop build 9922 contains a feature-gated replacement Cloud path that separates the existing service as "Cloud (Legacy)" and adds agent-led environment setup with Tailscale, proxy-delivered network secrets and OpenID Connect cloud identities, according to a RuntimeWire reverse-engineering analysis of builds 9922 (26.915.31945) and 9275 (26.908.70816). RuntimeWire counted 31 occurrences of `cloudThreadPrototype` in build 9922 versus eight in build 9275, with the new runner and redesigned environment catalog held behind feature gate 375130565. Microsoft Azure appears further along than Amazon Web Services or Google Cloud in the client build, and OpenAI was not contacted before publication.

OpenAI is preparing a new Codex Cloud with Tailscale and Azure workload identity Desktop build 9922 separates "Cloud" from "Cloud Legacy " and wires an environment-drafting agent to private-network access, proxy-delivered secrets and cloud identities behind a feature gate. By Ryan Merket https://runtimewire.com/author/ryan-merket · Published RUNTIMEWIRE INVESTIGATION — Original analysis Original reporting by RuntimeWire, based on documents, reverse engineering, data analysis. Why it matters If shipped, this would make environment setup and access control part of the coding agent itself, reducing the work required to deploy Codex against private repositories, networks, and cloud resources. It also shifts more of the security boundary to OpenAI, requiring enterprises to trust its handling of reusable network keys, proxy-injected secrets, workload identities, and agent-proposed configurations. That managed model may simplify adoption compared with self-hosted runners, but gives customers less direct control over execution infrastructure. Reporting record Finding Production Codex desktop build 9922 contains a feature-gated replacement Cloud path that separates the existing service as “Cloud Legacy ” and adds agent-led environment setup with Tailscale, network-secret and cloud-identity controls. How we verified Methods: documents, reverse engineering, data analysis. Comparative analysis of production builds 9922 26.915.31945 and 9275 26.908.70816 , including new Cloud labels, feature gate 375130565, environment setup states and schemas, Tailscale configuration, proxy-delivered network secrets, and Azure, AWS and Google Cloud identity controls. RuntimeWire reverse-engineered and compared the client code and interface wiring in production builds 9922 and 9275, counted cloud-prototype references, and analyzed labels, feature gates, state handling, API schemas and configuration panels. Tested versions: production build 9922 26.915.31945 , production build 9275 26.908.70816 . Reproduction RuntimeWire partially reproduced the finding. Company response The company was not contacted before publication. I found evidence in OpenAI desktop build 9922 that the company is developing a new Codex Cloud service alongside its existing system. The unreleased path separates "Cloud" from "Cloud Legacy ," lets Codex conduct an onboarding conversation, inspect selected repositories and prepare an environment draft for developer review. The accompanying environment system includes reusable Tailscale authentication keys, proxy-delivered network secrets and OpenID Connect cloud identities. Microsoft Azure appears further along than Amazon Web Services or Google Cloud in this client build, although the client alone cannot establish whether any supporting backend is available. A parallel Codex Cloud path 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, while internal copy says the legacy label distinguishes existing cloud tasks from the new service. Both the runner and a redesigned environment catalog remain behind feature gate 375130565 . That code establishes active development, not public availability or launch timing. When the gate is enabled, Codex can start a cloud task without an active local or remote project and mark the conversation with prefillCloudThreadPrototype . The client also stores a local, cloud or remote execution preference for each account and project. Those connected interface states, preferences and server-response handlers point to a parallel product path rather than an isolated interface experiment. Some scaffolding predates this release. I counted eight occurrences of cloudThreadPrototype in production build 9275 and 31 in build 9922. The newer build adds the selectable interface, feature gate, legacy labels and preference storage that make the prototype a more distinct service. OpenAI's public Codex Cloud documentation https://learn.chatgpt.com/docs/cloud 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. The existing Codex Cloud service remains available, and I found nothing showing whether or when users would move to the new path. 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. I found client states labeled "Preparing environment draft" and "Prepared environment draft," along with failure states. That review step gives the developer a checkpoint before accepting the proposed configuration. OpenAI has already moved toward more automatic setup. In an earlier Codex upgrade announcement https://openai.com/index/introducing-upgrades-to-codex/ , the company said the agent could scan for common setup scripts, execute them and fetch dependencies through configurable internet access. The build 9922 workflow goes further by making the developer part of a conversation about the environment before Codex drafts it. 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, with separate handling for invalid or failed saves. Tailscale warns https://tailscale.com/docs/features/access-control/auth-keys that reusable authentication keys can be dangerous if stolen and recommends keeping them in a purpose-built secrets vault. Its documentation recommends ephemeral configuration for short-lived workloads. The client package does not reveal how OpenAI stores a submitted key, whether joined Codex nodes are marked ephemeral, how those nodes are removed, or what rotation and revocation controls OpenAI would provide. Those are unanswered implementation questions, not evidence of a vulnerability. 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 https://learn.chatgpt.com/docs/environments/cloud-environment says conventional secrets are available only to setup scripts and are removed before the agent starts. It also says outbound traffic passes through an HTTP/HTTPS proxy. Existing internet-access controls https://learn.chatgpt.com/docs/cloud/internet-access let administrators restrict domains and block write-capable request methods. Proxy-delivered network secrets would use those boundaries to support authenticated runtime requests without exposing the underlying credential directly to the agent or its subprocesses. The identity panel separately 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, although client code cannot prove that its backend is enabled. A different boundary from Claude's self-hosted runners Anthropic already documents self-hosted environments for Claude Code https://code.claude.com/docs/en/self-hosted-environments , 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. RuntimeWire previously examined how Claude Desktop configures that self-hosted path. Coder also announced Claude Code support for Agent Relay https://coder.com/blog/agent-relay-claude-code-agentic-development 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. The new service would let Codex help design the environment it runs in and connect that environment to approved private networks and cloud resources. The entire new Codex path remains behind feature gate 375130565 . Build 9922 shows a new Cloud service under active development alongside "Cloud Legacy ," but it does not establish launch timing, backend availability or a migration plan. AWS and Google Cloud remain configuration-only in the observed interface, Azure's attachment path still requires backend verification, and the existing Codex Cloud service continues to be available.