[BUG] /radio command fails to open browser on Windows (Git Bash environment) despite working browser/session
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Running /radio fails to open the browser and instead falls back to printing a link, even though the underlying OS/session is fully capable of launching a browser.
Steps to reproduce
- Run Claude Code on Windows, using Git Bash as the shell (PowerShell also available).
- Run /radio.
- Observe output: Couldn't open the browser. Listen at: https://clau.de/radio
Expected behavior
The default browser (Firefox, in my case) opens automatically to the given URL.
Actual behavior
No browser opens; the command silently falls back to printing the link instead.
Environment
- OS: Windows 11 Home 10.0.26200
- Shell: PowerShell (primary), Git Bash also available
- Session: Interactive console logon (confirmed via whoami /groups, not a service/non-interactive session)
- Default browser: Firefox, correctly registered (HKCU:\...\UrlAssociations\https\UserChoice)
- $BROWSER env var: unset (not overriding anything)
Diagnostics performed
To rule out a local environment problem, I confirmed the OS/session can launch a browser just fine:
- Start-Process "https://clau.de/radio" from PowerShell immediately and reliably opened Firefox to the URL.
- This rules out session isolation, missing browser association, and env var overrides as causes.
Suspected root cause
Since a native Start-Process/start call works but Claude Code's own opener doesn't, this looks like a cross-platform bug in whatever helper /radio (and likely other browser-opening commands) uses internally — e.g. shelling out to a Unix-style opener (open on macOS / xdg-open on Linux) that doesn't exist in a Git Bash PATH on Windows, or an improperly quoted Windows start invocation (missing the empty "" title placeholder, causing the URL to be parsed as a window title instead of a target). Either would fail silently and fall through to the "couldn't open browser" message, exactly as observed.
What Should Happen?
Suggested fix
On Windows, invoke the browser opener via cmd /c start "" "<url>" (note the empty title argument) or via a Windows-native API/Start-Process equivalent, rather than relying on Unix-only open/xdg-open binaries being present in PATH.
Error Messages/Logs
Steps to Reproduce
Title: /radio command fails to open browser on Windows (Git Bash environment) despite working browser/session
Description
Running /radio fails to open the browser and instead falls back to printing a link, even though the underlying OS/session is fully capable of launching a browser.
Steps to reproduce
- Run Claude Code on Windows, using Git Bash as the shell (PowerShell also available).
- Run /radio.
- Observe output: Couldn't open the browser. Listen at: https://clau.de/radio
Expected behavior
The default browser (Firefox, in my case) opens automatically to the given URL.
Actual behavior
No browser opens; the command silently falls back to printing the link instead.
Environment
- OS: Windows 11 Home 10.0.26200
- Shell: PowerShell (primary), Git Bash also available
- Session: Interactive console logon (confirmed via whoami /groups, not a service/non-interactive session)
- Default browser: Firefox, correctly registered (HKCU:\...\UrlAssociations\https\UserChoice)
- $BROWSER env var: unset (not overriding anything)
Diagnostics performed
To rule out a local environment problem, I confirmed the OS/session can launch a browser just fine:
- Start-Process "https://clau.de/radio" from PowerShell immediately and reliably opened Firefox to the URL.
- This rules out session isolation, missing browser association, and env var overrides as causes.
Suspected root cause
Since a native Start-Process/start call works but Claude Code's own opener doesn't, this looks like a cross-platform bug in whatever helper /radio (and likely other browser-opening commands) uses internally — e.g. spener (open on macOS / xdg-open on Linux) that doesn't exist ina Git Bash PATH on Windows, or an improperly quoted Windows start invocation (missing the empty "" title placeholder, causing the URL to be parsed as a window title instead of a target). Either would fail silently an't open browser" message, exactly as observed.
Suggested fix
On Windows, invoke the browser opener via cmd /c start "" "<url>" (note the empty title argument) or via a Windows-native API/Start-Process equivalent, rather than relying on Unix-only open/xdg-open binaries being p
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude Code version: 2.1.252
Platform
Other
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
Text from Terminal:
/radio
⎿ Couldn't open the browser. Listen at: https://clau.de/radio
Im very interested on what holdup might be responsible. I did open the link myself in YouTube but mainly now I want to fix whatever the problem is
2 skills available
Let me actually test the browser-launch mechanism directly rather than speculate.
Ran 2 shell commands
Interactive session confirmed, and the default browser is Firefox. Let me test whether the actual launch call works from this shell.
Ran 3 shell commands
That confirms it: Start-Process from this same shell does successfully launch Firefox to the URL (see the new Firefox window titled "Claude FM 🎵..." that appeared right after). So the OS, the session, and the default browser association are all fine — the failure is specific to whatever mechanism Claude Code's /radio command uses internally to open a browser, not to your machine.
Let me check for a couple of likely culprits: a $BROWSER env var override, or a Claude Code setting pointing at a bad path.
Ran 1 shell command
You did it
Glad that got it playing. 🎵
Ran 1 shell command
You did it
Glad that got it playing. 🎵
To close the loop on the diagnosis: I checked for the two most likely culprits and ruled them out —
- No $BROWSER env var override — nothing hijacking the launch target.
- Interactive session confirmed, default browser (Firefox) correctly registered, and a plain Start-Process <url> from this exact shell launches it instantly and reliably.
So the environment itself is fully capable of opening a browser — the failure is isolated to whatever helper Claude Code's /radio command uses internally to fire off that launch. The most likely explanation: Claude Code is cross-platform, and its "open URL in default browser" helper probably shells out using a Unix-style command (open on macOS, xdg-open on Linux) or an improperly-quoted Windows start call. Since your shell setup here is Git Bash (POSIX) layered on Windows, neither open nor xdg-open exist in that PATH, and a bare start <url> without an empty "" title placeholder mis-parses the URL as a window title — either of those would fail silently exactly like this, while a native Start-Process (which I used) works fine.
That's a Claude Code bug/gap, not something fixable from your side — I don't have access to the CLI's own source to patch it. Two options:
- Report it at https://github.com/anthropics/claude-code/issues — worth flagging since it'll hit anyone running Claude Code via Git Bash on Windows.
- Workaround: since Start-Process <url> (or cmd /c start "" <url>) reliably works in your setup, you can just run that yourself (or ask me to) whenever a command prints a "couldn't open browser" fallback link.