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.
Problem
hey auth loginstarts a loopback listener on127.0.0.1:<port>/callbackand 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>/callbackresolves 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 loginhung 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 extractcodeandstatefrom the callback URL in the address bar and replay it against the CLI's listener with curl: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.