はじめに
Windows 11上のWSL2にUbuntuなどのLinuxをインストールして開発環境を構築している方は多いと思います(便利ですよね)。
その際、ブラウザの運用方針は人によって分かれるかと思います。
- WSL2上のLinux側にブラウザをインストールして完結させる(ただ、日本語という観点だと、Linux側にIMEをインストールするなど、ブラウザインストール以外の手間がかかります)
- WSL2上のLinux側にはブラウザをインストールせず、Windows側のブラウザをそのまま使う(今回はこちら)
特に後者の場合、CLIツールを使った認証などで少しつまずくポイントがあります。本記事ではその解決策と、さらに便利なWindows連携ツールへの応用を紹介します。
【2026/04/28】追記・大幅修正: いただいたフィードバックを反映しました
本記事の公開後、はてなブックマークにてフィードバックをいただきました。
-
wsluパッケージは現在 deprecated (非推奨) である -
deb(apt) 管理下のパッケージ(/usr/bin/xdg-openなど)をmvコマンドで強制的に退避・上書きしても、パッケージアップデート時に元に戻されてしまう
これらの指摘を踏まえ、システムを汚さずに、より安全で確実な方法に記事を大幅にアップデートさせていただきました。ご指摘いただいた皆様、ありがとうございました。
CLIツールのブラウザ認証で発生するエラー
Linux側でGitHub CLIなどのツールを使う際に、gh auth login のようにブラウザ認証を行おうとした際、以下のようなメッセージが表示されることがあります。
! First copy your one-time code: XXXX-XXXX
Press Enter to open https://github.com/login/device in your browser...
ここで素直にEnterキーを押しても、ブラウザが(Linux側にはインストールされていないので)立ち上がらず、以下のようなエラーが出力されてしまうケースがあります。
! Failed opening a web browser at https://github.com/login/device
exec: "xdg-open,x-www-browser,www-browser,wslview": executable file not found in $PATH
これは、Linux側でURLを開くための標準コマンド(xdg-openなど)が見つからず、その上、Windows側のブラウザに処理を渡せていないために発生します。
最新のベストプラクティス (システムを汚さない設定)
結論から言うと、以下の2つの設定を行うのが現在の最適解です。
- 環境変数
BROWSERに Windows純正のURLハンドラを指定する - ユーザーローカルのパスに、
xdg-openのラッパースクリプトを配置する
1. 環境変数 BROWSER の設定
多くのCLIツールは、ブラウザを開く必要がある際に環境変数 BROWSER を参照します。ここに Windows標準のURL起動コマンドである rundll32.exe を割り当てます。
お使いのシェル設定ファイル (~/.bashrc または ~/.zshrc に)以下を追記してください。
# Windowsのデフォルトブラウザで開くための設定
export BROWSER='/mnt/c/Windows/System32/rundll32.exe url.dll,FileProtocolHandler'
2. xdg-open 直叩きアプリへの対策
ツールによっては、環境変数 BROWSER を見ず、Linux標準の xdg-open コマンドを直接叩きに行く伝統的なアプリも存在します。ただし、/usr/bin/xdg-open を直接書き換えても、apt upgrade等でシステムが更新された際に元に戻されてしまいます。
そこで、システムのパス(/usr/bin)よりも優先されるユーザーローカルディレクトリ(~/.local/bin)に同名のラッパースクリプトを配置します。
ラッパースクリプトの作成
以下のコマンドを順に実行してください。
# ユーザーローカルのbinディレクトリを作成（無い場合）
mkdir -p ~/.local/bin
# xdg-openのラッパースクリプトを作成
cat << 'EOF' > ~/.local/bin/xdg-open
#!/bin/sh
/mnt/c/Windows/System32/rundll32.exe url.dll,FileProtocolHandler "$1"
EOF
# 実行権限を付与
chmod +x ~/.local/bin/xdg-open
もし ~/.local/bin にPATHが通っていない場合は、~/.bashrc 等に export PATH="$HOME/.local/bin:$PATH" も追記しておきましょう。
最後に source ~/.bashrc で設定を反映し、ラッパースクリプトが正しく優先されているかを確認します。
which xdg-open
実行結果がシステムの標準パス（/usr/bin/xdg-open ）ではなく、以下のようにご自身のローカルディレクトリ配下のパスになっていれば、無事に設定完了です！
/home/（あなたのユーザー名）/.local/bin/xdg-open
動作確認
ターミナル上で以下を実行し、Windows側のブラウザでGoogleが開けば成功です。
xdg-open https://google.com
さらに便利に: Browser Tamer でプロファイルを自動振り分け
WSL2からWindowsの「既定のブラウザ」が起動できるようになったことで、ここに Browser Tamer などのブラウザルーター(振り分けツール)を設定しておくと、WSL2上で動作しているアプリケーションがブラウザを起動する際に、その恩恵を受けることができます。
- このURL(ドメイン)はChromeの会社プロファイルで開く
- このURL(ドメイン)はChromeの個人プロファイルで開く
といったルールをWindows側でいったん設定しておけば、WSL2からのブラウザ起動であろうとプロファイルの切り替えミスを防ぎ(あるいはドキュメントが開けないといったトラブルを防ぎ)、作業効率が劇的に向上します。
- Browser Tamer: https://github.com/aloneguid/bt/releases
WSL2の隔離された開発環境と、Windowsのブラウザ＋日本語入出力環境、この2つをストレスなくつなぐために、ぜひ本記事の内容を活用してみてください。
注意: 以下の方法は現在非推奨です。アーカイブとして残しています。
以前は、wslu (WSL Utilities) の wslview を利用し、システム(/usr/bin)のxdg-openを無理やり書き換えるハックを紹介していました。
# 過去の非推奨コマンド
sudo apt install wslu
export BROWSER=wslview
sudo mv /usr/bin/xdg-open /usr/bin/xdg-open.bak
sudo ln -s /usr/bin/wslview /usr/bin/xdg-open
非推奨の理由:
-
wslu事態がすでにdecprecated (非推奨)になっている。 -
aptの管轄下にある/usr/bin/xdg-openを手動でmvしても、OSのパッケージアップデートが走った時に上書きされてしまい、設定が元に戻るため。
元バージョンの記事に「いいね」「ストック」いただきありがとうございました。今後ともよろしくお願いいたします！