What happened?
Codex Desktop Remote Connections can discover an SSH host from ~/.ssh/config, but enabling the connection fails during remote app-server bootstrap when the remote account's login shell is /bin/csh.
Normal SSH to the host succeeds, passwordless auth works, and the remote has both /bin/bash and /bin/sh installed. The remote codex app-server --help command also works when run manually. The failure appears to happen because the Desktop remote bootstrap is executed through the remote login shell and uses Bourne/bash-style syntax or -l flags that csh does not accept.
Sanitized log excerpt
[remote-connections/discovery] discovery_completed collectedAliasCount=1 ... resolvedConnectionCount=1
[WindowContext] [ssh-websocket-v0] selected app-server transport websocketUrl=ws://127.0.0.1:<local-port>/rpc
[AppServerTransportSshWebsocket] ssh_websocket_v0.ensure_remote_app_server_and_tunnel localPort=<local-port> remotePort=<remote-port> sshAlias=<redacted> sshHost=<redacted> sshPort=<redacted>
[AppServerConnection] app_server_connection.transport_connect_failed
errorMessage="Unmatched '''.
fi: Command not found.
Unknown option: `-l'
Usage: csh [ -bcdefilmnqstvVxX ] [ argument ... ]."
Environment
- Codex Desktop on Windows
- Codex app version observed in local install/logs:
26.422.2437.0
- Remote app-server version reported by logs:
0.124.0-alpha.2
- Remote host: Unix/Linux via SSH
- Remote login shell:
/bin/csh
/bin/bash and /bin/sh are available on the remote- SSH auth works normally outside Codex Desktop
- Host alias, hostname, user, and ports intentionally redacted
Expected behavior
Codex Desktop Remote Connections should either:
- bootstrap through a POSIX shell explicitly, e.g.
/bin/sh -lc ..., regardless of the account login shell;
- support
csh/tcsh login shells with compatible syntax; or
- expose a per-connection "remote bootstrap shell" setting, e.g.
/bin/bash, so users can keep their login shell as csh for existing remote workflows.
Why changing the login shell is not always viable
Some enterprise environments require csh/tcsh login shells for existing tool setup. In this environment the shell is managed by central account tooling and cannot be changed locally. Users may need to keep csh as the login shell while allowing Codex to use sh/bash only for its bootstrap.
What happened?
Codex Desktop Remote Connections can discover an SSH host from
~/.ssh/config, but enabling the connection fails during remote app-server bootstrap when the remote account's login shell is/bin/csh.Normal SSH to the host succeeds, passwordless auth works, and the remote has both
/bin/bashand/bin/shinstalled. The remotecodex app-server --helpcommand also works when run manually. The failure appears to happen because the Desktop remote bootstrap is executed through the remote login shell and uses Bourne/bash-style syntax or-lflags thatcshdoes not accept.Sanitized log excerpt
Environment
26.422.2437.00.124.0-alpha.2/bin/csh/bin/bashand/bin/share available on the remoteExpected behavior
Codex Desktop Remote Connections should either:
/bin/sh -lc ..., regardless of the account login shell;csh/tcshlogin shells with compatible syntax; or/bin/bash, so users can keep their login shell ascshfor existing remote workflows.Why changing the login shell is not always viable
Some enterprise environments require
csh/tcshlogin shells for existing tool setup. In this environment the shell is managed by central account tooling and cannot be changed locally. Users may need to keepcshas the login shell while allowing Codex to usesh/bashonly for its bootstrap.