Log in to OpenShift from WSL using a Windows browser

The browser is on the other side of WSL

The OpenShift CLI is running in Ubuntu under WSL. Firefox is installed on Windows. Both are on the same laptop, but asking the CLI to open a browser produces this:

exec: "xdg-open,x-www-browser,www-browser": executable file not found in $PATH

That was the problem behind these notes. The command was a browser-based login, also used through an alias:

oc login --server=https://api.example.com:6443 -w

The API address here is a placeholder. Replace it with your cluster's API endpoint.

The approach is to give Ubuntu in WSL a small browser-opening command that launches Windows Firefox, then select it with BROWSER. A symlink workaround later in this guide covers the specific case where the CLI looks for a comma-separated executable name.

Check that browser login is available

Run these commands inside WSL:

oc version --client
oc login --help

Check that your CLI supports --web (the long form of the -w option used here). Red Hat documents the browser flow in its OpenShift CLI login instructions. The flow uses a local HTTP callback listener, so opening the authentication page is only one part of completing the login.

First, launch Firefox directly

Before changing browser configuration, check that WSL can start the installed Windows executable:

"/mnt/c/Program Files/Mozilla Firefox/firefox.exe" "https://example.com"

Firefox should open on the Windows desktop. Adjust the path if your installation lives elsewhere. Quoting matters because Program Files contains a space.

WSL can launch Windows .exe files directly; this is part of Windows/Linux command interoperability. If this direct command fails, resolve the executable path or WSL interoperability first. A wrapper cannot fix a command that does not work on its own.

Give Linux an xdg-open wrapper

The original setup used /usr/local/bin/xdg-open. Check for an existing file before creating it:

command -v xdg-open
ls -l /usr/local/bin/xdg-open

A missing-file message from ls is expected if you have not created the wrapper. If that path already exists, inspect it before changing it. This wrapper forwards arguments to Firefox; it is not a complete replacement for a desktop's file-opening service.

Create /usr/local/bin/xdg-open with an editor:

sudo nano /usr/local/bin/xdg-open

Use these contents:

#!/bin/bash
exec "/mnt/c/Program Files/Mozilla Firefox/firefox.exe" "$@"

"$@" preserves each argument, including a URL containing & or other characters. exec hands execution over to Firefox without an extra shell waiting around.

Make the wrapper executable and test it:

sudo chmod +x /usr/local/bin/xdg-open
hash -r
command -v xdg-open
xdg-open "https://example.com/?source=wsl&test=browser"

For this setup, command -v should report /usr/local/bin/xdg-open. If it reports another path, inspect type -a xdg-open and your PATH. The quoted test URL should reach Firefox intact.

Tell the CLI which opener to use

Check the current value and select the wrapper:

printf '%s\n' "$BROWSER"
export BROWSER=xdg-open

Try the login from the same shell:

oc login --server=https://api.example.com:6443 -w

When the browser flow completes, verify both the user and cluster:

oc whoami
oc whoami --show-server

An open browser window alone does not prove the CLI authenticated. These checks should identify the intended account and API endpoint.

Once this works, add the following line once to ~/.bashrc, replacing any conflicting existing BROWSER assignment:

export BROWSER=xdg-open

Reload Bash's configuration:

source ~/.bashrc

If you use a different shell, put the setting in that shell's configuration instead. Other CLI applications may also use BROWSER, so this choice can affect more than OpenShift.

Give each environment a login alias

When switching between clients and systems, an alias saves typing the API endpoint each time. Use the pattern oc-<clientname>-<system> so the destination is clear:

alias oc-cbtest-dev='oc login --server=https://api.dev.cbtest.example.com:6443 -w'
alias oc-cbtest-test='oc login --server=https://api.test.cbtest.example.com:6443 -w'

Replace these example endpoints with the corresponding cluster API addresses. Add the aliases to ~/.bashrc alongside your BROWSER setting, then reload it:

source ~/.bashrc
oc-cbtest-dev

The alias runs the same browser-based login using your Windows Firefox wrapper. It does not store credentials or create an isolated CLI session. Before running commands against the cluster, confirm where the login took you:

oc whoami
oc whoami --show-server
oc project

The alias name is a reminder, not proof of the active cluster or project. Check these values whenever switching environments.

If it still asks for a comma-separated executable

The original investigation also encountered the literal name:

xdg-open,x-www-browser,www-browser

Those are three familiar Linux opener names. The error reports them together; it does not tell us why that CLI invocation arrived at the combined name. Do not assume commas are a general-purpose way to configure BROWSER.

First check the environment used by the failing command:

printf '%s\n' "$BROWSER"
type -a oc xdg-open
ls -l /usr/local/bin/xdg-open
xdg-open "https://example.com"

An alias, another shell or a different oc binary can make a successful standalone test differ from the failing login. Check your CLI version and current login help before adding a workaround.

If the error still explicitly names the entire comma-separated filename, a symlink with exactly that name lets the lookup reach the wrapper:

sudo ln -s /usr/local/bin/xdg-open \
  '/usr/local/bin/xdg-open,x-www-browser,www-browser'

This workaround applies only to that particular executable lookup. Do not add it when normal BROWSER=xdg-open login already works. Its necessity for completing this login flow remains unverified.

If you created that link and later no longer need it, verify it is your symlink before removing it:

ls -l '/usr/local/bin/xdg-open,x-www-browser,www-browser'
sudo unlink '/usr/local/bin/xdg-open,x-www-browser,www-browser'

Firefox opens, but login never finishes

At this point, browser launching and authentication are separate problems. Keep oc login running while completing the browser flow. Check that Windows can reach the localhost callback inside WSL and that no other process owns the selected callback port. WSL normally supports Windows-to-Linux localhost access; see Microsoft's networking guidance.

Use the callback options shown by your installed oc login --help if a port conflict is reported. If the CLI prints a login URL, opening that URL manually in Windows is also a useful way to separate an opener failure from the rest of the flow. Treat the generated URL as login-session information rather than something to paste into public logs.

Calling Firefox directly avoids an additional cmd.exe /c start parsing layer. Once the wrapper, browser login and oc whoami checks work, the CLI can stay in Linux while authentication happens in the Windows browser you already use.