Support remote `--cd` for `codex --remote` command

What issue are you seeing?

Human-readable setup:

• app-server is running on a remote Mac mini
• the codex --remote ... client is running on a separate MacBook
• the client can connect to the remote app-server normally
• the failure only happens when passing --cd with a path that exists on the remote machine but not on the local machine

codex --remote ... --cd <remote-path> fails with:

Error: No such file or directory (os error 2)

This happens even when the remote app-server is running and the same cwd is valid on the remote host.

I verified that the remote app-server itself accepts the exact same path over the websocket protocol via thread/start with cwd set, and returns that cwd in the response. That suggests the issue is in the stock CLI's --remote / --cd handling rather than app-server cwd support.

Environment:

• local client: codex-cli 0.117.0
• remote server: codex-cli 0.117.0
• local client machine: MacBook
• remote server machine: Mac mini
• local OS: macOS arm64
• remote OS: macOS arm64
• transport: websocket (codex app-server --listen ws://<REMOTE_HOST>:<PORT>)

What steps can reproduce the bug?

1. Start a remote app-server on a machine where a target project directory exists:

codex app-server --listen ws://<REMOTE_HOST>:<PORT>

1. From another machine, verify the server is reachable:

curl -fsS http://<REMOTE_HOST>:<PORT>/readyz >/dev/null && echo ready

1. Try to launch the TUI against that remote server with a remote-only working directory:

codex --remote ws://<REMOTE_HOST>:<PORT> --no-alt-screen --cd /path/on/remote/host/project 'say hello'

1. Observe the failure:

Error: No such file or directory (os error 2)

1. As a control, connect to the same app-server directly over websocket and send thread/start with the same cwd:

{
  "method": "thread/start",
  "id": 2,
  "params": {
    "model": "gpt-5.4",
    "cwd": "/path/on/remote/host/project",
    "approvalPolicy": "never"
  }
}

The server accepts it and returns:

{
  "accepted_cwd": "/path/on/remote/host/project",
  "thread_cwd": "/path/on/remote/host/project"
}

What is the expected behavior?

If --remote is being used, I would expect --cd to be forwarded as the remote thread/session cwd without requiring that path to exist on the local machine.

At minimum, if remote-only --cd is not intended to be supported, it would be helpful for the CLI/docs to state that explicitly.

Additional information

This seems consistent with the CLI validating --cd locally before sending anything to the remote app-server.

Relevant docs that appear to support the underlying behavior:

• CLI --cd: https://developers.openai.com/codex/cli/features/#tips-and-shortcuts
• App-server thread/start with cwd: https://developers.openai.com/codex/app-server/#start-or-resume-a-thread
• App-server lifecycle noting turn/start can override cwd: https://developers.openai.com/codex/app-server/#lifecycle-overview