Desktop app (Windows): /login in embedded terminal is unusable — 'c to copy' copies nothing, URL click warns then opens nothing

Environment

• Claude Code v2.1.216 — Windows desktop app, embedded Terminal tab
• Windows 11 Pro for Workstations (build 26200), multi-monitor, display scaling active
• Default browser: Chrome

Summary

When a session in the desktop app's embedded Terminal tab needs /login, there is no working path to the OAuth URL. Every affordance on the login screen fails silently. A non-technical user was completely blocked; it ultimately took a second, AI-driven session using OS automation to screen-capture the terminal, transcribe the ~500-char OAuth URL from an 8x-zoomed screenshot, and launch it via Start-Process. That should not be the happy path.

Steps to reproduce

1. Open the desktop app's Terminal tab with an expired CLI login ("Login expired · Please run /login").
2. Run /login. The screen shows: "Browser didn't open? Use the url below to sign in (c to copy)" with the OAuth URL.

Bug 1 — "(c to copy)" copies nothing

Pressing c on that screen leaves the Windows clipboard unchanged. Verified programmatically: clipboard read before and after the keypress (with the terminal focused) shows no text ever arrives. Presumably the CLI emits OSC52 and the embedded terminal doesn't bridge it to the system clipboard. It fails with no error, so users assume they are doing it wrong.

Bug 2 — clicking the URL: scary warning, then... nothing

Clicking the URL in the terminal shows a modal: "Do you want to navigate to … WARNING: This link could potentially be dangerous." Two problems:

• The warning fires on a first-party claude.com OAuth URL (generated by the product itself two lines up). Terrifying for non-developers.
• Clicking OK dismisses the dialog and no browser ever opens — no new window, no new tab (verified by window enumeration before/after). Silent failure again.

Bug 3 — no selection/copy fallback in the terminal pane

Mouse-selecting the URL text and right-clicking doesn't offer copy (right-click on the link region instead triggers the Bug 2 dialog, which also clears the selection). So all three intuitive paths — hotkey copy, click-to-open, select-and-copy — dead-end.

The kicker

The desktop app has a built-in Browser pane directly below the Terminal pane. The login flow never uses it. Opening the OAuth URL there would sidestep every failure above.

Suggestions

1. Open /login URLs in the app's built-in browser pane (or at minimum offer it).
2. Fix c to copy in the embedded terminal on Windows (bridge OSC52 → system clipboard).
3. Make OK on the navigation warning actually launch the default browser.
4. Whitelist first-party claude.com / claude.ai / anthropic.com URLs from the "potentially dangerous" warning.
5. Surface copy failures — a "Copied!" confirmation would have revealed the no-op immediately.

User feedback, verbatim spirit

The affected user is a non-developer small-business owner. His offer to Anthropic: he's happy to walk the team through which parts of the product are confusing to normal people — his words: the parts that are obviously broken for non-developers exist "and yet they don't ask." He'd genuinely take that call.

(Filed on his behalf, from his machine, with his permission, by the Claude instance that watched the copy button fail with its own hands.)