If you're using Chrome installed via Flatpak (common on Fedora Silverblue, immutable distros, etc.), the Claude Code browser automation won't work out of the box. Here's how to fix it.
Claude Code installs the native messaging host to the standard Chrome location, but Flatpak Chrome:
- Looks for native messaging hosts in a different directory
- Has a sandboxed
/tmpthat isolates the Unix socket used for communication - Doesn't have access to
~/.claude/or~/.local/share/claude/by default
cp ~/.config/google-chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json \
~/.var/app/com.google.Chrome/config/google-chrome/NativeMessagingHosts/flatpak override --user com.google.Chrome \
--filesystem=~/.claude:ro \
--filesystem=~/.local/share/claude:roThis is needed because Claude Code's MCP server and the native messaging host communicate via a Unix socket in /tmp. Without this, the socket created inside Flatpak's sandbox isn't visible to Claude Code.
flatpak override --user com.google.Chrome --filesystem=/tmpFully quit Chrome (not just close the window) and relaunch it:
pkill -9 -f '/app/extra/chrome'
pkill -9 -f 'bwrap.*chrome'
# Then reopen ChromeRun claude --chrome or use /chrome in an existing Claude Code session.
You can check your Flatpak overrides with:
flatpak override --user --show com.google.ChromeExpected output should include:
[Context]
filesystems=~/.local/share/claude:ro;/tmp;~/.claude:ro;
Sharing /tmp with Flatpak has some security implications as it breaks part of the sandbox isolation. A better long-term fix would be for Claude Code to use a socket path in a user-accessible directory like ~/.claude/ or $XDG_RUNTIME_DIR instead of /tmp.
Tested on Fedora Silverblue with Chrome Flatpak (com.google.Chrome) and Claude Code 2.0.76.