[BUG] Cannot login to Roo Cloud at signup with either vscode or pycharm in linux

[rojalator]

Problem (one or two sentences)

Problem (one or two sentences)

After signing up, the website displays a copyable link to complete. In linux under xfce4 it is impossible to proceed as the relevant IDE is not launched.
This is similar to bug #12120 but for both VSCode and PyCharm

Recommendation

Recommend a simple 'enter key' or 'enter code' alternative setting in the relevant plugin dialogues.

Context (who is affected and when)

xfce4 linux users (and possibly others whose systems are not able to process 'open app' links)

Reproduction steps

Attempt to complete login using xfce4 under linux.

Expected result

login should complete

Actual result

Unable to proceed or use RooCode router (it is possible to use OpenRouter, etc)

Variations tried (optional)

Attempted setting xdg-open and all manner of script adjustments

App Version

Version: 3.52.0 (09edc1e)

API Provider (optional)

Not Applicable / Other

Model Used (optional)

N/A

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

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

Analysis

The Roo Cloud login flow works by:

1. Opening the browser to app.roocode.com/extension/sign-in with a state param and an auth_redirect URI (e.g. vscode://RooVeterinaryInc.roo-cline)
2. After web authentication, the website redirects back using the vscode:// URI scheme with a code and state in the callback URL
3. The extension picks up this URI via handleUri.ts and completes the sign-in

On Linux desktop environments like xfce4, the vscode:// custom URI scheme is often not registered, so the redirect in step 2 never reaches the IDE. A "Having trouble?" link exists that shows a manual URL paste field, but it requires users to copy the full callback URL from the browser, which can be confusing.

What we can improve on the extension side

A true "enter short code" flow (like device authorization) would require server-side changes to app.roocode.com, which is outside this repository. However, we can significantly improve the manual entry UX to make it work better for affected users:

1. Show the manual URL entry more prominently -- instead of hiding it behind a "Having trouble?" link that only appears after clicking "Connect", show a secondary "Sign in with URL" or "Paste callback URL" option directly on the Cloud view as a visible alternative
2. Improve the instructions -- add clearer text explaining what URL to paste and where to find it (e.g. "Copy the URL from your browser address bar after signing in")
3. Add the same prominent manual entry to the WelcomeView -- the WelcomeViewProvider.tsx also has a manual URL flow; keep it consistent
4. Increase the clerkSignIn timeout -- the related issue [BUG] Cannot login to Roo Cloud in Baidu Comate IDE（VSCode Compatible） #12120 shows TimeoutError failures with the current 10-second timeout in WebAuthService.clerkSignIn(). Increasing this to 30 seconds would help users on slower connections or when there's a delay in pasting the URL

Proposed changes

1. webview-ui/src/components/cloud/CloudView.tsx -- Restructure the unauthenticated view to show "Paste callback URL" as a visible alternative alongside the "Connect" button, rather than hidden behind "Having trouble?"
2. webview-ui/src/components/welcome/WelcomeViewProvider.tsx -- Apply the same improvements to the welcome view manual entry flow
3. packages/cloud/src/WebAuthService.ts -- Increase the AbortSignal.timeout in clerkSignIn() from 10s to 30s to reduce timeout failures when using the manual URL flow
4. Update relevant i18n strings for the improved UX text

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

[rojalator]

@roomote, not approved. The issue is that the URI (vscode:// or pycharm://) do not work even if xdg-open or other settings are adjusted: the extension does NOT pick up this URI via handleUri.ts and complete the sign-in, making using RooCode's router impossible. Adjusting timeouts will not adjust this behaviour, altering the URI will not adjust this behaviour. Displaying the URL entry will also fail as will improving instructions.

[roomote-v0]

I've seen your comment and understand the core problem -- the vscode:// URI scheme callback doesn't work on Linux desktop environments like xfce4, and the extension's handleUri never fires. Manual URL entry is also impractical because the callback URL is not easily visible when the redirect fails silently.

I'll explore implementing a local HTTP server fallback for the auth flow. Instead of relying on the vscode:// URI scheme, the extension would start a temporary http://127.0.0.1:PORT server to receive the OAuth callback directly. This is the same pattern used by tools like GitHub CLI and gcloud for OAuth on environments where custom URI schemes don't work.

I'll open a PR to share progress. Feedback and guidance are welcome.

[rojalator]

That is complicated: how will you know the PORT number to use? (developer-machines can have lots of services running: you might post to another service). The single simplest fix is to offer a fallback manual option in the interface for the plugin. It is a robust solution requiring no servers to run.

[roomote-v0]

Opened a draft PR with my attempt at addressing this: #12123

The approach: instead of relying on the vscode:// URI scheme (which does not work on many Linux desktop environments), the extension now starts a temporary local HTTP server on http://127.0.0.1:<random-port> and uses that as the OAuth callback URL. After browser authentication, the redirect goes to this localhost URL, which the extension receives directly -- no custom URI scheme needed.

Important caveat: This requires the Roo Cloud server (app.roocode.com) to accept http://127.0.0.1:PORT as a valid auth_redirect value. If the server validates/restricts redirect URLs, a server-side allowlist update would also be needed for this to work end-to-end.

Feedback welcome!

[rojalator]

A random port is not acceptable: again, there might be a service already running on that port. Are you checking whether the port is in use first?