Repository navigation
Support login when the browser runs on a different machine than the CLI #480
Description
Problem
hey auth login starts a loopback listener on 127.0.0.1:<port>/callback and expects the OAuth redirect to land on the same machine as the CLI. That breaks whenever the terminal running the CLI isn't the machine with the browser: headless VMs, containers, SSH sessions, or agent sandboxes where the browser lives on a different VM.
What happens: the authorization page opens fine in the remote browser, but HEY's redirect to http://127.0.0.1:<port>/callback resolves to the browser machine's localhost, where nothing is listening. The CLI waits forever and the login never completes.
This bit us setting up the HEY CLI for Muse, an AI assistant: the agent runs the CLI on its own VM while the browser lives on a separate VM, so hey auth login hung until we worked around it manually (below).
Current workaround
hey auth login --no-browser, copy the authorization URL, approve it in a browser with a HEY session, then extract code and state from the callback URL in the address bar and replay it against the CLI's listener with curl:
curl "http://127.0.0.1:<PORT>/callback?code=<CODE>&state=<STATE>"
This works, but it's painful and requires shell access to the CLI machine at login time.
Request
Support the RFC 8628 device authorization grant as an alternative login flow: the CLI prints a URL plus a short user code, the user approves on any device, and the CLI polls for tokens. No localhost listener, no browser-on-the-same-machine assumption.
Note: #356 (ephemeral loopback port) doesn't address this — it solves local port squatting, not the cross-machine browser case.
Activity
GoldenrodScript commentedon Oct 16, 2026
Running into this too with HEY CLI v1.9.0. Trying to let my agent check email from a cloud computer while my laptop’s closed, but the browser and CLI are on different machines so the localhost callback can’t reach it. Is there a supported workaround? Device-code login would be really useful.
justin-thurman commentedon Oct 19, 2026
+1, with one more use case that device-code login (#381) wouldn't fully cover.
I run agents in short-lived cloud sandboxes. Each new task gets a fresh VM, and several can run at once. Signing in once per VM doesn't scale, so I sign in once and share the access token with every sandbox through
HEY_TOKEN. That works well for about two weeks, until the access token expires.I can't share the refresh token as well. As I read
internal/auth, HEY rotates the refresh token on every refresh. If two sandboxes held the same one, the first to refresh would sign out the other. So every two weeks I sign in by hand again.Device-code login would make that sign-in easier, which would be great. It wouldn't remove it, though. What would remove it is a long-lived token meant for unattended use, like a personal access token from HEY's settings.
docs/cli.mdalready mentionshey auth login --token TOKENfor "a pre-generated token," but I couldn't find where to generate one.So, two questions:
For reference, my workaround is to approve the authorization in a browser running inside the same VM, so the loopback callback lands locally, then keep only the access token. It works but it's clunky.