Diese Fehlersuche ist es absolut wert, einmal vollständig zu dokumentieren, weil sie so ziemlich alle typischen Fallstricke, in die Desktop‑KI‑Tools unter Windows am leichtesten treten, einmal komplett mitgenommen hat: benutzerdefinierte API, WSL, Windows native, PowerShell, PATH, Shim, Store‑Version mit eingebetteten Binaries – und außerdem „sieht aus wie plötzlich aufgetaucht, ist aber in Wirklichkeit ein alter, erneut getriggerter Altfehler“.
Zum Schluss zuerst das Fazit:
Was Codex Desktop unter Windows native wirklich komplett daran gehindert hat, überhaupt noch Befehle auszuführen, war nicht WSL, nicht das PowerShell‑Profile und auch nicht eine Versionsabweichung zwischen Desktop‑ und npm‑Variante, sondern ein versteckter Batch‑Shim in C:\\Users\\1\\AppData\\Local\\Programs\\Python\\Python313\\Scripts\\pwsh.cmd. Der Windows‑Command‑Executor von Codex wirft beim Starten dieses .cmd‑Wrappers mit Parametern direkt: batch file arguments are invalid – und damit sterben alle Befehle, bevor sie überhaupt ausgeführt werden.
1. Ausgangspunkt des Vorfalls: Es sah so aus, als wäre es „nach dem Wechsel zu WSL kaputtgegangen“
Die anfängliche Oberfläche des Problems hatte eigentlich zwei Ebenen:
- Nachdem in den Codex‑Einstellungen sowohl Agent als auch Integrated terminal auf WSL umgestellt wurden, begann der Desktop‑Client ständig neu zu verbinden und meldete:
Reconnecting... 1/5
...
stream disconnected before completion: error sending request for url (https://wuju.de5.net/v1/responses)
- Aber der Nutzer sagte klar: WSL bitte noch nicht reparieren – zuerst muss das ursprüngliche Windows‑native‑Problem gelöst werden, denn ursprünglich war native kaputt, deshalb wurde überhaupt erst auf WSL gewechselt.
Dieser Schritt ist wichtig, weil er zwei Probleme sauber trennt:
- Das WSL‑Thema wirkt eher wie ein Problem mit Netzwerk/Proxy/WSL‑Umgebung beim Zugriff auf eine Custom‑Endpoint.
- Das Windows‑native‑Thema ist, dass der lokale Command‑Executor selbst bereits defekt war.
Wenn man das nicht zuerst trennt, irrt man später ständig zwischen zwei unabhängigen Fehlern hin und her.
2. Erste Minimal‑Reproduktion: Nicht ein einzelner Befehl ist kaputt – „alle Befehle sterben vor der Ausführung“
Um zu klären, ob es Git, PowerShell oder Codex selbst ist, haben wir Minimaltests gemacht:
Write-Output hiGet-Locationgit status -sbcmd.exe /c echo hi
Das Ergebnis war extrem konsistent: alles meldete denselben Fehler:
execution error: Io(Error { kind: InvalidInput, message: \"batch file arguments are invalid\" })
Der Nutzen ist enorm, weil es direkt zeigt:
- Kein Git‑spezifisches Problem.
- Kein Problem eines bestimmten Working Directories.
- Kein PowerShell‑Profile‑Skript, das einen konkreten Befehl kaputtmacht.
- Nicht einmal ein „PowerShell umgehen“ via
cmd.exe /cfunktioniert.
Das heißt: Der Fehler sitzt in der „Command‑Start‑Schicht“, nicht im Zielbefehl.
3. Zweiter irreführender Punkt: Das integrierte Terminal ist doch normal – warum sagt Codex, es geht nicht?
Damals war im Thread ein Snapshot zu sehen, bei dem das integrierte Terminal normal aussah: Prompt kommt hoch, man sieht:
PowerShell 7.5.4
PS C:\\Users\\1\\0.0.90_0>
Das verleitet dazu zu glauben:
- Wenn das Terminal aufgeht, ist PowerShell selbst wohl okay.
- Dann ist es vermutlich ein Bug im eingebauten Runner von Codex.
Das ist nur halb richtig.
PowerShell selbst war tatsächlich nicht kaputt – aber in Codex Desktop bedeutet „Terminal kann angezeigt werden“ nicht automatisch, dass „der Command‑Executor des Agents die Shell erfolgreich starten und mit Parametern Befehle ausführen kann“. Das sind zwei unterschiedliche Ketten.
Das ist der erste große Gewinn dieser Fehlersuche:
Ein interaktives integriertes Terminal, das funktioniert, beweist nicht, dass die shell_command‑Kette des Agents funktioniert.
4. Dritte Fehlannahme: Verdacht, dass die Store‑Desktop‑Version ein altes Backend bündelt
Dann fiel etwas sehr Verdächtiges auf:
- In der Microsoft‑Store‑Desktop‑App war die gebundelte CLI/Runner‑Version
0.112.0-alpha.3 - Das global via npm installierte
@openai/codexwar bereits0.113.0
Das sieht stark nach Root Cause aus, weil „neue Desktop‑Hülle, altes eingebettetes Runtime“ tatsächlich zu sehr seltsamem Verhalten führen kann.
Also haben wir einen recht harten, aber sehr wertvollen Test gemacht:
- Eine beschreibbare Kopie der Store‑App aus den Ressourcen herauskopiert.
- Die per npm installierten
0.113.0‑Binaries genutzt, um dortcodex.exe,codex-command-runner.exeusw. zu ersetzen. - Gepatchte Desktop‑App gestartet und im neuen Thread reproduziert.
Wenn Versionsinkonsistenz die Ursache wäre, müsste die gepatchte Version wieder funktionieren.
Das Ergebnis: Gar keine Besserung.
Im neuen Thread meldete selbst das einfachste git status -sb weiterhin:
batch file arguments are invalid
Dieser Schritt ist entscheidend, weil er eine sehr plausible Hypothese direkt eliminiert.
Das Fazit wurde damit:
- Die Diskrepanz zwischen
0.112.0-alpha.3und0.113.0ist höchstens Rauschen oder ein separates Thema. - Aber sie ist nicht die Root Cause für den native‑Shell‑Crash.
Das ist der zweite große Gewinn:
Es gibt viele „verdächtige Punkte“, die das Verhalten erklären könnten – aber wenn ein Patch‑Experiment das Verhalten nicht beseitigt, ist es nicht die Ursache.
5. Weiteres Ausschließen: Das PowerShell‑Profile ist laut, aber nicht der tödliche Punkt hier
Zwischendurch gab es PowerShell‑Profile‑Fehler, z. B. dass .wt_proxy_config.json als null gelesen wurde und dann Logik wie Add-Member/$cfg.enabled im Profile explodierte.
So etwas sollte man natürlich beheben, weil es den Terminal‑Start verschmutzt und den Eindruck erweckt, Shell‑Initialisierung sei generell kaputt.
Aber hier ist die Kernbeurteilung:
Wenn die Root Cause das Profile wäre, müssten wenigstens einige Command‑Wege es umgehen können, oder das Fehlerbild müsste eher nach PowerShell‑Skriptfehler aussehen – nicht danach, dass alle Befehle einheitlich schon in der Startschicht mit batch file arguments are invalid sterben.
Später zeigte sich auch: Das Profile war nicht der Hauptgrund, warum der native Executor komplett lahmgelegt war.
6. Der echte Durchbruch: Ein sehr seltsames pwsh.cmd entdeckt
Am Ende wurde das Problem dadurch „festgenagelt“, dass auf dem System diese Datei gefunden wurde:
C:\\Users\\1\\AppData\\Local\\Programs\\Python\\Python313\\Scripts\\pwsh.cmd
Der Inhalt hatte nur zwei Zeilen:
@echo off
\"C:\\Program Files\\PowerShell\\7\\pwsh.exe\" %*
Das sieht aus wie ein „gut gemeinter Shim“, der pwsh einmal wrappt und auf echtes PowerShell 7 weiterleitet.
Aber für den Windows‑Executor von Codex Desktop ist das Gift:
- Es ist nicht
pwsh.exe, sondern ein.cmd‑Batch‑Wrapper. - Der Codex‑Command‑Executor triggert beim Aufruf dieser Datei mit Parametern irgendwo in der Kette direkt:
batch file arguments are invalid
Anders gesagt: Der Befehl erreicht pwsh.exe nie – er stirbt bereits auf der .cmd‑Ebene.
Das erklärt perfekt, warum:
Write-Output histirbtGet-Locationstirbtgit status -sbstirbtcmd.exe /c echo hiebenfalls stirbt
Weil nicht der Zielbefehl kaputtgeht, sondern das äußerste Shell‑Bootstrap.
7. Die entscheidende Beweiskette: Diese Falle wurde nicht erst heute erzeugt
Der interessanteste und zugleich kontraintuitive Teil ist hier.
Die Nutzerwahrnehmung war: „Vor ungefähr drei Stunden ist es plötzlich aufgetreten, vorher gab es kein Problem.“
Aber die Logs zeigen, dass die Historie dieses Problems älter ist als „heute plötzlich“:
Beweis 1: Der pwsh.cmd‑Shim wurde bereits am 2026-02-02 18:52:53 (lokale Zeit) geschrieben
Im codex-tui.log sieht man einen klaren Schreibvorgang: direkt in Pythons Scripts‑Verzeichnis wurde pwsh.cmd geschrieben.
Beweis 2: Derselbe Fehlertyp tauchte bereits am 2026-02-03 15:02:40 (lokale Zeit) auf
In den Logs tauchen ab 3. Februar bereits viele Einträge auf wie:
exec error: batch file arguments are invalid
Es gibt sogar explizite Aufrufversuche dieses Shims.
Beweis 3: Die aktuelle Störung wurde um etwa 2026-03-11 04:11 erneut sichtbar; der Repro‑Test um 04:33 traf stabil
Das heißt: Heute wurde nicht „diese kaputte Konfiguration neu erstellt“, sondern „ein alter Altfehler wurde erneut getriggert und traf genau den aktuell genutzten Pfad“.
8. Warum fühlt es sich für den Nutzer dann an wie „vor drei Stunden plötzlich kaputt“?
Das ist der Punkt, den es am meisten lohnt, klar zu erklären.
Die präzisere Aussage ist:
Nicht vor drei Stunden wurde die kaputte Konfiguration erzeugt, sondern vor drei Stunden ist Codex Desktop wieder auf den Ausführungspfad geraten, der pwsh.cmd trifft.
Mit den vorliegenden Indizien ist die plausibelste Erklärung diese Kombination (nicht „die Software hat heimlich gerade ein Update gemacht“):
- Die Mine
pwsh.cmdlag schon lange da. - Sie hat Anfang Februar bereits ähnliche Fehler ausgelöst, aber nicht jede Nutzung musste sie gleich sichtbar machen.
- Diesmal ist der Nutzer zur Diagnose wieder zu Windows native + PowerShell‑bezogenen Pfaden zurückgewechselt.
- Gleichzeitig hat der Desktop/Backend‑Prozess die persistente Umgebung erneut geladen und
pwshwieder via PATH aufgelöst. - Dabei traf die Auflösung den
.cmd‑Shim – und der Fehler brach wieder vollständig aus.
So ein Fehler kann also ohne Software‑Update „plötzlich erscheinen“.
Sobald irgendeines davon passiert, kann ein alter Altfehler reaktiviert werden:
- Desktop‑App Neustart
- Agent‑Backend‑Prozess Neustart
- Wechsel von WSL zurück zu Windows native
- Settings ändern → Shell neu initialisieren
- Ein neuer Thread nutzt nicht mehr die alte Umgebung, sondern liest PATH neu aus Persistenz
Hier muss man ehrlich sein:
Ich kann die Struktur „alter Altfehler + neuer Trigger“ bestätigen, aber ich kann anhand der vorhandenen Logs nicht zu 100% beweisen, welcher konkrete Moment ihn ausgelöst hat.
Sicher ist jedoch: Es ist nicht „heute neu erzeugte, unbekannte kaputte Konfiguration“.
9. Endgültige Reparatur
Die Aktion, die Windows native wiederhergestellt hat, ist simpel – muss aber präzise sein:
Aktion 1: Den Shim wegbewegen
Diese Datei:
C:\\Users\\1\\AppData\\Local\\Programs\\Python\\Python313\\Scripts\\pwsh.cmd
umbenennen zu:
C:\\Users\\1\\AppData\\Local\\Programs\\Python\\Python313\\Scripts\\pwsh.cmd.disabled-by-codex
Aktion 2: PowerShell 7 im User‑PATH nach vorne ziehen
Explizit:
C:\\Program Files\\PowerShell\\7\\
an den Anfang des Benutzer‑Path setzen, damit spätere Auflösungen nicht zuerst auf andere Shims treffen.
Aktion 3: Umgebungsvariablen‑Änderung broadcasten
Nicht nur Registry ändern, sondern explizit WM_SETTINGCHANGE / Environment senden, damit neue Prozesse die aktualisierte Umgebung schnell bekommen.
Aktion 4: Das patched Startskript prependet PowerShell 7 ebenfalls aktiv
Damit ist selbst dann, wenn später irgendwo PATH wieder verändert wird, diese Startkette weniger anfällig für Kontamination.
Nach der Reparatur hat der Nutzer bestätigt: endlich wieder normal.
10. Welche Umwege sind wir gegangen – und warum waren sie trotzdem sinnvoll?
Es sah nach vielen Schleifen aus, aber jede hat den Suchraum verkleinert:
Umweg 1: Zuerst vom WSL‑Netzwerkfehler abgelenkt
Nutzen: Bestätigt, dass WSL‑Problem und native‑Problem nicht dieselbe Störung sind.
Umweg 2: Verdacht auf PowerShell‑Profile
Nutzen: Trennt „Terminal‑Init‑Rauschen“ von „tödlichem Command‑Executor‑Defekt“.
Umweg 3: Verdacht auf veraltetes gebundeltes Backend der Desktop‑App
Nutzen: Durch das Experiment mit einer gepatchten App wird „reines Versionsproblem“ direkt ausgeschlossen.
Umweg 4: Verschiedene Command‑Einstiegspunkte ausprobiert
Zum Beispiel direkt:
Write-Output hicmd.exe /c echo hipowershell -NoProfile -Command ...\u0026 git.exe status -sb
Nutzen: Beweist, dass alle Wege auf derselben vorgelagerten Ebene scheitern – nicht ein shell‑spezifischer Bug.
Diese „Umwege“ waren also nicht umsonst, sondern haben das Problem von „kann überall sein“ zu „muss ein sehr low‑level Windows‑Shell‑Bootstrap / PATH / Shim‑Problem sein“ komprimiert.
11. Die praktischsten Lessons Learned
Lesson 1: Bei Desktop‑KI‑Tools bedeutet „Terminal sieht normal aus“ nicht, dass der Agent‑Executor normal ist
UI‑Terminal und Backend‑Command‑Execution sind zwei unterschiedliche Dinge.
Lesson 2: Kürzeste Command‑Tests sind extrem wertvoll
Tests wie Write-Output hi, Get-Location, cmd.exe /c echo hi sind viel wirksamer, als sofort komplexe Kommandos zu fahren.
Lesson 3: Versionsunterschiede sind nicht automatisch die Root Cause
Wenn man Binaries austauscht und das Verhalten 0% ändert, ist die Version höchstens Begleiterscheinung.
Lesson 4: Shims unter Windows sind extrem hinterhältig
Besonders .cmd, .bat, Python‑Scripts‑Verzeichnisse, WindowsApps‑Proxy‑Stubs – im Alltag unauffällig, aber sobald ein Programm anders auflöst als man erwartet, explodiert es absurd.
Lesson 5: „Der Nutzer spürt: heute plötzlich kaputt“ heißt nicht „die Ursache ist heute entstanden“
Viele systemnahe Probleme haben real diese Struktur:
- Altlast existiert lange
- lange nicht getroffen
- nach Prozessneustart/Moduswechsel/Environment‑Reload plötzlich totaler Ausbruch
Lesson 6: Log‑Zeitlinien sind extrem wichtig
Wenn man nur den aktuellen Zustand betrachtet, verwechselt man leicht „heute getriggert“ mit „heute erzeugt“.
12. Der wichtigste Ein‑Satz‑Schluss
Das war kein simples „Codex ist kaputt“, sondern ein typischer Windows‑Environment‑Kontaminationsfall: Ein lange zuvor abgelegter pwsh.cmd‑Shim wurde beim erneuten Durchlaufen des Windows‑native‑Shell‑Pfads wieder getroffen und hat den Command‑Executor von Codex Desktop komplett gesprengt.
Wenn ihr künftig etwas Ähnliches seht:
- alle Befehle schlagen einheitlich fehl
- Fehler ist sehr kurz und unabhängig vom Befehl
- integriertes Terminal geht, aber der Agent kann nicht laufen
- verschiedene Einstiegspunkte melden denselben Fehler
…dann schaut nicht primär auf Git, Repo, Profile oder sogar die App‑Version, sondern zuerst auf:
where.exe pwsh- PATH‑Reihenfolge
- gleichnamige
.cmd/.bat‑Shims - ob in WindowsApps / Python Scripts / Custom‑Launcher‑Verzeichnissen irgendwo Wrapper versteckt sind
Bei solchen Problemen ist die Reparatur oft klein, sobald man die Root Cause gefunden hat. Schwer ist nur: aus einem Haufen Lärm, der wie Root Cause aussieht, die eine echte Mine herauszuschälen.