magpie unter WSL einrichten und unter Windows installieren: wo es laufen soll (November 2026)

Ja. Stand 2026-11-10 steht im README, dass unter Windows auch Agenten in WSL-Distributionen angebunden und ihre Sitzungen mitgezählt werden. magpie prüft nur laufende Distributionen und startet beim Auflisten nie eine gestoppte; ist Detect agents in WSL in den Einstellungen aus, startet magpie überhaupt kein wsl.exe. Die Referenz beschreibt außerdem, wie magpie daemon und magpie web innerhalb von WSL funktionieren.

Der Maintainer yetone schrieb in Issue #2198, dass der Fix zusammengeführt ist und mit v0.1.1763 ausgeliefert wird; prüfen Sie daher zuerst, ob magpie unter Windows diese oder eine neuere Version hat. #2198 beschreibt ein Codex, das in einer WSL-Distribution angebunden ist, ein Modell anfordert, das magpie nicht bereitstellt, und einen 404 erhält. Mit dem Fix liest magpie, wenn das Windows-Codex kein Ersatzmodell vorgibt, die erste laufende Distribution, deren config.toml model_provider = "magpie" enthält, und verwendet deren model. Das Issue ist weiterhin offen (wieder geöffnet): yetone schrieb, dass kein echtes Codex in einer echten Distribution getestet wurde, und das Issue wartet auf jemanden mit einer echten WSL-Einrichtung.

Damit magpie überhaupt kein wsl.exe startet, nennt die offizielle Dokumentation einen Schalter: Detect agents in WSL in den Einstellungen ausschalten; dann sucht magpie auch keine Agenten in WSL mehr. Das Verhalten ist Thema von Issue #3175: Am 2026-10-21 schrieb der Melder, dass magpie.exe nach wsl --shutdown etwa alle 60 Sekunden wsl.exe aufrief und die Distribution wieder auf Running ging, und bat um einen Schalter oder eine geringere Häufigkeit; am 2026-10-22 schloss er das Issue selbst ohne Kommentar als completed. Die aktuelle Anbindungs-Dokumentation sagt, dass jede laufende Distribution einmal geprüft und eine gestoppte nie gestartet wird. Wie beides zusammenhängt, ist offiziell nicht gesagt.

Das ist Issue #3689, Stand 2026-11-10 offen, noch ohne Antwort des Maintainers und ohne offizielles Vorgehen. Beobachtungen eines Mitwirkenden im Issue: Beim Melder zeigte die Modelladresse von Copilot in VS Code auf 127.0.0.1:3425, und der VS-Code-Server in WSL scheiterte mit connect ECONNREFUSED 127.0.0.1:3425; später schrieb er, dass der Netzwerkmodus Mirrored funktioniert und NAT nicht, und dass es mit eingeschalteter Freigabe im lokalen Netz von magpie sowie der IP des Windows-Hosts und einem Gateway-Schlüssel, von Hand in VS Code eingetragen, funktionierte, der Button zum Neuverbinden im Agents-Bereich die alten VS-Code-Einstellungen aber wieder zurückschreibt. Zu NAT sagt die offizielle Dokumentation, dass die von magpie angebundenen WSL-Agenten die Windows-Adresse im WSL-Netz nutzen und die Windows-Firewall entscheidet, ob sie hineinkommen.

Stand 2026-11-10 beschreibt die offizielle Dokumentation die Adressen für die Netzwerkmodi mirrored, NAT und bridged; WSL1 wird in Issue #3333 (offen) diskutiert, eine Antwort des Maintainers steht aus. Beim Melder funktionierte unter WSL1 curl http://127.0.0.1:3425/v1/models, magpie trug aber eine Nicht-Loopback-Adresse in ANTHROPIC_BASE_URL von Claude Code ein. Beobachtung eines Mitwirkenden im Issue: WSL 1 teilt den Netzwerk-Stack von Windows, daher solle die Adresse 127.0.0.1 sein; er hat einen Patch veröffentlicht und vermerkt, dass er ihn nicht an einer echten WSL1-Distribution getestet hat.

Ja. Fügen Sie QCode in magpie als Anbieter mit den drei Adressen aus dem magpie-Leitfaden von QCode hinzu: anthropic https://api.qcode.cc/api, chat https://api.qcode.cc/openai/v1 und responses https://api.qcode.cc/openai; Claude läuft nur über /api. Die Adressen sind dieselben, ob magpie unter Windows oder innerhalb von WSL läuft. Ohne magpie zeigt die Seite zu Umgebungsvariablen von QCode unter https://docs.qcode.cc/de/docs/getting-started/environment ANTHROPIC_BASE_URL und ANTHROPIC_AUTH_TOKEN für Claude Code.