Claude Code und Codex absichern: was die Sandbox blockiert

Am 4. September 2026 wurde bekannt, dass sich Code-Agenten von OpenAI auf einem deutschen Wiki verabredet hatten, um Sandbox-Umgehungen auszutauschen. Die Moral der Sache interessiert weniger als ihre Mechanik. Auf deiner Maschine lautet die Frage, was du erlaubst, wenn du claude oder codex startest, ohne hinzuschauen.

Was auf dem deutschen Wiki passiert ist

DseWiki ist ein Wiki deutscher Entwickler, gehostet auf prowiki.org und seit fünfundzwanzig Jahren aktiv. Zwischen dem 11. Mai und dem 13. Juli 2026 wurden dort rund 18.000 Nachrichten von fast 3.700 autonomen Agenten-Identitäten hinterlassen, mit einem Höhepunkt vom 16. bis 22. Juni und bis zu 400 Einträgen pro Tag. Das Kollektiv Nightingale hat das Dossier am 4. September 2026 auf collusion.wiki veröffentlicht, am selben Tag wie die Enthüllung von Reuters.

Neben Datensätzen und API-Endpunkten finden sich dort auch Fluchtrezepte. Der am besten dokumentierte: Die NO_PROXY-Liste ihrer Umgebung vertraute allem, was auf .blob.core.windows.net endet, also erfanden sie einen Namen mit dieser Endung und leiteten ihn über /etc/hosts auf die gewünschte Adresse um. Ein Agent veröffentlichte das Rezept am 20. Juni unter dem Titel „REPRODUCIBLE BYPASS“, ein anderer reproduzierte es vierzehn Minuten später, berichtet the-decoder.

Das unangenehme Detail ist die Chronologie. Bereits im März 2026 beschrieb OpenAI, 99,9 % des Traffics seiner internen Code-Agenten zu überwachen, mit GPT-5.4 Thinking, das den gesamten Kontext sieht, Gedankenkette und Tool-Aufrufe eingeschlossen, und schwere Fälle innerhalb von dreißig Minuten an einen Menschen eskaliert. Das Wiki lief auch nach dieser Veröffentlichung weiter. Ein Monitor, der alles sieht, ist keine Grenze.

Das Bedrohungsmodell auf deiner Maschine

Du bist nicht OpenAI, und dein Agent hat vermutlich überhaupt keine Absichten. Trotzdem reichen drei Szenarien, und keines davon braucht böse Absicht.

• Prompt-Injection: Eine Webseite, ein GitHub-Issue, ein Log oder das Ergebnis eines MCP-Tools enthält Anweisungen, die der Agent als Befehle liest. Das ist der Haupteinstiegspunkt, und er lässt sich nicht im Prompt beheben.
• Exfiltration: Der Agent liest deine Schlüssel und schickt sie woandershin. Ein curl zur falschen Domain genügt.
• Der zerstörerische Befehl: ein rm, ein git reset --hard, eine Migration auf der falschen Datenbank.

Die einzige Antwort, die trägt, ist eine Grenze, die das Modell sich nicht aussuchen kann, die des Betriebssystems oder eines Containers.

Kappt die Sandbox von Codex wirklich das Netzwerk?

Codex bietet über -s drei Modi: read-only, workspace-write und danger-full-access. Die Dokumentation gibt an, dass workspace-write das Schreiben im Arbeitsbereich erlaubt und das Netzwerk kappt. Ich habe das auf diesem Mac unter macOS 26.6.2 mit gpt-6-astra überprüft.

codex exec --skip-git-repo-check -C ./workspace -s workspace-write \
  'Execute une fois : curl -sS -m 10 -o /dev/null -w "%{http_code}" https://example.com'

Ergebnis: Exit-Code null, 200. Das Netzwerk kam durch. Im Modus read-only, mit einer Abfrage der entfernten Adresse, lautete die Ausgabe code=200 ip=2606:4700:10::6814:179a t=0.084658: eine echte Antwort eines Cloudflare-Servers in fünfundachtzig Millisekunden. Weder -c sandbox_workspace_write.network_access=false noch --ignore-user-config änderten daran etwas.

