Windows Codex App remote connections fail when the remote machine's 127.0.0.1:9234 is already in use

What version of the Codex App are you using (From “About Codex” dialog)?

26.415.4716.0

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex App remote SSH fails against a shared enterprise Linux development host when the remote loopback port 127.0.0.1:9234 is already occupied by another process.

In my case, connecting to the remote host from the Windows Codex App consistently fails with:

parse Error: Expected HTTP/, RTSP/ or ICE

The SSH path itself is valid:

• the host is reachable
• the SSH alias / jump host setup works
• the host is only resolvable from inside the enterprise network / jump path, and SSH still reaches it correctly
• the same remote machine works fine with normal SSH usage
• the same remote machine also works with VS Code Remote-SSH + the Codex extension

The failure appears specific to the Codex App remote-SSH path.

On the remote machine, 127.0.0.1:9234 is already listening before Codex App connects. This is normal in a multi-user shared development environment. When Codex App tries to establish the remote connection, the bootstrap step fails because the expected remote app-server cannot bind that port, and the forwarded connection appears to hit the wrong local service instead of the expected Codex endpoint.

This makes remote development in Codex App unreliable or impossible on shared Linux hosts, which are common in enterprise environments.

What steps can reproduce the bug?

1. Use the Windows Codex App.
2. Configure a remote SSH connection to a shared Linux development machine.
3. Ensure that some process on the remote host is already listening on 127.0.0.1:9234.
4. In Codex App, try to create or open a remote project over SSH.
5. Observe that the connection fails, often with:

• parse Error: Expected HTTP/, RTSP/ or ICE

1. On the remote host, checking the port shows that 127.0.0.1:9234 was already in use before the attempt.

This is especially easy to reproduce on shared enterprise machines where multiple users and background services coexist on the same host.

What is the expected behavior?

Codex App remote SSH should not hard-fail just because a fixed remote loopback port is already in use.

Any of the following would solve the problem:

• automatically choose a free remote loopback port
• allow the user to configure the remote app-server port
• store a per-connection remote app-server port in connection settings or connection metadata
• at minimum, surface a clear error saying that the remote app-server port is already in use

Today, the behavior is brittle on shared hosts because one occupied port can break remote development entirely.

Additional information

Shared Linux development hosts are also a common option in enterprise environments, so this does not seem like a niche setup.

It would be very helpful if Codex App could support either:

1. dynamic free-port selection for the remote app-server, or
2. an explicit per-connection setting for the remote app-server port

If this is made configurable, the most natural place seems to be on the local Codex App side, for example:

• a per-connection advanced setting in the Connections UI, or
• a local config.toml default / override

That seems like a better fit than requiring users to manage this in remote ~/.codex files, because this is really a client-side remote-connection transport setting.

Also, improving the user-facing error would help a lot. The current parse error does not make it obvious that the real root cause is a remote port collision on the shared host.