はじめに
WSL Ubuntu 内にブラウザ機能を内蔵した ChatGPT Desktop アプリをインストールしたところ、今回の環境では HTTP・HTTPS のデフォルトアプリが chatgpt.desktop に変わっていました。
その結果、gh auth login や claude auth login でブラウザ認証を行おうとすると、普段使っているブラウザではなく、ChatGPT 内のブラウザが起動するようになりました。
認証用のページを開きたいだけなのに、別のアプリが立ち上がるのは少々不便です。最初は ChatGPT アプリをアンインストールして回避していましたが、そのたびに削除するのも面倒なので、WSL 側のブラウザ設定を見直すことにしました。
この記事では、WSL Ubuntu から開く HTTP・HTTPS の URL を、Windows 側のデフォルトブラウザに渡す方法をまとめます。
設定の途中で遭遇した、rundll32.exe の実行権限エラーや、自作した .desktop ファイルがデフォルトアプリとして採用されない問題についても、実際に解決した手順を紹介します。
今回は ChatGPT Desktop がきっかけでしたが、別のブラウザやブラウザ内蔵アプリが意図せず URL の起動先になった場合にも、同じ観点で切り分けられます。
本記事は、今回の環境で確認した挙動と解決手順をまとめたものです。ChatGPT Desktop のすべての配布形態・バージョンで、デフォルトブラウザ設定が変更されることを示すものではありません。
この記事でできること
- WSL Ubuntu の HTTP・HTTPS のデフォルトアプリを確認する
- Windows 側のデフォルトブラウザを開くランチャーを作成する
- ランチャーを URL のデフォルトハンドラーとして登録する
-
Permission deniedが出る場合に、WSL のマウント設定を確認する -
gh auth loginとclaude auth loginで Windows 側のブラウザが開くことを確認する
検証環境と発生した問題
今回の検証環境は次のとおりです。
| 項目 | 環境 |
|---|---|
| Linux 環境 | WSL Ubuntu 24.04 |
| systemd | 有効 |
| Windows の C ドライブ |
/mnt/c にマウント |
| WSL 内のアプリ | ChatGPT Desktop、複数の Linux ブラウザ |
| 確認した認証操作 |
gh auth login、claude auth login
|
問題が起きていたとき、URL のデフォルトアプリを確認すると、次の結果になっていました。
xdg-mime query default x-scheme-handler/http
xdg-mime query default x-scheme-handler/https
chatgpt.desktop
chatgpt.desktop
この状態では、CLI が認証用 URL を開くと、ChatGPT 内のブラウザが起動してしまいます。
今回の目的は、ChatGPT 自体を削除せず、こうした URL を Windows 側の普段使っているブラウザで開くことです。
今回の設定の仕組み
次の経路で Windows のブラウザを呼び出します。
WSL 内の CLI／xdg-open
↓
windows-browser.desktop
↓
~/.local/bin/windows-browser
↓
Windows の rundll32.exe
↓
Windows 側のデフォルトブラウザ
Windows の Chrome や Edge の実行ファイルを直接指定するのではなく、Windows の URL ハンドラーを呼び出す構成にします。
作成するファイルは、次の2つです。
| ファイル | 役割 |
|---|---|
~/.local/bin/windows-browser |
Windows 側へ URL を渡すランチャー |
~/.local/share/applications/windows-browser.desktop |
ランチャーを Linux 側のアプリとして登録するエントリ |
まずこの2つを作成し、最後に HTTP・HTTPS のデフォルトアプリとして設定します。
1. 現在のデフォルトブラウザ設定を確認する
変更前の状態を確認します。
xdg-settings get default-web-browser
xdg-mime query default x-scheme-handler/http
xdg-mime query default x-scheme-handler/https
GIO 側の状態も確認します。
gio mime x-scheme-handler/http
gio mime x-scheme-handler/https
元の設定に戻せるよう、出力を控えておきます。
また、ブラウザ選択用の環境変数も確認します。
printf 'BROWSER=%s\n' "$BROWSER"
printf 'GH_BROWSER=%s\n' "$GH_BROWSER"
過去にブラウザ起動の回避策を設定した場合は、その値が残っている可能性があります。たとえば、/bin/true や別ブラウザを指定していた場合は、後で実際の CLI の動作を確認するときに注意します。
2. Windows のブラウザを開くランチャーを作る
ユーザー用のディレクトリに、ランチャースクリプトを作成します。
mkdir -p "$HOME/.local/bin"
cat > "$HOME/.local/bin/windows-browser" <<'EOF'
#!/bin/sh
exec /mnt/c/Windows/System32/rundll32.exe \
url.dll,FileProtocolHandler "$@"
EOF
chmod 755 "$HOME/.local/bin/windows-browser"
作成したランチャーを直接実行します。
"$HOME/.local/bin/windows-browser" https://example.com
ここで Windows 側のデフォルトブラウザが開くことを確認します。
Permission deniedが出た場合は、後述の「ランチャーの実行時にPermission deniedが出る」を先に確認してください。この直接実行が成功するまでは、
.desktopや URL の関連付けを変更しても、起動経路全体の問題は解消しません。
3. デスクトップエントリを作成する
ランチャーを Linux 側のアプリとして登録するため、.desktop ファイルを作成します。
mkdir -p "$HOME/.local/share/applications"
cat > "$HOME/.local/share/applications/windows-browser.desktop" <<EOF
[Desktop Entry]
Type=Application
Name=Windows Default Browser
Exec=$HOME/.local/bin/windows-browser %u
Terminal=false
MimeType=x-scheme-handler/http;x-scheme-handler/https;text/html;
Categories=Network;WebBrowser;
EOF
このコマンドでは、ファイル作成時に $HOME が展開されます。
cat "$HOME/.local/share/applications/windows-browser.desktop"
今回の環境では、次の内容になりました。
[Desktop Entry]
Type=Application
Name=Windows Default Browser
Exec=/home/yuhri/.local/bin/windows-browser %u
Terminal=false
MimeType=x-scheme-handler/http;x-scheme-handler/https;text/html;
Categories=Network;WebBrowser;
%u は、起動時に渡される URL の位置を示します。
この例は、ホームディレクトリのパスに空白を含まない環境を対象としています。パスに空白を含む場合は、
Execの引用・エスケープを別途確認してください。
デスクトップエントリを検証する
必要なツールをインストールします。
sudo apt install desktop-file-utils
書式を検証し、アプリケーションの MIME データベースを更新します。
desktop-file-validate \
"$HOME/.local/share/applications/windows-browser.desktop"
update-desktop-database "$HOME/.local/share/applications"
続けて、.desktop を経由して起動します。
gio launch \
"$HOME/.local/share/applications/windows-browser.desktop" \
https://example.com
ここでも Windows 側のブラウザが開くことを確認してください。
この時点で、次の2段階が動作していることになります。
- ランチャーから Windows 側のブラウザを開ける
-
.desktop経由でもランチャーを起動できる
4. HTTP・HTTPS のデフォルトアプリに設定する
今回、最終的に成功した登録方法は gio mime でした。
gio mime x-scheme-handler/http windows-browser.desktop
gio mime x-scheme-handler/https windows-browser.desktop
次のように表示されます。
Set windows-browser.desktop as the default for x-scheme-handler/http
Set windows-browser.desktop as the default for x-scheme-handler/https
設定結果を確認します。
gio mime x-scheme-handler/http
gio mime x-scheme-handler/https
HTTPS の場合、既定アプリが次のようになっていれば設定できています。
Default application for “x-scheme-handler/https”: windows-browser.desktop
xdg-mime 側からも確認します。
xdg-mime query default x-scheme-handler/http
xdg-mime query default x-scheme-handler/https
期待する出力は次のとおりです。
windows-browser.desktop
windows-browser.desktop
最後に、URL のデフォルト起動経路を確認します。
xdg-open https://example.com
Windows 側のブラウザが開けば、関連付けを含めた動作確認は完了です。
なお、ここで設定しているのは主に HTTP・HTTPS の URL ハンドラーです。ローカルの HTML ファイルをどのアプリで開くかは、別の関連付けになります。
5. GitHub CLI・Claude Code で動作確認する
本来の目的だった認証操作を確認します。
gh auth login
claude auth login
今回の環境では、どちらの認証操作でも ChatGPT 内のブラウザではなく、Windows 側のデフォルトブラウザが起動することを確認できました。
これで、認証のたびに ChatGPT アプリをアンインストールする必要はなくなりました。
トラブルシューティング
ここからは、今回の設定中に遭遇した問題と、その切り分けをまとめます。
ランチャーの実行時に Permission denied が出る
今回、最初に遭遇したエラーは次のものでした。
/home/yuhri/.local/bin/windows-browser: 2:
exec: /mnt/c/Windows/System32/rundll32.exe: Permission denied
ランチャー自体には実行権限がありましたが、その呼び出し先である rundll32.exe に実行ビットがありませんでした。
ls -l /mnt/c/Windows/System32/rundll32.exe
-r--r--r-- ... /mnt/c/Windows/System32/rundll32.exe
マウント設定を確認する
findmnt -T /mnt/c/Windows/System32/rundll32.exe \
-o TARGET,FSTYPE,OPTIONS
cat /etc/wsl.conf
今回の /etc/wsl.conf には、次の設定がありました。
[automount]
mountFsTab=true
options="metadata,umask=022,fmask=111"
実際のマウントオプションにも fmask=111 が反映されていました。
/mnt/c 9p ... metadata;umask=022;fmask=111;...
今回の環境では、この実行ビットを落とす設定が Windows プログラムの起動を妨げていました。
ファイル単体の chmod は失敗した
まず、対象ファイルだけに実行権限を追加しようとしました。
chmod u+x /mnt/c/Windows/System32/rundll32.exe
しかし、次のエラーになりました。
chmod: changing permissions of
'/mnt/c/Windows/System32/rundll32.exe': Permission denied
このログだけでは、権限変更が拒否された詳細な理由までは断定できません。
今回は、Windows のシステムファイルに対する権限変更を続けるのではなく、WSL のマウント設定を修正しました。
fmask=111 を削除する
まずバックアップしてから編集します。
sudo cp -a /etc/wsl.conf \
"/etc/wsl.conf.bak.$(date +%Y%m%d-%H%M%S)"
sudoedit /etc/wsl.conf
変更したのは、次の1行だけです。
[automount]
mountFsTab=true
-options="metadata,umask=022,fmask=111"
+options="metadata,umask=022"
[boot]、[user]、[network] など、ほかの設定はそのまま残します。
この変更は
rundll32.exeだけに限定されません。自動マウントされる Windows ドライブ上のファイルの権限表示・実行可否に影響します。意図的に
fmask=111を設定している場合は、その目的と変更の影響を確認してください。ランチャーの直接実行が既に成功している環境では、この変更は不要です。
作業を保存してから、Windows の PowerShell で実行します。
wsl --shutdown
実行中のすべての WSL ディストリビューションが停止するため、ほかの WSL 環境で動かしている処理にも注意してください。
Ubuntu を起動し直し、確認します。
findmnt -T /mnt/c/Windows/System32/rundll32.exe \
-o TARGET,FSTYPE,OPTIONS
ls -l /mnt/c/Windows/System32/rundll32.exe
今回の環境では、fmask=111 がなくなり、次の権限表示になりました。
-r-xr-xr-x ... /mnt/c/Windows/System32/rundll32.exe
その後、ランチャーの直接実行で Windows のブラウザが開くようになりました。
"$HOME/.local/bin/windows-browser" https://example.com
ランチャーは動くが、デフォルトアプリに設定できない
Windows 側のブラウザを直接起動できるようになった後も、最初の .desktop では関連付けがうまくいきませんでした。
当初は次の指定を含めていました。
Exec="/home/yuhri/.local/bin/windows-browser" %u
NoDisplay=true
この状態で設定しても、
xdg-mime default windows-browser.desktop x-scheme-handler/http
xdg-mime default windows-browser.desktop x-scheme-handler/https
xdg-settings set default-web-browser windows-browser.desktop
問い合わせ結果は引き続き次のままでした。
chatgpt.desktop
.desktop の配置先を /usr/local/share/applications や /usr/share/applications に変えるだけでも解決しませんでした。
最終的には、次の変更と登録を行うことで成功しました。
-
Execを、空白を含まない絶対パスを引用符で囲まない形に変更する -
NoDisplay=trueを削除する -
desktop-file-validateで検証する -
update-desktop-databaseを実行する -
gio launchで直接起動を確認する -
gio mimeで HTTP・HTTPS のデフォルトアプリに設定する
複数の変更をまとめて行っているため、Exec の引用符、NoDisplay=true、登録方法のどれが決定的だったかは、今回の検証だけでは切り分けていません。
本記事では、原因を1つに断定するのではなく、実際に動作した最小構成と手順を掲載しています。
設定したはずなのに別のブラウザが開く
まず、CLI 用の環境変数を確認します。
printf 'BROWSER=%s\n' "$BROWSER"
printf 'GH_BROWSER=%s\n' "$GH_BROWSER"
過去の設定が残っていれば、その意図を確認して修正します。
今回のランチャーへ明示的に統一したい場合は、現在のシェルで次のように設定できます。
export BROWSER="$HOME/.local/bin/windows-browser"
export GH_BROWSER="$HOME/.local/bin/windows-browser"
永続化する場合は、既存設定との重複に注意してシェル設定ファイルを編集してください。
ただし、今回のように URL の関連付けだけで目的を達成できているなら、追加の環境変数設定は必須ではありません。
次に、関連付けの結果を確認します。
gio mime x-scheme-handler/https
xdg-mime query default x-scheme-handler/https
参照している設定ファイルを調べたい場合は、デバッグ出力を使います。
XDG_UTILS_DEBUG_LEVEL=2 \
xdg-mime query default x-scheme-handler/https
デスクトップ環境やユーザー設定の場所も確認対象です。
printf 'XDG_CURRENT_DESKTOP=%s\n' "$XDG_CURRENT_DESKTOP"
printf 'XDG_CONFIG_HOME=%s\n' "$XDG_CONFIG_HOME"
printf 'XDG_DATA_HOME=%s\n' "$XDG_DATA_HOME"
printf 'XDG_DATA_DIRS=%s\n' "$XDG_DATA_DIRS"
段階ごとにテストすると切り分けやすい
| テスト | 確認する段階 |
|---|---|
"$HOME/.local/bin/windows-browser" https://example.com |
Windows プログラムの呼び出し |
gio launch ...windows-browser.desktop https://example.com |
デスクトップエントリ経由の起動 |
gio mime x-scheme-handler/https |
GIO 側の関連付け |
xdg-mime query default x-scheme-handler/https |
XDG 側の既定アプリ |
xdg-open https://example.com |
URL 起動経路全体 |
gh auth login・claude auth login
|
実際の利用場面 |
ランチャーが動かない状態で .desktop の配置先だけを変えたり、既定アプリを繰り返し設定したりしても、原因が分かりにくくなります。
下の層から順に確認するのがポイントです。
補足：ブラウザ候補の並び順を調整する
デフォルトアプリを変更した後、gio mime の結果では、次のように複数の候補が表示されました。
Registered applications:
windows-browser.desktop
chatgpt.desktop
helium.desktop
mercury-browser.desktop
ChatGPT を候補に残しつつ最後尾にしたい場合は、mimeapps.list の関連付け設定を調整する方法があります。
以下は、その設定例です。この順序への変更後の表示までは、今回の記事の動作確認範囲に含めていません。
編集前に既存ファイルをバックアップします。
mkdir -p "$HOME/.config"
if [ -f "$HOME/.config/mimeapps.list" ]; then
cp -a "$HOME/.config/mimeapps.list" \
"$HOME/.config/mimeapps.list.bak.$(date +%Y%m%d-%H%M%S)"
fi
~/.config/mimeapps.list の該当箇所を、次のように編集します。
[Default Applications]
x-scheme-handler/http=windows-browser.desktop;
x-scheme-handler/https=windows-browser.desktop;
[Added Associations]
x-scheme-handler/http=windows-browser.desktop;helium.desktop;mercury-browser.desktop;chatgpt.desktop;
x-scheme-handler/https=windows-browser.desktop;helium.desktop;mercury-browser.desktop;chatgpt.desktop;
既存ファイル全体を上書きせず、ほかの MIME タイプの設定を残してください。同名セクションや同じキーを重複追加しないようにします。
設定後は、次で結果を確認します。
gio mime x-scheme-handler/http
gio mime x-scheme-handler/https
候補一覧の表示順と、実際のデフォルトアプリは分けて考える必要があります。ChatGPT が候補に表示されていても、デフォルトが windows-browser.desktop であれば、それだけで ChatGPT が自動起動することを意味するわけではありません。
まとめ
今回の問題は、次の2段階に分かれていました。
-
/mnt/cのfmask=111により、ランチャーからrundll32.exeを起動できなかった - ランチャーが動くようになっても、最初の
.desktopと登録手順ではデフォルトアプリとして採用されなかった
マウント設定を修正し、最小構成の .desktop を作成して、gio mime で HTTP・HTTPS のデフォルトアプリに設定することで解消しました。
最終的に、次のすべてで Windows 側のブラウザが起動することを確認できました。
xdg-open https://example.com
gh auth login
claude auth login
意図しないアプリで認証ページが開く場合は、アプリを削除する前に、URL の関連付けとブラウザの起動経路を確認してみてください。