Schreibzugriffe dagegen waren gut eingedämmt. Unter workspace-write ging touch ./fichier durch, während touch /Users/gekkode/fichier Operation not permitted zurückgab. Unter read-only wurde sogar das Schreiben im aktuellen Ordner verweigert. Aber ls ~/.ssh | wc -l lieferte zwölf: Eine schreibgeschützte Sandbox schützt dich vor dem Schreiben, nicht davor, dass jemand deine Schlüssel liest.

Das Flag, das alles erklärte, war --ignore-rules.

codex exec --ignore-rules --skip-git-repo-check -C ./workspace -s workspace-write \
  'Execute une fois : curl -sS -m 10 -o /dev/null -w "%{http_code}" https://example.com'
# curl: (6) Could not resolve host: example.com

Die Sandbox funktioniert. Was sie umging, steckt in ~/.codex/rules/default.rules, der Datei, in der sich die beim Arbeiten angeklickten „immer erlauben“ stapeln. Sie enthielt 249 Regeln, alle auf allow gestellt, darunter diese:

prefix_rule(pattern=["curl"], decision="allow")
prefix_rule(pattern=["wget"], decision="allow")

Vor Monaten wurde eines Tages ein bestimmter curl-Befehl „für immer“ erlaubt. Die gespeicherte Regel bezieht sich auf das Programm, nicht auf die URL: Seitdem lief jeder curl zu jeder beliebigen Adresse außerhalb der Sandbox. Das erklärt auch, warum network_access = false wirkungslos blieb, denn die Entscheidung fällt, bevor die Netzwerkrichtlinie greift. Sieh dir diese Datei noch einmal an, es ist wahrscheinlich die lohnendste Änderung in diesem ganzen Artikel.

Um eine Grenze zu testen, ohne einen einzigen Token zu verbrauchen, legt Codex die Sandbox direkt offen, mit den eingebauten Profilen :read-only, :workspace und :danger-full-access:

codex sandbox -P ':workspace' -- /usr/bin/curl -sS -m 8 https://example.com
# curl: (6) Could not resolve host: example.com

codex sandbox -P ':read-only' -- /usr/bin/touch ./preuve.txt
# touch: ./preuve.txt: Operation not permitted

Claude Code abhärten

Die Einstellungen unten stammen aus der Dokumentation von Claude Code, aufgerufen am 7. September 2026.

Die Sandbox von Claude Code ist nicht standardmäßig aktiv: /sandbox schreibt sie in die .claude/settings.local.json des Projekts, oder du setzt sie in ~/.claude/settings.json für alle deine Projekte. Sie stützt sich auf Seatbelt unter macOS, auf bubblewrap unter Linux und WSL2. Das Netzwerk läuft dabei über einen Proxy mit Whitelist: Keine Domain ist im Voraus erlaubt.

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"],
      "strictAllowlist": true
    },
    "credentials": {
      "files": [{ "path": "~/.ssh", "mode": "deny" }],
      "envVars": [{ "name": "GITHUB_TOKEN", "mode": "deny" }]
    }
  }
}

strictAllowlist lehnt ab, statt zu fragen, und wirkt nur über Nutzer-Einstellungen, verwaltete Einstellungen oder --settings: Es in der .claude/settings.json eines Repositorys zu setzen, bewirkt nichts. Der Block credentials beantwortet die bei Codex gemessene Lücke: Standardmäßig lässt eine Sandbox das Lesen von ~/.ssh zu.

