Summary
railway ssh returns exit code 0, but the requested non-interactive remote command does not appear to execute. The same occurs when a script is provided on stdin. The CLI reports success even though the expected sentinel is absent, so callers cannot distinguish this from a successful remote execution.
Environment
- Railway CLI:
5.30.1 (also confirmed as the current npm version at the time of testing)
- Client: macOS arm64, system OpenSSH
- Target container: Ubuntu Noble-based Playwright image with
/bin/sh in the base image contract
- Dashboard-generated command shape:
railway ssh --project <redacted> --environment <redacted> --service <redacted>
- All project, environment, service, deployment, account, and key identifiers are intentionally omitted
Reproduction contracts
I tested two separate read-only contracts against the active deployment:
- A single remote command that prints a unique fixed sentinel.
sh -s with a versioned read-only script supplied on stdin; the script prints a start sentinel, versioned JSON, and a completion sentinel.
Before the production checks, I used a no-network PATH shim in place of system ssh to inspect only the CLI local argv/stdin behavior. That isolated check showed the CLI invoking the SSH boundary with the expected non-PTY target/remote-command shape and forwarding the complete stdin payload. Ten shim cases and sixteen assertions passed.
Expected behavior
- The requested command executes inside the selected deployment.
- stdout contains the unique sentinel (or the versioned JSON/sentinels for
sh -s).
- The CLI propagates the remote exit status.
Actual behavior
For both production contracts:
- CLI exit code:
0
- stdout:
3234 bytes, one line
- stderr:
0 bytes
- expected start sentinel count:
0
- expected versioned JSON count:
0
- expected completion sentinel count:
0
- remote exit status: not observable
The raw stdout is not included because it may contain platform-generated connection material. No secret or environment variable was requested or read. Temporary SSH keys were removed after each bounded test, and I am not repeating production attempts while the boundary remains uncertified.
Additional observation
The dashboard Copy SSH Command currently produces the same railway ssh --project ... --environment ... --service ... path used above; it does not expose a distinct direct SSH target that could be tested as an alternative.
Question
Could the Railway relay/exec boundary be acknowledging the SSH session while dropping the remote command and stdin, or returning platform output with exit 0 before the target container shell is invoked? Is there a supported direct target or diagnostic that can authenticate that the remote command actually reached the selected deployment?
Summary
railway sshreturns exit code 0, but the requested non-interactive remote command does not appear to execute. The same occurs when a script is provided on stdin. The CLI reports success even though the expected sentinel is absent, so callers cannot distinguish this from a successful remote execution.Environment
5.30.1(also confirmed as the current npm version at the time of testing)/bin/shin the base image contractrailway ssh --project <redacted> --environment <redacted> --service <redacted>Reproduction contracts
I tested two separate read-only contracts against the active deployment:
sh -swith a versioned read-only script supplied on stdin; the script prints a start sentinel, versioned JSON, and a completion sentinel.Before the production checks, I used a no-network PATH shim in place of system
sshto inspect only the CLI local argv/stdin behavior. That isolated check showed the CLI invoking the SSH boundary with the expected non-PTY target/remote-command shape and forwarding the complete stdin payload. Ten shim cases and sixteen assertions passed.Expected behavior
sh -s).Actual behavior
For both production contracts:
03234bytes, one line0bytes000The raw stdout is not included because it may contain platform-generated connection material. No secret or environment variable was requested or read. Temporary SSH keys were removed after each bounded test, and I am not repeating production attempts while the boundary remains uncertified.
Additional observation
The dashboard Copy SSH Command currently produces the same
railway ssh --project ... --environment ... --service ...path used above; it does not expose a distinct direct SSH target that could be tested as an alternative.Question
Could the Railway relay/exec boundary be acknowledging the SSH session while dropping the remote command and stdin, or returning platform output with exit 0 before the target container shell is invoked? Is there a supported direct target or diagnostic that can authenticate that the remote command actually reached the selected deployment?