Hi, and welcome back.
I can confirm this is reproducible, and there is already a matching GitHub issue for it. You can also add your report there to help raise visibility and hopefully get it fixed sooner.
github.com/openai/codex
Support remote --cd for codex --remote command
opened 08:02PM - 28 Mar 26 UTC
AdithyanI
bug enhancement TUI
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: text 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: bash codex app-server --listen ws://<REMOTE_HOST>:<PORT> 2. From another machine, verify the server is reachable: bash curl -fsS http://<REMOTE_HOST>:<PORT>/readyz >/dev/null && echo ready 3. Try to launch the TUI against that remote server with a remote-only working directory: bash codex --remote ws://<REMOTE_HOST>:<PORT> --no-alt-screen --cd /path/on/remote/host/project 'say hello' 4. Observe the failure: text Error: No such file or directory (os error 2) 5. As a control, connect to the same app-server directly over websocket and send thread/start with the same cwd: json { "method": "thread/start", "id": 2, "params": { "model": "gpt-5.4", "cwd": "/path/on/remote/host/project", "approvalPolicy": "never" } } The server accepts it and returns: json { "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
Discussion in the ATmosphere