SSH remote: app-server bootstrap silently fails on macOS-to-macOS, leaving repeated WebSocket 1006 errors

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

26.429.20946 (Electron 41.2.0)

What subscription do you have?

Pro

What platform is your computer?

Local (Codex App): macOS 26.3.1, build 25D771280a (Apple Silicon)
Remote (SSH host): macOS 26.2, build 25C56
Remote codex --version: codex-cli 0.128.0

What issue are you seeing?

Connecting the Codex App to a macOS SSH remote host fails immediately with:

Error: Codex app-server websocket closed (code=1006)

This happens for every SSH host I have configured (all of them are aliases pointing to the same Mac mini), and it happens both with auto-connect and with manual "Connect" clicks. SSH itself works fine (ssh <alias> from the same machine succeeds in under a second using the same key).

The Codex App's bootstrap command appears to start, run mkdir -p and chmod against $CODEX_HOME/app-server-control, and then try to launch nohup codex app-server --listen unix://. The remote SSH session exits with status 0, but the listening socket at ~/.codex/app-server-control/app-server-control.sock is never created, so the subsequent codex app-server proxy from the App fails with:

Error: failed to connect to socket at /Users/<user>/.codex/app-server-control/app-server-control.sock

Caused by:
    No such file or directory (os error 2)

Notably, ~/.codex/app-server-control/app-server.log is also never created, suggesting the nohup codex app-server command in the bootstrap chain never actually executes.

Workaround

If I ssh into the remote host manually and run

codex app-server --listen unix://

inside a tmux session, the App connects instantly on the next attempt. So the codex CLI on the remote is fine, the PATH is fine, and the socket location is fine — only the App's automated bootstrap is broken on this combination.

Steps to reproduce

1. Local Mac running Codex App 26.429.20946 on macOS 26.3.1.
2. Remote Mac running codex-cli 0.128.0 on macOS 26.2, reachable via SSH using key auth.
3. Add the host to ~/.ssh/config with HostName, Port, User, IdentityFile.
4. In Codex App → Settings → Connections, add the SSH host and click Connect.
5. App immediately reports Codex app-server websocket closed (code=1006).

Relevant log excerpts (from ~/Library/Logs/com.openai.codex/...)

The bootstrap command Codex App sent over SSH:

exec /bin/sh -c 'umask 077;
  mkdir -p -- "${CODEX_HOME:-$HOME/.codex}/app-server-control" &&
  chmod 700 -- "${CODEX_HOME:-$HOME/.codex}/app-server-control" &&
  nohup codex app-server --listen unix:// >"${CODEX_HOME:-$HOME/.codex}/app-server-control/app-server.log" 2>&1 &'

stderr from the bootstrap step (first attempt, txymini host):

debug1: Sending command: ... 'codex app-server proxy'
Error: failed to connect to socket at /Users/<user>/.codex/app-server-control/app-server-control.sock

Caused by:
    No such file or directory (os error 2)
debug1: Exit status 1

stderr from the bootstrap step (macmini-frp host, same Mac mini, different alias):

chmod: --: No such file or directory
debug1: Exit status 0

The exit status from the bootstrap shell is 0 (because the command ends with & and the shell only checks the background spawn), but nohup codex app-server was never actually started. Next, codex app-server proxy runs and fails because no socket exists.

App-side error:

[AppServerConnection] app_server_connection.closed code=1006 connectionId=N hasReason=false reason="" signal=null transport=websocket
[AppServerConnection] app_server_connection.state_changed cause=transport_closed
  closeCode=1006 connectionError={"code":"connection-failed","message":"socket hang up"}
[AppServerTransportSshWebsocket] ssh_websocket_v0.proxy_command_failed code=1 operation=app_server_proxy

Expected behavior

The bootstrap command should reliably start codex app-server --listen unix:// on a macOS remote, or fail loudly with a descriptive error instead of silently producing exit 0 + no socket.

Suspected root causes

A few possibilities, in order of suspicion:

1. The & at the end of the bootstrap command makes the shell return 0 even when the launched process never actually starts (or starts and exits immediately). There's no verification that app-server-control.sock was created before app-server proxy is invoked.
2. nohup codex app-server may exit immediately if the login-interactive remote shell's stdin/stdout aren't connected the way it expects, but because of & and nohup, the failure is swallowed.
3. chmod: --: No such file or directory on the macmini-frp alias path is suspicious. I have not been able to reproduce this in a plain SSH session on the same host with the same command, so it may be an artifact of how the App's SSH session is invoked. Either way, when chmod fails the &&-chain stops before nohup codex app-server is reached, but the shell still returns 0 on the trailing &.

Suggested fix

After running the bootstrap command, the App should poll for the socket file (with a short timeout, e.g. 2-3 seconds) before invoking app-server proxy. If the socket isn't created, surface the bootstrap log contents (app-server.log) instead of a generic 1006.

Additional notes

• Multiple SSH aliases point at the same physical Mac mini. All of them fail identically.
• Restarting the remote machine does not help.
• A previous Codex App version (before the recent update) connected fine with the same SSH config and the same remote machine.
• ~/.zshrc / ~/.zprofile on the remote do not modify stdout, do not run exec, and codex resolves correctly under a login interactive shell (ssh txymini "$SHELL -l -i -c 'which codex'" returns the expected path).