The browser login flow starts a temporary local server to receive the callback, and it sounds like the CLI process is exiting before that callback arrives. As a workaround, you can use railway login --browserless, which uses a pairing-code flow that doesn't depend on a local callback server. It will display a URL and code you can enter in any browser to authenticate.

The silly CLI won't let me use the --browserless option. When I try to it just says, "A browser is available on this machine — railway login without --browserless opens it directly and completes more reliably."

Based on your description, the problem is most likely that the Railway CLI starts a temporary local callback server on 127.0.0.1 to complete the OAuth login flow, but that server is no longer running or is exiting before the browser redirects back to it.

Since you mentioned that railway login immediately returns to the shell prompt instead of continuing to wait, it suggests the CLI process is terminating prematurely. As a result, when the browser redirects to 127.0.0.1:<random_port>, there is no process listening on that port, causing the "127.0.0.1 refused to connect" error.

Possible causes include:

A bug in Railway CLI v5.26.0.

Incompatibility with Node.js v25.9.0 (which is a very recent version and may not be fully supported).

Another process interfering with the localhost callback.

Browser extensions, proxy, or security software interrupting the OAuth redirect.

I would recommend trying the following:

Use the latest LTS version of Node.js (v22 or v24) instead of Node.js v25.

Update or reinstall the Railway CLI.

Try a different browser (Chrome or Firefox) or use an incognito window.

Run railway login --browserless (if supported) to authenticate without the local callback server.

Check whether the issue persists on another machine or user account.

The key symptom is that the CLI should remain running and wait for the browser callback. Since it exits immediately, the localhost listener disappears before the redirect arrives, which explains why the browser cannot connect to 127.0.0.1. This points to a CLI/runtime issue rather than a firewall problem.

Are you copy-pasting from AI? I asked Microsoft Copilot for help before posting here and got most of the same suggestions you're giving. We're all aware of the option of trying to solve this kind of problem with AI. I wouldn't be here if it had solved mine.

I've tried downgrading Node to version 24.18.0 (NPM version 11.16.0) and reinstalling Railway CLI (now version 5.26.1) and have gotten the same result.

Your suggestion to use a different browser or Incognito doesn't make any sense given your diagnosis that the local callback server is no longer running.

Your suggestion to use the --browserless option implies you didn't even read my last reply.

Hey, can you show a screenshot of how railway login --browserless looks like on your end? It prints the message that you have mentioned above but also honors it by providing the link you should open / the code that you should use with https://railway.com/activate.

I don't get the link or code.

Hey, do you mind uninstalling the Railway CLI, which you installed with npm and reinstall the Railway CLI using the first/second (with or without agent configuration) option listed in the documentation?

You might have an outdated version of Railway cli, if you have installed it using npm, just run npm i -g @railway/cli@latest to update it.