First-party Codex integration for Microsoft Visual Studio and remote targets

[baXTer-stOkMan]

What variant of Codex are you using?

CLI, IDE Extension

What feature would you like to see?

outputs/codex-vscode-remote-zero-egress-feature-request.md

Feature request: VS Code Remote-SSH with a local Codex broker for zero-egress remote hosts

One-sentence request

Allow the Codex VS Code extension to keep authentication and all OpenAI HTTPS/WebSocket traffic on the managed laptop while reading files and running tools on an isolated VS Code remote host through the existing authenticated Remote-SSH connection.

Enterprise scenario

This is a common enterprise development topology, not an offline-mode request:

Managed laptop                         Isolated development host
┌──────────────────────────────┐       ┌──────────────────────────────┐
│ VS Code + Codex UI           │  SSH  │ Repository and filesystem    │
│ Codex authentication         │◄─────►│ Git, shell, builds, tests    │
│ Enterprise proxy / Prisma    │       │ Minimal execution worker     │
│ Approved OpenAI connectivity │       │ No public internet or token  │
└──────────────┬───────────────┘       └──────────────────────────────┘
               │
               ▼
        OpenAI/Codex services

• Source code and development tools are permitted only on the remote host.
• The employee laptop is the approved, inspected internet boundary.
• The laptop can reach Codex through enterprise endpoint controls.
• The remote host intentionally has no route to OpenAI or the public internet.
• Codex account credentials must not be copied to the remote host.

Today, the Codex extension normally launches its CLI/app-server in the VS Code remote extension host. This makes the remote host responsible for Codex authentication and model connectivity, which defeats the enterprise network boundary.

Why existing support does not solve it

This request is not ordinary HTTP proxy support.

A reverse-forwarded proxy can sometimes give the remote process an outbound route, but the remote Codex process still owns credentials and originates model requests. It also depends on proxy variables, certificate handling, WebSocket behavior, and extension-host environment propagation.

The current Remote Connections documentation similarly instructs users to install and authenticate Codex on the remote host and starts the remote Codex app-server through SSH. That is useful remote execution support, but it does not support a zero-egress remote host with authentication retained exclusively on the laptop.

The closest existing reports demonstrate pieces of the problem:

• #2987: VS Code Remote-SSH extension stuck on "Thinking" used SSH reverse-port forwarding to a local proxy. Forcing the extension to run locally restored model access but lost access to the remote filesystem.
• #2939: VS Code extension ignores proxy settings addressed general proxy behavior, not separation of local authentication from remote execution.
• #27597: IDE extension fails in Remote-SSH while the CLI works tracks a current Remote-SSH extension failure.
• #29138: Remote app-server loses proxy environment illustrates the fragility of making a remote app-server depend on proxy environment propagation.

This request fills the missing architectural gap between “run everything locally” and “run and authenticate Codex on the remote host.”

Requested behavior

For VS Code Remote-SSH—and ideally Dev Containers, WSL, Codespaces, and Tunnels—provide a supported split execution mode:

Local control plane

• Run the Codex UI, model client, authentication, and session management on the managed laptop.
• Originate OpenAI HTTPS and WebSocket connections from the laptop.
• Honor the laptop’s enterprise proxy, certificates, device identity, DLP, and endpoint policy.
• Keep reusable Codex credentials off the remote host.

Remote execution plane

• Use VS Code’s authenticated remote channel, SSH stdio, or a similarly protected transport.
• Read, search, and edit files in the active remote workspace.
• Run shell commands, Git operations, builds, tests, and development tools remotely.
• Return structured results, diffs, diagnostics, and approvals to the local extension.
• Terminate the worker when the VS Code remote session ends.
• Open no inbound or unauthenticated network listener.

The implementation could use a local Codex app-server paired with a minimal remote filesystem/tool worker. The exact protocol is less important than making the local-network/remote-execution split a supported product mode.

Suggested user experience

{
  "chatgpt.remoteExecution.networkMode": "local-broker",
  "chatgpt.remoteExecution.credentials": "local-only"
}

When Codex detects a remote workspace, it could offer:

Run Codex network and authentication locally while executing workspace operations on the remote host.

The UI should clearly show:

• Model connection: Local laptop
• Workspace execution: Remote-SSH host
• Credentials on remote host: No
• Remote public-internet requirement: No

Security and administration requirements

• No Codex access token, refresh token, session cookie, or reusable account credential is persisted remotely.
• OpenAI traffic originates only from the managed endpoint.
• The remote worker accepts requests only over the existing authenticated VS Code/SSH transport.
• Existing Codex approval, sandbox, and workspace-trust controls still apply.
• Administrators can require, disable, or centrally configure this mode.
• Commands, file changes, connection identity, and execution target are auditable.
• Disconnecting the IDE terminates or invalidates the remote worker.
• Repository content continues to follow the organization’s configured Codex data controls.

Acceptance criteria

1. Connect VS Code on a managed Windows or macOS laptop to a Linux host using Remote-SSH.
2. Block all public-internet and OpenAI access from the Linux host.
3. Allow the laptop to reach Codex through its managed enterprise network path.
4. Authenticate Codex only on the laptop.
5. Open a repository that exists only on the remote host.
6. Use the Codex sidebar to search and edit remote files, inspect Git state, run commands, execute tests, and display diffs.
7. Confirm that no reusable Codex credential is written to the remote host.
8. Confirm by network logging that OpenAI HTTPS/WebSocket traffic originates only from the laptop.
9. Disconnect VS Code and confirm that the remote worker terminates without leaving a public listener.

Business impact

Many regulated enterprises prohibit source code and toolchains on employee laptops. Developers use managed endpoints as secure interfaces to segmented development environments.

Requiring each remote environment to reach OpenAI creates firewall exceptions, credential-distribution concerns, certificate and proxy dependencies, and additional security reviews. In zero-egress environments it makes Codex adoption impossible even though the managed laptop is already approved to use Codex.

A supported local-control-plane/remote-execution-plane mode would allow Codex adoption without weakening network segmentation or moving repositories onto employee endpoints. This is similar in outcome to enterprise remote-development workflows supported by tools such as Amazon Q Developer.

Non-goals

• This does not request that Codex run without any OpenAI connectivity.
• This does not request an unauthenticated proxy or an internet-facing remote daemon.
• This does not require source code to be mirrored onto the laptop.
• This does not replace existing fully remote Codex operation for hosts that are allowed direct egress.

Additional information

No response

[github-actions]

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

• VS Code Remote-SSH with a local Codex broker for zero-egress remote hosts #35795

Powered by Codex Action

[baXTer-stOkMan]

35796 and 35795 are slightly different. One is vscode and the other is Visual Studio. The reason it was done this way is to not assume the functionality is the same on both dev paths.