Connecting local Codex to a remote development environment: Which project directory is authoritative?

Sharing connectivity does not copy project directories

The former codex-remote-bridge URL now redirects to codex-remote-Skill. Its README defines the purpose as letting server-side Codex CLI use a local HTTP proxy or network connection. It does not upload a local project into a remote workspace or merge conversations from two clients. Before editing, identify where the project files actually reside.

In the intended terminal, inspect pwd, git status --short --branch, and git rev-parse HEAD. HEAD identifies a commit, while the status reveals uncommitted changes. Matching commits on two machines do not prove that their current files match. Project transfer or synchronization needs a separate, explicit method; it cannot be inferred from a proxy tunnel.

pwd
git status --short --branch
git rev-parse HEAD

A reverse forward listens on the server

OpenSSH’s -R option creates a remote listener and carries its connections back to the specified local destination. The project maps server-side 127.0.0.1:17891 to a local HTTP port: 11450 for its direct-network forwarder, or the actual HTTP/mixed port of existing proxy software. These example ports are configuration values, not services automatically present on every machine.

An open SSH window only shows that the tunnel process remains running. ExitOnForwardFailure checks whether forwarding listeners were established; it does not verify the local proxy or final service. Retain host-key checking and confirm that the listener is bound to loopback. Other users on the same server may still reach that loopback port.

The launched process must receive proxy settings

The repository’s codex_with_proxy.py reads only allowed proxy variables and launches Codex with the updated environment, without executing arbitrary shell content from the environment file. Its --check option validates configuration format and explicitly does not test connectivity. Writing a new proxy address does not automatically change an already running process.

Separate a listening proxy from a response by the target service. An HTTP CONNECT success establishes tunnel negotiation, not the origin of later responses. Login and model requests have additional conditions; one curl response does not establish that Codex can complete a development task. We did not run these checks on a real server.

Start with an isolated server-side sample

After connectivity is established, a temporary server-side sample project can be used for a read-only request that reports the current directory and visible files. Confirm that the intended directory is being read before requesting edits, then check results with the project’s own tests. Seeing code in a local editor does not establish that the remote CLI has read the same file.

This article explains execution location from the current documentation and launcher source. We transferred no login credentials and performed no end-to-end GPU-server test. When stopping, follow the project’s instructions to close the tunnel and restore the proxy configuration saved before the change. Project files and running training jobs are outside proxy-configuration cleanup.