Codex App on Windows: stale managed SSH host state breaks unrelated Remote SSH connections; manual proxy succeeds but app fails with socket hang up

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

26.609.9530.0

Also reproduced on 26.609.4994.0 before reinstall.

What subscription do you have?

ChatGPT paid plan with Codex desktop access.

What platform is your computer?

Windows 11 x64 (10.0.22000)

OpenSSH client on the Windows side:

OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2

What issue are you seeing?

Codex App on Windows fails to establish Remote SSH app-server connections to otherwise healthy Linux targets with socket hang up, even though the exact same SSH path and remote Codex bootstrap work outside the app.

The strongest signal is that stale internal state for a previously known managed SSH host appears to poison unrelated Remote SSH targets.

Representative app log lines:

Failed to load config requirements errorMessage="No AppServerRequestClient registered for hostId: remote-ssh-codex-managed:<redacted>"
Failed to load experimental features error="Error: No AppServerManager registered for hostId: remote-ssh-codex-managed:<redacted>"

For the failing Linux hosts, the app consistently gets through the early probes and then fails later during transport setup:

codex_path_probe
codex_version_probe
app_server_bootstrap
proxy_command_starting
app_server_connection.transport_connect_failed errorCode=ECONNRESET errorMessage="socket hang up"

This is not explained by basic SSH/auth/Codex availability on the remote side:

• SSH login succeeds outside the app
• codex --version succeeds on the remote hosts
• codex app-server proxy --sock ... starts successfully on the remote hosts
• a manual WebSocket Upgrade test over the same Windows ssh.exe path returns HTTP/1.1 101 Switching Protocols
• the manually started proxy stream stays alive

So the failure appears to be inside the Windows app’s Remote SSH/session-management layer, not in the remote machine configuration.

What steps can reproduce the bug?

1. Use Codex App on Windows with Remote SSH enabled.
2. Have at least one previously registered/managed SSH host that is now stale or internally broken.
3. Connect to a different healthy Linux host over SSH from the app.
4. Observe that Codex App passes path/version/bootstrap probes, then fails with socket hang up while bringing up the app-server transport.
5. In parallel, run the equivalent SSH and remote Codex commands manually outside the app; they succeed.

I reproduced this against multiple Linux targets:

• Host A: Linux x86_64 over Tailscale SSH
• Host B: Linux aarch64 over Tailscale SSH

Both had working Codex CLI installations and both were reachable and functional outside the app.

I also reproduced after:

• uninstalling/reinstalling the Codex App
• deleting local Codex app data/cache/session state on Windows
• revalidating SSH keys and remote Codex availability

What is the expected behavior?

A stale/broken managed-host entry should not affect unrelated healthy Remote SSH targets.

If the app can successfully complete:

• SSH auth
• remote path probe
• remote version probe
• remote app-server bootstrap

then it should either:

• complete the transport connection successfully, or
• fail with a target-specific actionable error

but it should not abort with a generic socket hang up while manual proxy/WebSocket setup over the same path works.

Additional information

Sanitized environment summary:

• Local client: Windows 11 x64, locale ko-KR
• Remote targets: Linux x86_64 and Linux aarch64
• Remote Codex CLI: 0.140.0
• SSH username handling is slightly constrained by the Windows app UX, but the same effective login path still works outside the app and had worked in-app previously

This looks related to, but not identical to:

• #18974 (stale SSH host state)
• #26757 (Remote SSH app-server/proxy connection failures after probes succeed)

What seems distinct here is that:

1. the stale state references a managed host that is not the current target, and
2. manual end-to-end validation of the proxy/WebSocket path succeeds, while the app still resets the connection internally.

If useful, I can provide a sanitized sequence of timestamps/log events showing the exact transition from successful bootstrap to ECONNRESET during proxy_command_starting.