Summary
Codex Desktop's managed SSH remote connection can connect to a different user's already-running codex app-server on a shared remote host.
The SSH login itself is correct, but the Desktop app starts the remote app-server on fixed remote port 127.0.0.1:9234. If another user already owns that port, the new app-server startup fails with Address in use, while the SSH tunnel still forwards to 127.0.0.1:9234. The Desktop app then talks to the other user's app-server and displays that user's Codex home/config state.
Impact
This can expose or operate on the wrong user's remote Codex app-server state on shared systems.
In the observed case, the Desktop configuration screen offered to import external agent config from another user's home directory. The SSH target was the intended account, but the app-server behind the tunnel reported a different user's Codex home.
Reproduction Outline
-
On a shared remote Linux host, have user A already running:
codex app-server --listen ws://127.0.0.1:9234
-
From Codex Desktop, create/connect a managed SSH remote as user B to the same host.
-
Codex Desktop runs a remote bootstrap command equivalent to:
nohup codex app-server --listen ws://127.0.0.1:9234 >/tmp/codex-app-server-ssh-ws-v0.log 2>&1 &
-
User B's app-server fails to bind because the port is already in use.
-
Codex Desktop still creates a local SSH tunnel to remote 127.0.0.1:9234.
-
Desktop RPC calls then reach user A's app-server, not user B's.
Observed Evidence
- Direct SSH to the remote reports the expected user and home directory.
- Remote
127.0.0.1:9234 is already listening and owned by a different user.
- The remote bootstrap log contains:
Error: Address in use (os error 98)
- The app-server reached through the Desktop SSH tunnel reports the other user's
codexHome.
- The Desktop configuration screen shows external-agent import paths under the other user's home directory.
Expected Behavior
Codex Desktop should never silently connect to an app-server owned by a different remote user.
At minimum, it should detect that the remote app-server failed to bind and fail the connection instead of tunneling to the occupied port.
Preferably, managed SSH remotes should use a per-user or otherwise collision-resistant remote app-server port/socket, or verify after connection that the app-server identity/home matches the SSH login.
Notes
The issue appears to be caused by the managed SSH transport using fixed remote port 9234 for the app-server and not validating that the process behind the tunnel was the one just started for the current SSH user.
Summary
Codex Desktop's managed SSH remote connection can connect to a different user's already-running
codex app-serveron a shared remote host.The SSH login itself is correct, but the Desktop app starts the remote app-server on fixed remote port
127.0.0.1:9234. If another user already owns that port, the new app-server startup fails withAddress in use, while the SSH tunnel still forwards to127.0.0.1:9234. The Desktop app then talks to the other user's app-server and displays that user's Codex home/config state.Impact
This can expose or operate on the wrong user's remote Codex app-server state on shared systems.
In the observed case, the Desktop configuration screen offered to import external agent config from another user's home directory. The SSH target was the intended account, but the app-server behind the tunnel reported a different user's Codex home.
Reproduction Outline
On a shared remote Linux host, have user A already running:
codex app-server --listen ws://127.0.0.1:9234From Codex Desktop, create/connect a managed SSH remote as user B to the same host.
Codex Desktop runs a remote bootstrap command equivalent to:
nohup codex app-server --listen ws://127.0.0.1:9234 >/tmp/codex-app-server-ssh-ws-v0.log 2>&1 &User B's app-server fails to bind because the port is already in use.
Codex Desktop still creates a local SSH tunnel to remote
127.0.0.1:9234.Desktop RPC calls then reach user A's app-server, not user B's.
Observed Evidence
127.0.0.1:9234is already listening and owned by a different user.Error: Address in use (os error 98)codexHome.Expected Behavior
Codex Desktop should never silently connect to an app-server owned by a different remote user.
At minimum, it should detect that the remote app-server failed to bind and fail the connection instead of tunneling to the occupied port.
Preferably, managed SSH remotes should use a per-user or otherwise collision-resistant remote app-server port/socket, or verify after connection that the app-server identity/home matches the SSH login.
Notes
The issue appears to be caused by the managed SSH transport using fixed remote port
9234for the app-server and not validating that the process behind the tunnel was the one just started for the current SSH user.