Allow the new ChatGPT Desktop App to attach to multiple existing Codex CLI and VS Code extension instances

Feature request

Allow the new ChatGPT desktop app (the app absorbing Codex app functionality) to connect to and manage multiple already-running Codex instances, including Codex CLI sessions and Codex VS Code extension sessions running inside devcontainers.

The underlying abstraction should ideally be a connection to an existing Codex app-server or session endpoint, rather than a feature tied specifically to SSH, Docker, or any one editor.

Primary use case: VS Code devcontainers

Devcontainers running the Codex VS Code extension offer a particularly useful combination:

• Filesystem isolation: Codex sees only the repository and mounts intentionally exposed to the container, providing an additional and understandable security boundary.
• Environment standardization: Toolchains, dependencies, environment variables, and system packages are reproducible and project-specific.
• Developer ergonomics: Developers retain the normal VS Code workflow, including full file visibility, language tooling, terminals, debugging, diffs, and extensions.
• Parallel work: Multiple repositories or worktrees can run in separate containers with independent Codex sessions.

Today, those advantages come with fragmentation: each containerized VS Code window or CLI process has its own Codex UI and session context. The ChatGPT desktop app would be much more useful as a unified control surface for all of them. The mobile app’s Remote Control functionality provides a useful preview of this kind of workflow.

Desired topology

ChatGPT desktop app
├── devcontainer A: VS Code extension session
├── devcontainer B: VS Code extension session
├── devcontainer C: Codex CLI session
└── local Codex CLI session

The app should be able to:

• Discover or manually register multiple Codex endpoints.
• Display active and resumable sessions from each endpoint.
• Identify sessions by host, container, workspace, repository, and worktree.
• Open, monitor, steer, and approve actions for an existing session.
• Reconnect after the app, VS Code, or a container restarts.
• Preserve the filesystem, process environment, sandbox, and tool context of the originating instance.
• Avoid spawning a duplicate Codex process or creating a parallel session.
• Support multiple simultaneous connections.

The transport should vary by environment—for example, Unix sockets, forwarded TCP, SSH, or an account-mediated encrypted connection.

Why attaching to existing instances matters

Opening a remote folder and starting a new Codex process is useful, but it is not equivalent to attaching to an existing session.

The existing VS Code extension or CLI session may already have:

• An active conversation.
• Editor selections and IDE context.
• A configured devcontainer environment.
• Project-local tools and extensions.
• Approval or sandbox state.
• Running commands and task progress.

The app should attach to that session in place rather than recreate an approximation of it elsewhere.

Why devcontainers are a compelling target

Although the connection model should remain transport-agnostic, devcontainers are a strong first-class use case.

They combine reproducible project environments with a deliberately constrained filesystem view while preserving the everyday ergonomics of VS Code. They also make it practical to run several independent Codex environments concurrently without sharing dependency state or broadly exposing the host filesystem.

Containers are not automatically a hard security boundary; their isolation depends on configured mounts, privileges, credentials, sockets, and host integrations. However, a properly configured devcontainer provides a useful additional layer of isolation alongside Codex’s own permission sandbox.

I have found this workflow especially effective with the Claude Code VS Code extension and would like to use the same model with Codex.

Relationship to existing requests

This appears related to:

• #27565, which proposes Claude Code-like Remote Control with CLI, mobile, and desktop clients connecting to the same app-server session.
• #33750, which asks for SSH and account-based Remote Control clients to share one existing app-server.
• #21974, which asks the desktop app to live-refresh sessions being run by a standalone local CLI process.
• #21079, which asks the desktop app to expose Codex CLI sessions as first-class threads.
• #21509, which requests first-class SSH remote workspaces in the Codex App.
• #31187, which requests multi-machine Remote Control connections.

There is also evidence in #35248 that account-based Remote Control can already expose sessions hosted by a Codex CLI/app-server on Linux to the mobile app.

These issues cover individual parts of the desired workflow: endpoint connectivity, shared app-server access, session discovery, live synchronization, remote workspaces, and multiple hosts. I could not find one focused on using the desktop app as a unified control surface for multiple already-running Codex CLI and VS Code extension instances, particularly instances hosted in separate devcontainers.

Suggested model

Treat a Codex runtime as a connectable endpoint with a stable identity and advertised capabilities.

Desktop, mobile, CLI, and IDE clients could attach to the same endpoint and session through different transports without taking ownership of its lifecycle.

This would make devcontainers, SSH hosts, VMs, WSL environments, and local processes variations of the same connection model rather than separate product features.