[BUG] CLI routes to localhost on auth

[ArchimedesCrypto]

Problem (one or two sentences)

CLI routes to 127.0.0.1 on successful auth instead of correctly routing to domain. Needed when deploying CLI to a cloud instance instead of a local machine.

Context (who is affected and when)

CLI users.

Reproduction steps

Install roo cli on cloud server
run roo auth login
copy login link to local browser, authenticate
get stuck

Expected result

Should login

Actual result

Does not

Variations tried (optional)

No response

App Version

v0.17.1

API Provider (optional)

None

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Problem: In apps/cli/src/commands/auth/login.ts, the callback host is hardcoded to 127.0.0.1. When the CLI runs on a cloud server, the auth service redirects the browser to http://127.0.0.1:{port}/callback, which resolves to the user's local machine rather than the remote server where the callback HTTP server is actually listening. Additionally, the server binds to 127.0.0.1 only, rejecting external connections.

Proposed fix: Add a --host flag to roo auth login that lets users specify a custom callback host:

1. Add --host option to the login command (apps/cli/src/commands/auth/index.ts or wherever the command is wired up) - a new optional string flag like --host <hostname-or-ip>.

2. Thread the host through LoginOptions in apps/cli/src/commands/auth/login.ts:

   • Add an optional host?: string field to LoginOptions.
   • When host is provided, use it for the callback URL (e.g. http://<host>:{port}/callback) instead of 127.0.0.1.
   • When host is provided, bind the HTTP server to 0.0.0.0 (all interfaces) so it can accept external connections, rather than binding to 127.0.0.1.
   • When host is not provided, keep the current behavior (bind to and use 127.0.0.1).

3. Update tests to cover the new host option behavior.

This approach is backward-compatible (no change for local usage) while enabling cloud deployments by allowing something like roo auth login --host my-server.example.com.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[ArchimedesCrypto]

@roomote can you make it so that It can accept a device code elsewhere similar to how github device codes are done for logging into GH CLI on remote servers?

[roomote-v0]

I've seen your comment about implementing a device code flow similar to how GitHub CLI handles auth on remote servers. I'll explore the current auth implementation and work on adding this capability. I'll open a PR to share progress shortly.

[roomote-v0]

Opened a draft PR with my attempt at implementing the device code auth flow: #11934

The PR adds a --device-code flag to roo auth login that follows the standard OAuth 2.0 Device Authorization Grant pattern (like GitHub CLI). On the CLI side, it requests a device code, displays a verification URL + user code, and polls for completion.

Note: the server-side endpoints (POST /api/cli/device-code and POST /api/cli/device-code/poll) still need to be implemented. The expected API contract is documented in the PR.

Feedback welcome!