[BUG] Linux: login dead-ends at "Finish sign-in in the Claude app"

same, Ubuntu 22.04.5 LTS. Installed and logged in just fine, but when I entered my first prompt it told me I had to login, and getting the same deeplink error.

That said, i was able to work around it (thanks to claude web....) It looks like there might be the link already, it just needs to be updated with: update-desktop-database /usr/share/applications ~/.local/share/applications

however that was at the end of setting it up manually, which I did before reading the whole prompt...
Since this is the official Anthropic .deb build, the binary lives at /usr/bin/claude-desktop. Here's how to register the claude:// handler manually (which also worked...):

1. Create a desktop entry for the URL scheme:

bash
mkdir -p ~/.local/share/applications
cat > ~/.local/share/applications/claude-desktop-handler.desktop << 'EOF'
[Desktop Entry]
Name=Claude Desktop (URL Handler)
Exec=/usr/bin/claude-desktop %u
Type=Application
NoDisplay=true
MimeType=x-scheme-handler/claude;
EOF

2. Register it with the desktop database:

bash
xdg-mime default claude-desktop-handler.desktop x-scheme-handler/claude
update-desktop-database ~/.local/share/applications

3. Verify it took:

bash
xdg-mime query default x-scheme-handler/claude
# should print: claude-desktop-handler.desktop

4. Test the handoff directly before retrying sign-in:

bash
xdg-open "claude://test_nonce=abc123"

Adding a data point that narrows this down, plus one correction to the environment assumption in the original report: the desktop app does ship for Linux now (apt repo, claude-desktop 2.2553.0), so on Ubuntu the deep link does have something to open — and it still dead-ends.

Environment

• Ubuntu 26.04, GNOME (Wayland session)
• claude-desktop 2.2553.0 from Anthropic's apt repo
• Google Chrome 153 (.deb, not snap/flatpak)
• "Continue with Google"

The handler was registered correctly the whole time

$ xdg-mime query default x-scheme-handler/claude
com.anthropic.Claude.desktop
 
$ gio mime x-scheme-handler/claude
Default application for "x-scheme-handler/claude": com.anthropic.Claude.desktop

Both /usr/share/applications/com.anthropic.Claude.desktop and ~/.local/share/applications/com.anthropic.Claude.desktop exist with MimeType=x-scheme-handler/claude;. xdg-open "claude://claude.ai/new" and gio open "claude://claude.ai/new" both launch the app.

So @adammarr's step 4 passes here, and the manual handler entry isn't what's missing in my case — yet sign-in still fails identically.

Where it actually breaks

Chrome reports success. From --enable-logging=stderr --v=1:

shell_integration_linux.cc:490] Looking for desktop file in /home/<user>/.local/share/applications/com.anthropic.Claude.desktop
shell_integration_linux.cc:492] Found desktop file at /home/<user>/.local/share/applications/com.anthropic.Claude.desktop
INFO:CONSOLE:0] "Launched external handler for 'claude://login/google-auth?code=...&anon_id=...&hop_nonce=...'", source: https://claude.ai/login/popup-google-auth

The app never sees it. ~/.config/Claude/logs/main.log at the same moment:

09:22:35 [info] [Auth] Using system browser for: /login/app-google-auth
09:22:36 [info] [RemotePluginManager] Skipping sync: session not confirmed after 5s wait
09:22:37 [info] [PluginsFetcher] fetchPluginEnabledState: 2 overrides

Nothing about an incoming callback, ever. Instead GNOME shows the app chooser ("No Apps Available — ..._nonce=...") and journalctl --user -f logs:

xdg-desktop-portal-gnome[...]: Failed to associate portal window with parent window

The app process is alive throughout (confirmed with ps), so this isn't a failed launch — the URL just never reaches the running instance.

The IPC path itself is fine

Delivering a URL manually to the already-running app works:

$ claude-desktop "claude://login/google-auth?code=test123&hop_nonce=test"

# main.log:
[warn] Google sign-in code does not answer a sign-in this app started; ignoring
[info] claudeURLHandler: ignoring repeat delivery of login callback
[info] Not main instance, returning early from app ready

It's received, routed to the main instance, and correctly rejected because the code is fake. So single-instance delivery works; the gap is between Chrome's external-protocol launch and the app.

One thing that supports @adammarr's update-desktop-database hint

My user mimeinfo cache had the entry but the system one did not:

$ grep -c "x-scheme-handler/claude" ~/.local/share/applications/mimeinfo.cache
1
$ grep -c "x-scheme-handler/claude" /usr/share/applications/mimeinfo.cache
0

After sudo update-desktop-database /usr/share/applications it reads 1. I can't confirm whether that alone fixes sign-in, because by then I'd already gotten in via the workaround below — but it's worth others testing first, since the package's postinst apparently doesn't refresh the system cache.

Workaround that got me in

Capture the real callback URL and hand it to the app yourself while the code is still valid:

# terminal 1
pkill -f chrome
google-chrome-stable --enable-logging=stderr --v=1 2>&1 | grep --line-buffered -o 'claude://[^"]*'
 
# complete the Google sign-in, copy the printed URL, then in terminal 2:
claude-desktop "<the claude:// URL>"

Sign-in completes normally. Move quickly — the code is short-lived.

Things that did not help: reinstalling claude-desktop, clearing claude.ai site data in Chrome, and forcing --ozone-platform=x11 instead of native Wayland.

i think they fixed it because its working fine now. i am closing the issue.