{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreie7xq335su7ugdsedvrjavr5n555lr6qn6zq4bf6abvqfanijqgdy",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3milr373nj632"
  },
  "path": "/t/codex-cli-cd-ignored-when-connecting-to-codex-app-server/1378429#post_2",
  "publishedAt": "2026-04-03T11:51:36.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "github.com/openai/codex",
    "Support remote `--cd` for `codex --remote` command",
    "AdithyanI"
  ],
  "textContent": "Hi, and welcome back.\n\nI 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.\n\ngithub.com/openai/codex\n\n####  Support remote `--cd` for `codex --remote` command\n\nopened 08:02PM - 28 Mar 26 UTC\n\n\n\n          AdithyanI\n        \n\nbug  enhancement  TUI\n\n### 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",
  "title": "Codex CLI --cd ignored when connecting to Codex app server"
}