railway login --browserless exits silently in TTY on Linux

[bntvllnt]

Summary

railway login --browserless exits with code 1 without printing a browserless login URL when run inside a TTY on a Linux VPS.

The non-TTY behavior appears correct: it prints Browserless login requires an interactive terminal. For non-interactive environments, set RAILWAY_API_TOKEN or RAILWAY_TOKEN.

Environment

• Railway CLI: railway 4.66.1
• Binary path: /home/ubuntu/.nvm/versions/node/v24.13.0/bin/railway
• Node: v24.13.0
• OS: Linux vps-fe31c5f8 6.17.0-40-generic #40-Ubuntu SMP PREEMPT_DYNAMIC Fri Jun 19 16:42:13 UTC 2026 x86_64 GNU/Linux
• Shell: zsh
• Host type: headless VPS

Reproduction

railway --version
railway login --browserless

Non-TTY output:

Browserless login requires an interactive terminal. For non-interactive environments, set RAILWAY_API_TOKEN or RAILWAY_TOKEN.
exit:1

TTY/PTY output using script:

script -q -e -c 'railway login --browserless' /tmp/railway-browserless.typescript
echo $?
sed -n '1,120p' /tmp/railway-browserless.typescript

Captured output:

exit:1
Script started on 2026-07-06 16:15:00+02:00 [COMMAND="railway login --browserless" <not executed on terminal>]

Script done on 2026-07-06 16:15:01+02:00 [COMMAND_EXIT_CODE="1"]

RAILWAY_DEBUG=1 produced the same silent exit. Running in an agent-provided TTY also returned exit code 1 with no output.

Expected behavior

Inside a TTY, railway login --browserless should print the browserless login URL/code flow, or print an actionable error explaining why it cannot start the browserless flow.

Actual behavior

Inside a TTY/PTY, the command exits 1 silently. This blocks Railway MCP/local CLI auth on headless hosts where normal browser login is not available.

Workaround

Use RAILWAY_API_TOKEN / RAILWAY_TOKEN for non-interactive commands, or authenticate from another environment.

[m-abdelwahab]

Hey! Does the issue happen on the latest CLI version? You can run railway upgrade to upgrade

[bntvllnt]

Update after deeper investigation: the root cause is not TTY detection — it's the npm distribution channel. Two stacked defects:

1. The x86_64-unknown-linux-gnu release binary segfaults on its first TLS handshake

On the affected host class (QEMU "Haswell" vCPU — a common generic VPS profile — with glibc 2.42), the linux-gnu binary dies with a general protection fault inside vendored crypto during the TLS key exchange:

traps: tokio-runtime-w[…] general protection fault ip:…22e sp:… error:0 in railway[9cd22e,…]

The faulting instruction (same offset on every crash) is an SSE movaps on a stack address misaligned by 8, inside a constant-time ECC table-select loop (ring 0.17.14):

9cd22e:  0f 28 94 24 98 00 00 00   movaps 0x98(%rsp),%xmm2   ; requires 16-byte alignment

Because the key exchange runs on every HTTPS call, all network commands crash, not just login:

Test (same host)	linux-gnu build	linux-musl build
railway login --browserless	SIGSEGV (exit 139)	works — prints device-code URL, polls
RAILWAY_API_TOKEN=x railway whoami	SIGSEGV (exit 139)	clean Unauthorized (exit 1)

Reproduced on both v4.66.1 and v5.23.3 release artifacts, so this is live on latest. Same source + same ring version works when built for musl → build-artifact issue, not a source bug.

Why the report initially looked TTY-related: on 4.66.x, the non-TTY path bailed at the is_stdout_terminal() gate before any network call, so it printed its error normally. The TTY path passed the gate, touched TLS, and crashed. The TTY was never the variable — the network was.

2. The npm wrapper swallows the crash

bin/railway.js runs the binary via execFileSync and does:

} catch (e) {
	exit(1);
}

The SIGSEGV (and every real exit code — clap usage errors, Ctrl-C 130, …) collapses into a silent exit 1. That's the "exits silently" part.

Why only npm users are affected

install.sh already ships musl binaries to all Linux users, with this comment:

# use the statically compiled musl bins on linux to avoid linking issues.
linux) platform="unknown-linux-musl" ;;

But npm-install/postinstall.js picks triples.platformArchTriples[platform][arch][0], which on Linux resolves to the gnu triple. Two more consequences of that ordering:

• aarch64 Linux npm installs 404 — aarch64-unknown-linux-gnu is selected but only the musl asset is published.
• arm32 Linux npm installs 404 — triples yields armv7-unknown-linux-* but the published asset is arm-unknown-linux-musleabihf.

Fix

PR incoming that:

1. makes npm-install/postinstall.js select the same musl targets install.sh uses on Linux (fixes the segfault-by-default on x64 + both 404s), and
2. makes bin/railway.js report crash signals with an actionable message and propagate the binary's real exit code.

Workaround meanwhile: uninstall the npm package and install via the shell installer (musl build), or set RAILWAY_API_TOKEN/RAILWAY_TOKEN — noting the latter only helps commands that don't need the interactive flow.

Happy to retitle this issue to something like "npm-installed CLI (linux-gnu build) segfaults on any network call; wrapper hides the crash" if that helps triage.