ドキュメント · ガイド

エージェントが magpie を通らなくなったとき

magpie はエージェントを接続するとき、その設定に何を書いたかを記録します。以後エージェントページは二つのことを確かめ続けます。設定がまだ magpie の書いたとおりか、そして設定が正しいとき、エージェントの最近のリクエストが実際に magpie のゲートウェイに届いたか。合わないときは、そのエージェントの行に理由と直す手段が出ます。たいていは 再適用（ステータス行では 再接続）、アドレスが応答しないときやプロキシが間にあるときは 直し方 です。magpie が出す五つの表示を順に説明します。

問題にならないものが二つあります。エージェント自身のモデル選択で magpie のモデルから別の magpie のモデルに移すのは表示されません。また、あなたが手で書いた magpie という名前のプロバイダーはあなたのものなので、magpie は表示も上書きもしません。

「magpie を経由しなくなりました — 設定が変更されています」

モデルはまだ magpie のものですが、リクエストを magpie に送る部分（ゲートウェイのアドレスなど）が変わっています。手での編集、エージェントの更新による設定の書き換え、別のツールなどが原因です。

  1. 再適用 を押すmagpie が書いた内容をもう一度書き、記録を更新します。表示は消えます。
  2. エージェントを再起動する多くのエージェントは起動時に設定を読むので、開いているものは開き直します。

「magpie の外で {model} から切り替えられました」

magpie が設定したのは magpie のモデルでしたが、今は magpie を通らないエージェント自身のモデルになっています。詳細には今の値と magpie が設定した値が出ます。選べるのは二つです。

「magpie を経由せずに使われました — 適用後に再起動してください」

設定は正しいのに、magpie が設定した後にエージェントが使われ、そのリクエストが一つも magpie に届いていません。多いのは、magpie が設定を変える前から開いていて古い設定のまま動いている場合です。環境変数など、ファイルの外のものが上書きしていることもあります。詳細にはどれかが出ます。

どれもエージェントを終了して開き直せば直ります。先に 再適用 を押すと記録が更新され、それ以前の使用は数えられなくなります。

「設定済みですが、magpie につなぐアドレスから応答がありません」

設定は正しいものの、エージェントが magpie につなぐのはこのコンピューターのループバック（127.0.0.1）以外のアドレスで、そこが応答せず、magpie 自身はここで正常に応答しています。たいていは WSL のエージェントか、自分で用意した転送です。magpie はそのアドレスをバックグラウンドでここから試します。

WSL のエージェントが、magpie が WSL 向けに待ち受けるアドレスを指しているのに応答がないときは、Windows ファイアウォールが WSL を遮っています。Windows に聞かれたら magpie を許可するか、管理者の PowerShell で次を実行します（-Program は magpie.exe の実際のパスで、詳細に完全なコマンドが出ます）。

ターミナル
New-NetFirewallRule -DisplayName 'magpie (WSL)' -Direction Inbound -Action Allow -Profile Any -InterfaceAlias 'vEthernet (WSL*)' -Program '…\magpie.exe'

WSL のネットワークは「パブリック」扱いなので、「プライベート」だけのルールでは足りません。Windows 11 なら .wslconfig でミラーモードにすると、WSL から 127.0.0.1 で magpie に届きます。

ターミナル
# %UserProfile%\.wslconfig
[wsl2]
networkingMode=mirrored

WSL 既定の NAT ネットワークでは、WSL から見た Windows のアドレスは何かが待ち受けているときだけ応答します。設定 › ネットワークと共有 › ローカルネットワークで共有 をオンにした magpie 自身（すべてのアドレスで待ち受け、他のコンピューターにはゲートウェイキーを求めます）か、自分で用意した転送（netsh interface portproxy。Windows の再起動後に設定し直しが要ることがあります）です。ここでは応答するのに WSL からつながらないなら、ファイアウォールです。WSL のネットワークにゲートウェイのポート（既定は 3425）を許可します。

WSL ディストリビューションから見た Windows のアドレスが変わったときは、詳細に新しいアドレスが出て、ボタンが {url} を使う になります。押すとエージェントがそこを指します。WSL 以外では、そのアドレスを magpie に転送していたものが止まっています。起動し直すか、エージェントをこのコンピューターの magpie のアドレスに向けてください。

「プロキシ経由で magpie につなぎますが、そのプロキシがリクエストを magpie に渡していません」

これは Codex の場合です。Codex は magpie 宛てのリクエストを環境変数やシステム設定のプロキシ経由で送り、そのプロキシが magpie に渡さないため、どのモデルでも毎ターン 502 Bad Gateway になります。magpie は Codex と同じやり方でどのプロキシを通るかを調べ（ターミナルの Codex はターミナルの環境、ChatGPT アプリの Codex はログインシェルの環境）、詳細にプロキシとその設定場所が出ます。直し方はどれか一つで足ります。

ターミナル
# ~/.zshrc
export NO_PROXY=127.0.0.1

そのあと Codex を終了して開き直します。

magpie から切断

すぐに直せないとき、またはそのエージェントで magpie を使いたくないときは、行メニューの magpie から切断 を選びます。magpie はエージェントの設定を接続前に戻し、設定した内容を忘れます。あとでまたつなぐときは エージェント ページで設定し直します。

よくある質問

エージェントでモデルを変えたら、設定が変更されたと出るのはなぜ？

変えた先が magpie を通らないモデルだからです。残すなら 現在の設定を維持、magpie に戻すなら 再適用 を押します。エージェント内で magpie のモデル同士を移すのは表示されません。

再適用しても magpie を経由せずに使われたと出る？

そのエージェントは magpie の設定より前から開いていて、古い設定で動いています。終了して開き直し、新しいリクエストが magpie に届けば表示は消えます。

WSL のエージェントが magpie につながらないときは？

多くは Windows ファイアウォールが WSL を遮っています。聞かれたら magpie を許可するか、詳細にある New-NetFirewallRule のコマンドを管理者の PowerShell で実行します。Windows 11 なら .wslconfig の networkingMode=mirrored でも直ります。

Codex が毎ターン 502 で、プロキシが渡していないと出る？

Codex の magpie 宛てのリクエストをプロキシが受け取っています。127.0.0.1 を直結にするか NO_PROXY に 127.0.0.1 を加え、Codex を開き直します。

関連ページ：Codex で DeepSeek・Kimi・GLM・Claude など他のモデルを使う、リモート magpie。ほかのエラーは よくあるエラーの直し方、または Discord で質問してください。