magpie の WSL 設定と Windows への導入:どちらで動かすか(2026 年 11 月)
2026-11-10 時点で、magpie の README には、Windows では WSL のディストリビューション内のエージェントも接続されると書かれています。そのため、magpie を Windows で動かし、Claude Code と Codex は WSL に置いたままにでき、それぞれ Agents ページに独立した項目として表示されます。Windows 用のファイルは magpie-windows-amd64.exe(ARM 版は magpie-windows-arm64.exe)で、magpie.exe は他の OS と同じコマンドを受け付けます。公式リファレンスには、WSL 内の magpie daemon も Linux と同じように動作するとあります。QCode の三つのプロバイダーアドレスは、magpie をどこで動かしても同じです。
更新日 2026-11-10
このツールを QCode エンドポイントに接続。Claude・GPT・中国系モデルを 1 キーで。
- トークン単位の課金・最新単価は /models
- カード(Visa / Mastercard)・Apple Pay・Google Pay・暗号資産で支払い可能
- チャージ後すぐにセルフサービスで開通
公式情報の四つのポイント
Windows:アプリのファイルと magpie.exe
GitHub のリリースでは、Windows 向けに magpie-windows-amd64.exe(ARM 版は magpie-windows-arm64.exe)、ターミナル専用ビルドとして magpie-cli-windows-amd64.exe が公開されています。サイトに記載の動作環境は Windows 10 以降です。magpie.exe は他の OS と同じコマンドを受け付けます。
WSL のエージェントは Windows の magpie が接続
README によると、Windows では WSL のディストリビューション内のエージェントも接続され、そのセッションも集計されます。接続の仕組みを説明する公式ドキュメントによると、見つかった各エージェントは独立した項目になり、その設定ファイルはディストリビューションの \\wsl.localhost 共有を通じて編集されます。
WSL 内に入れる場合:daemon と web
リファレンスによると、systemd を有効にすれば(/etc/wsl.conf に [boot] systemd=true)、magpie daemon は WSL 内でも Linux と同じように動作します。ブラウザでアプリ画面を開く magpie web も、WSL や SSH で接続するサーバー向けに挙げられています。
QCode のアドレスは変わりません
QCode の magpie ガイドには、anthropic https://api.qcode.cc/api、chat https://api.qcode.cc/openai/v1、responses https://api.qcode.cc/openai が記載されています。magpie を Windows で動かしても WSL で動かしても、この三つを入力します。
magpie とは?WSL はどこに関わるのか
2026-11-10 時点で、magpie(GitHub リポジトリ yetone/magpie、MIT ライセンス)は手元のマシンでゲートウェイを動かし、各エージェントのモデルを一か所で選べるツールです。リポジトリの説明文は「Every agent's model. One place.」です。README によると、ゲートウェイは 127.0.0.1:3425 で OpenAI Chat、OpenAI Responses、Anthropic Messages、Gemini に対応し、Windows では WSL のディストリビューション内のエージェントも接続されます。エージェント接続の公式ドキュメントが仕組みを説明しています。magpie は起動中の各ディストリビューションを一度だけスキャンし、停止中のものは起動しません。ディストリビューションのホーム配下のフォルダ、またはそこにあるコマンドでエージェントを見つけ、そのファイルを \\wsl.localhost 経由で編集します。ゲートウェイのアドレスとキーは、ディストリビューションのネットワーク方式(mirrored または NAT)に従います。ゲートウェイがループバックだけで待ち受けている間、NAT では WSL ネットワーク上の Windows 側アドレスでも提供されます。
2026-10-27:WSL の Codex で起きる 404 の修正をメンテナーがマージ
2026-10-27、メンテナーの yetone は Issue #2198 で、修正をマージし v0.1.1763 に含めたと書きました。修正後は、Windows 側の Codex の config.toml に代替モデルの指定がない場合、magpie は Codex が見つかった起動中のディストリビューションから、model_provider = "magpie" を含む最初の config.toml を探し、その model を使います。停止中のディストリビューションは開きません。yetone は、実際のディストリビューションでの実際の Codex はまだ試していないとも書き、実際の WSL 環境を持つ人が確認するまで Issue を開いたままにしています。
タイムライン
Issue #2198 が起票されました。WSL の Codex が、magpie の提供していないモデル名で 404 を受け取るという内容です。
yetone が #2198 の修正をマージしました。実際の WSL での確認のため、Issue は開いたままです。
2026-11-10 に GitHub と公式ドキュメントで再確認しました。#2198、#3333、#3689、#4453 はオープンで、#3175 は報告者がクローズしています。
magpie が文書化していることと、まだ明らかでないこと
公式ドキュメントとメンテナーが明記していること
① Windows 用ファイルは magpie-windows-amd64.exe、magpie-windows-arm64.exe、ターミナル専用の magpie-cli-windows-amd64.exe で、動作環境は Windows 10 以降です。② README によると、Windows では WSL のディストリビューション内のエージェントも接続され、そのセッションも集計されます。③ 接続のドキュメントによると、WSL の各エージェントは独立した項目で、\\wsl.localhost 経由で編集されます。一覧表示では停止中のディストリビューションを起動しませんが、項目のフィールドを変更するとファイルが書き込まれ、ディストリビューションが起動します。設定で Detect agents in WSL をオフにすると、magpie は wsl.exe を一切起動しません。④ ゲートウェイのアドレスとキーは、ディストリビューションのネットワーク方式(mirrored または NAT)に従います。NAT ではゲートウェイが WSL ネットワーク上の Windows 側アドレスでも提供され、WSL から入れるかどうかは Windows のファイアウォールが決めます。接続できないディストリビューションには、通すためのファイアウォールのルールが表示されます。⑤ start ガイドによると、magpie 自身の設定、プロバイダー、使用量は、Windows ではユーザーフォルダ内の .config\magpie に保存されます。⑥ メンテナーの yetone は #2198(WSL の Codex、404)で、修正はマージ済みで、実際の WSL 環境で確認されるまで Issue を開いておくと書いています。
まだ公式に説明されていないこと
2026-11-10 時点:① 導入先:WSL への段階的な導入ガイドはなく、Windows と WSL のどちらに入れるのがよいかも書かれていません。install.sh には macOS と Linux の分岐があり、リファレンスは WSL 内の magpie daemon と magpie web に触れています。② WSL1(#3333、オープン)。Issue のコントリビューターの観察:WSL 1 は Windows とネットワークスタックを共有するので、Claude Code には 127.0.0.1 を書くべきだとしてパッチを公開しましたが、実際の WSL1 ディストリビューションでは試していないと書いています。メンテナーはまだ返信していません。③ NAT の WSL で開いた VS Code(#3689、オープン)。Issue のコントリビューターの観察:報告者は、ネットワーク方式を Mirrored にすると動き、NAT では動かないと書いています。メンテナーはまだ返信していません。④ #3175 とドキュメントの並記:#3175 は、wsl --shutdown の後に magpie.exe が約 60 秒ごとに wsl.exe を呼び出すと報告し、2026-10-22 に報告者がコメントなしで completed としてクローズしました。現在の接続ドキュメントには、起動中のディストリビューションだけをスキャンし、停止中のものは起動しないとあります。両者の関係は公式には説明されていません。⑤ SSH 越しの Claude Desktop(#4453、オープン):コントリビューターが、どのアドレスを書き込むかはプロダクトの判断だと書き、メンテナーに委ねています。
magpie を動かす二つの場所
magpie は Windows、エージェントは WSL
Windows アプリ、またはターミナル専用の magpie-cli-windows-amd64.exe をインストールします。README によると、起動中の WSL ディストリビューション内のエージェントも接続され、Agents ページに独立した項目として表示されます。Windows では magpie はサービスとしては動かず、リファレンスはログイン時に magpie を開き、ゲートウェイも動かす magpie autostart on を挙げています。
magpie を WSL 内に入れる
ディストリビューション内で公式インストーラー curl -fsSL https://usemagpie.ai/install.sh | sh を実行します。スクリプトには Linux 向けの分岐があり、Linux でデスクトップ環境がない場合はターミナル版を入れます。systemd を有効にしたら magpie daemon install でゲートウェイを常駐させるか、magpie web でアプリ画面をブラウザで開きます。リファレンスはどちらも WSL 内での使い方として説明しています。
WSL と QCode で magpie を設定する手順
① Windows で usemagpie.ai または GitHub Releases から magpie-windows-amd64.exe(ARM 版は magpie-windows-arm64.exe)をダウンロードします。リファレンスには、初回起動の前に SmartScreen が確認を求めることがあると書かれています。② QCode を追加します。Providers → Add provider で入力するか、ターミナルで magpie provider add QCode anthropic=https://api.qcode.cc/api url=https://api.qcode.cc/openai/v1 responses=https://api.qcode.cc/openai key=cr_xxx を実行します(2026-11-10 時点、magpie 0.1.3533 の Linux ターミナル版で実測したところ、このコマンドで追加できました)。anthropic はルートで /v1 は付けません。url は chat のアドレスで、/v1 で終わります。③ WSL のディストリビューションを起動して Agents ページを開くと、起動中のディストリビューションで見つかった Claude Code や Codex などが、それぞれ独立した項目として表示されます。Claude Code には qcode/claude-sonnet-5-5、Codex には qcode/gpt-6.1-sol を選びます。④ エージェントが見当たらない場合は、設定の Detect agents in WSL がオンか確認してください。接続のドキュメントによると、スキャンは sh -l で実行され(~/.profile は読み、~/.bashrc は読みません)、nvm、fnm、volta、pnpm、bun、~/.local/bin などの場所でもコマンドを探します。⑤ NAT でディストリビューションがゲートウェイに届かない場合は、magpie が表示するファイアウォールのルールで通信を許可します。⑥ magpie を WSL 内で動かす場合は、ディストリビューションで curl -fsSL https://usemagpie.ai/install.sh | sh を実行し、systemd を有効にしてから(/etc/wsl.conf に [boot] systemd=true)、magpie daemon install を実行します。⑦ magpie を使わない場合は、QCode の環境変数のページのとおり、WSL のシェルで ANTHROPIC_BASE_URL=https://api.qcode.cc/api と ANTHROPIC_AUTH_TOKEN=cr_xxx を設定します。
Windows と WSL の magpie で QCode を使う
2026-11-10 時点で、QCode の API キー一つで Anthropic 互換と OpenAI 互換の両方のインターフェースを使え、QCode の magpie ガイドには三つのアドレスが記載されています:anthropic https://api.qcode.cc/api(ルート、/v1 なし)、chat https://api.qcode.cc/openai/v1、responses https://api.qcode.cc/openai。magpie を Windows で動かしても WSL 内で動かしても同じです。Claude は /api だけを経由し、GPT は OpenAI の二つのアドレスを使い、中国系モデルは chat と anthropic のどちらでも使えます。課金はトークン単位で、モデルごとの単価は /models にあります。三つの手順です。① 登録してチャージします(Alipay などの主要な決済方法)。② 個人プランかクォータパックを購入し、cr_ から始まる API キーをコピーします。③ https://docs.qcode.cc/ja/docs/ide/magpie の手順どおりに magpie に QCode を追加します。月額プランをご希望でない場合は、クォータパックが $4 から。7 日以内に使い切る一度限りの枠です。個人プランをお使いで枠が足りないときはブースターパックを追加できます。
よくある質問
magpie は WSL に対応していますか?
はい。2026-11-10 時点の README によると、Windows では WSL のディストリビューション内のエージェントも接続され、そのセッションも集計されます。magpie は起動中のディストリビューションだけをスキャンし、一覧表示で停止中のものを起動することはありません。設定で Detect agents in WSL をオフにすると、magpie は wsl.exe を一切起動しません。リファレンスには、WSL 内で magpie daemon と magpie web を使う方法も書かれています。
WSL の Codex がモデル名で 404 になります。どうすればよいですか?
メンテナーの yetone は Issue #2198 で、修正をマージし v0.1.1763 に含めたと書いているため、まず Windows の magpie がこのバージョン以降か確認してください。#2198 は、WSL のディストリビューション内で接続された Codex が magpie の提供していないモデルを要求し、404 になる問題です。修正後は、Windows 側の Codex に代替モデルの指定がない場合、magpie は config.toml に model_provider = "magpie" を含む最初の起動中ディストリビューションを読み、その model を使います。Issue は(再オープンされて)オープンのままです。yetone は、実際のディストリビューションでの実際の Codex はまだ試していないと書いており、実際の WSL 環境を持つ人の確認を待っています。
wsl --shutdown の後、WSL のディストリビューションがまた起動するのはなぜですか?
magpie に wsl.exe を一切起動させたくない場合、公式ドキュメントが示すスイッチは設定の Detect agents in WSL です。オフにすると、WSL 内のエージェントも探さなくなります。この現象は Issue #3175 で報告されました。報告者は 2026-10-21 に、wsl --shutdown の後に magpie.exe が約 60 秒ごとに wsl.exe を呼び出し、ディストリビューションが Running に戻ると書き、スイッチの追加か頻度の低減を求めました。2026-10-22 に本人がコメントなしで completed としてクローズしています。現在の接続ドキュメントには、起動中の各ディストリビューションを一度だけスキャンし、停止中のものは起動しないとあります。両者の関係は公式には説明されていません。
WSL で開いた VS Code から magpie を使えません(ECONNREFUSED 127.0.0.1:3425)
これは Issue #3689 で、2026-11-10 時点でオープンのまま、メンテナーの返信や公式の手順はまだありません。以下は Issue のコントリビューターの観察です。報告者の VS Code では Copilot のモデルのアドレスが 127.0.0.1:3425 になっており、WSL 内の VS Code サーバーが connect ECONNREFUSED 127.0.0.1:3425 で失敗しました。報告者は後に、ネットワーク方式を Mirrored にすると動き NAT では動かないこと、magpie のローカルネットワーク共有をオンにして VS Code に Windows ホストの IP とゲートウェイキーを手動で入れると使えたものの、Agents パネルの再接続ボタンで VS Code の設定が元に戻されることを書いています。NAT について公式ドキュメントは、magpie が接続する WSL のエージェントは WSL ネットワーク上の Windows のアドレスを使い、入れるかどうかは Windows のファイアウォールが決めると説明しています。
WSL1 では Claude Code はどのアドレスを使いますか?
2026-11-10 時点で、公式ドキュメントは mirrored、NAT、bridged の各ネットワーク方式のアドレスを説明しており、WSL1 は Issue #3333(オープン)で議論中で、メンテナーはまだ返信していません。報告者の WSL1 では curl http://127.0.0.1:3425/v1/models が通るのに、magpie は Claude Code の ANTHROPIC_BASE_URL にループバック以外のアドレスを書き込みました。Issue のコントリビューターの観察:WSL 1 は Windows とネットワークスタックを共有するので 127.0.0.1 にすべきだとしてパッチを公開しましたが、実際の WSL1 ディストリビューションでは試していないと書いています。
WSL に入れた magpie で QCode を使えますか?
はい。QCode の magpie ガイドにある三つのアドレスで、QCode をプロバイダーとして追加します:anthropic https://api.qcode.cc/api、chat https://api.qcode.cc/openai/v1、responses https://api.qcode.cc/openai。Claude は /api だけを経由します。magpie を Windows で動かしても WSL 内で動かしても、アドレスは同じです。magpie を使わない場合は、QCode の環境変数のページ https://docs.qcode.cc/ja/docs/getting-started/environment に、Claude Code 向けの ANTHROPIC_BASE_URL と ANTHROPIC_AUTH_TOKEN が載っています。
情報源
yetone/magpie リポジトリ(main ブランチ)の README、リファレンス、install.sh、エージェント接続とゲートウェイのルーティングに関するドキュメント、usemagpie.ai のページ(ホーム、docs/start、docs/remote、docs/docker)、GitHub Releases API、Issue #2198、#3175、#3333、#3689、#4453 とそのコメント。いずれも 2026-11-10 に読みました。QCode:docs.qcode.cc の magpie と環境変数のページ、qcode.cc/models、/pay-as-you-go、/pricing を 2026-11-10 に取得。
関連記事
クォータパック
一度限りの枠を 7 日間使えるパックで、サブスクリプションは不要です。モデルごとの単価は /models にあります。
magpie の使い方:Claude Code と Codex のローカルゲートウェイ(2026-11)
magpie の設定:インストールとアンインストールのコマンド、プロバイダーを追加する三つの方法、Claude Code と Codex へのモデル選択、QCode の三つのアドレス。
magpie が動かない:401・405 エラーの原因と対処(2026-11)
magpie のよくあるエラーの公式の原因と対処:切り替えが反映されない、Docker の 401、ZCode の 405、provider test の 400、モデルが見えない。
暗号資産チャージガイド
9 通貨・56 ネットワーク、手数料 0 で AI コーディング API クレジットを購入。
このページの記述は 2026-11-10 に magpie のリポジトリとサイトに照らして確認したもので、公式ページが優先します。magpie は一日に複数のビルドを公開するため、メニュー名と動作はインストールしたバージョンに従い、オープンの Issue も変わることがあります。QCode のモデルの提供状況は /models に従います。