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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on May 1, 2026
2. github-actions commented on May 1, 2026

   

   github-actionsBot

   on May 1, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Codex App Remote SSH fails on macOS remote because bootstrap uses GNU-style chmod -- #20617

   Powered by Codex Action
3. HaroldHuanrongLIU commented on May 2, 2026

   

   HaroldHuanrongLIU

   on May 2, 2026

   More actions

   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).

   I meet this issue too. In my situation, I use codex desktop app on macos and connect my linux server with this app (both machines have installed codex-cli 0.128). I update the app to least version and the problem was resolved.
4. shrektan commented on May 2, 2026

   

   shrektan

   on May 2, 2026

   Author

   More actions

   @HaroldHuanrongLIU I think it has been fixed in the very latest Codex.app version. I updated it in the evening and it's perfectly fine now. I will close this issue for now.

   👍React with 👍2Reacted by HaroldHuanrongLIU and Zhihui Chen
5. shrektan

   closed this as completedon May 2, 2026