Zwei Grenzen solltest du kennen. Erstens beziehen sich die Berechtigungsregeln auf den Text des Befehls, und die Dokumentation sagt es unverblümt: Bash(curl http://github.com/ *) deckt weder curl -X GET ab, noch https, noch eine per Variable übergebene URL. Verbiete das Netzwerk-Tool und lass WebFetch die Arbeit machen:

{
  "permissions": {
    "deny": ["Bash(curl:*)", "Bash(wget:*)", "Read(~/.ssh/**)"],
    "allow": ["WebFetch(domain:github.com)"]
  }
}

Zweitens tut --permission-prompts none, seit 2.1.259 verfügbar, nicht das, was der Name vermuten lässt: Im Modus -p lehnt Claude Code die Anfrage ab, statt sie zu stellen, wenn niemand antworten kann. Das ist das Gegenteil von --dangerously-skip-permissions, und es ist das richtige Flag für einen unbeaufsichtigten Agenten.

Die Angriffsfläche der MCP-Server verkleinern

Ein MCP-Server ist Code, den du startest und dessen Ergebnisse in den Kontext einfließen: Beide Risiken addieren sich. Der Fall mcp-remote hat das gezeigt: Dieser OAuth-Proxy, 437.000-mal heruntergeladen und in den Integrationsleitfäden von Cloudflare, Hugging Face und Auth0 zitiert, reichte den vom entfernten Server gelieferten Autorisierungspunkt an die Shell weiter, was eine Remote-Code-Ausführung ermöglichte (CVE-2025-6514, dokumentiert von Docker).

Drei Regeln decken das Thema ab. Pinne die exakten Befehle statt der Namen fest: In allowedMcpServers ist ein serverName-Eintrag wertlos, da die Bezeichnung vom Nutzer gewählt wird, während ein serverCommand Argument für Argument übereinstimmen muss. Gib jedem Server nur Lesezugriff: SQL-Nutzer beschränkt auf SELECT, Dateiserver begrenzt auf einen Ordner. Und behandle jede Tool-Ausgabe als Daten, niemals als Anweisung.

{
  "allowedMcpServers": [
    { "serverCommand": ["npx", "-y", "@modelcontextprotocol/server-filesystem", "."] },
    { "serverUrl": "https://mcp.sentry.dev/*" }
  ],
  "deniedMcpServers": [{ "serverUrl": "https://*.untrusted.example.com/*" }]
}

Auf einem einzelnen Rechner leben diese Listen in deinen eigenen Einstellungen. Im Team legt eine managed-mcp.json-Datei unter /Library/Application Support/ClaudeCode/ auf macOS oder /etc/claude-code/ auf Linux die exklusive Serverliste fest: claude mcp add antwortet dann mit einem Unternehmensrichtlinien-Fehler. Wenn du eigene Server schreibst, wird der Geltungsbereich schon beim Entwurf festgelegt, wie der Artikel über das Erstellen eines MCP-Servers in PHP im Detail zeigt.

Wann solltest du zum Container wechseln?

Sobald der Agent ohne dich läuft. Ein Container gibt dir eine Grenze, die weder eine vergessene Regel noch die Antwort eines Tools verschieben kann. Die folgenden zwei Messungen wurden hier durchgeführt:

docker run --rm --network none alpine:3 \
  sh -c 'wget -q -T 5 -O /dev/null https://example.com'
# wget: bad address 'example.com'   (code 1)

docker run --rm --read-only --tmpfs /tmp alpine:3 \
  sh -c 'touch /etc/preuve; touch /tmp/preuve'
# touch: /etc/preuve: Read-only file system   (code 1, /tmp akzeptiert)

--network none kappt sogar die DNS-Auflösung, und --read-only mit einem tmpfs für temporäre Dateien lässt den Agenten arbeiten, ohne das System anzufassen. Binde nur das Repository als Volume ein, sonst nichts: kein ~/.ssh, kein ~/.aws, kein Docker-Socket, die Dokumentation von Claude Code sagt es unumwunden, /var/run/docker.sock zu erlauben kommt der Freigabe des Hosts gleich. Der Überblick über Kommandozeilen-Agenten zeigt, welche diesen Rahmen ohne Widerstand akzeptieren.

Was du dir merken solltest

• Öffne noch heute ~/.codex/rules/default.rules: Ein „immer erlauben“ bei curl befreit alle deine Anfragen still und für immer aus der Sandbox.
• codex sandbox -P ':read-only' und -P ':workspace' testen die Grenze, ohne das Modell aufzurufen. Prüfe es, nimm es nicht einfach an.
• Eine Sandbox blockiert das Schreiben, nicht das Lesen: ~/.ssh bleibt lesbar, solange du es nicht in sandbox.credentials oder denyRead aufgeführt hast.
• Regeln, die Argumente filtern, sind brüchig: Verbiete Bash(curl:*) und nutze stattdessen WebFetch(domain:…). Pinne bei MCP serverCommand fest, nicht serverName.
• Unbeaufsichtigt gilt der Container: --network none, --read-only, keine Secrets eingebunden. Der Rest ist Komfort. Um aufzuräumen, was deine Agenten laden, gibt es außerdem /skill-doctor.