Windows codex --remote fails to start TUI against Linux app-server due to remote Linux path decoding (autogen selfreport from codex)

What version of Codex CLI is running?

codex-cli 0.128.0

What subscription do you have?

plus

Which model were you using?

gpt-5.5

What platform is your computer?

Failing client: Windows 11 Pro ARM64 10.0.28000, PROCESSOR_ARCHITECTURE=ARM64, RuntimeOSArchitecture=Arm64. Control client: Fedora Linux 42 under WSL 2 aarch64 succeeds against the same remote. Remote app-server: Rocky Linux 10 x86_64.

What terminal emulator and version are you using (if applicable)?

Failing client: PowerShell 7.6.1 on native Windows 11 ARM64, no tmux/screen/zellij. Control client: Fedora Linux 42 under WSL 2.

What issue are you seeing?

Native Windows codex --remote fails during TUI startup when connecting to a Linux codex app-server.

Command shape:

codex --remote wss://<host> --remote-auth-token-env CODEX_REMOTE_AUTH_TOKEN -C /home/<user>

Actual error:

Error: thread/start failed during TUI bootstrap

The same endpoint, auth token, codex-cli 0.128.0, and -C /home/<user> work from Fedora Linux 42 under WSL 2 on the same Windows ARM64 machine.

What steps can reproduce the bug?

1. Start codex app-server on Rocky Linux 10 x86_64 with codex-cli 0.128.0.

1. From native Windows 11 ARM64 with codex-cli 0.128.0, connect to it:

``powershell
codex --remote wss://<host> --remote-auth-token-env CODEX_REMOTE_AUTH_TOKEN -C /home/<user>
``

1. Native Windows client fails during TUI bootstrap:

``text
Error: thread/start failed during TUI bootstrap
``

1. From Fedora Linux 42 under WSL 2 on the same Windows machine, run the same remote session:

``bash
codex --remote "$CODEX_REMOTE_URL" --remote-auth-token-env CODEX_REMOTE_AUTH_TOKEN -C /home/<user> --no-alt-screen
``

1. The WSL client succeeds and reaches the normal Codex TUI screen.

I also reproduced the Windows failure with a fake local app-server:

• returning Linux paths such as /home/<user> in the thread/start response makes the native Windows TUI fail with the same bootstrap error
• returning Windows paths such as C:\Users\<user> lets the native Windows TUI pass bootstrap

What is the expected behavior?

Native Windows Codex CLI should be able to start a remote TUI session against a Linux codex app-server.

Remote Linux paths such as /home/<user> should be treated as server-side remote paths, not validated as local Windows filesystem paths.

Additional information

Likely root cause:

The app-server protocol returns remote Linux paths in fields typed as AbsolutePathBuf, for example ThreadStartResponse.cwd / Thread.cwd.

On Fedora WSL 2, /home/<user> is a valid absolute path, so bootstrap succeeds.

On native Windows, /home/<user> is not a valid local absolute path for std::path::PathBuf, so the Windows client appears to fail while decoding the thread/start response. The TUI only surfaces:

thread/start failed during TUI bootstrap

This does not appear to be a proxy, token, firewall, systemd, or server startup issue. Health checks, WebSocket upgrade, initialize, and manual JSON-RPC thread/start against the Linux app-server all succeed.