Sie kommen zurück vom Kaffee. Der Agent hat gelaufen. Im Terminal liegt ein Diff, der aussieht wie Arbeit. In den Logs stehen Pfade, die Sie nicht freigegeben haben. Und irgendwo zwischen .env, Keychain und einem Outbound-Call, den niemand protokolliert hat, fehlen die Secrets. Die Sandbox? Noch aus. Im Model-Picker glänzt derweil ein Frontier-Modell, das Sie vor einer Woche noch gar nicht auswählen konnten. Spoiler: Das ist kein Feature-Flex. Das ist ein Incident-Setup mit Changelog-Datum.

Am 23.9. landet Local Sandboxing in der Copilot App als Public Preview. Zwei Tage später, am 25.9., schiebt das Weekly vier Frontier-Modelle in denselben Picker – Claude Opus 5.5, GPT-6 Sol, GPT-6 Luna, Grok 4.7, planabhängig. Wer das als „endlich mehr Power“ abhakt und die Default-Policy ignoriert, debuggt später die falsche Schicht. Wir bei digital-magazin.de sehen hier kein Upgrade-Marketing. Wir sehen eine Woche, in der GitHub die Schutzschiene ausliefert und gleichzeitig die Pferdestärken hochdreht – und die Schiene standardmäßig offen lässt.

Nerd-Alarm: Wer nach dem Leak das Modell anschreit, hat die Default-Policy nicht gelesen. /sandbox on nach dem ersten Leak ist kein Undo. Es ist ein Schalter für die nächste Session, nicht für den Credential-Dump, der schon raus ist.

Was Local Sandboxing laut Changelog 23.9. tatsächlich tut

Die kurze Version: Local Sandboxing begrenzt den Zugriff von Agent-Sessions auf Dateisystem, Netzwerk und Credentials – pro Projekt, für lokale Repo- und Working-Tree-Sessions. So steht es im GitHub-Changelog vom 23.9.. Vendor-Claim, Public Preview, subject to change. Wir nehmen das ernst und zitieren es als Vendor-Claim, nicht als Sicherheitsgarantie.

Die Projekt-Einstellungen beschreiben die Policy, die die App anfordert, wenn eine sandboxed Session startet. Drei Hebel:

Filesystem: zusätzliche Read/Write-Ordner, zusätzliche Read-only-Ordner, explizit denied Folders.
Network: Outbound-Internet und lokales Netzwerk – getrennt steuerbar.
Credentials: Git-Credentials für authentifizierte HTTPS-Git-Operationen und GitHub-CLI-Credentials für CLI-Auth.

Klingt einfach, ist es aber nicht. „Requested policy“ heißt: Die App bittet. Enterprise-managed Settings können restriktiver sein. Die effektive Policy ist dann enger als das, was Sie im Projekt-Dialog angeklickt haben. Wer glaubt, die Checkbox im Projekt sei die Wahrheit, hat den Enterprise-Layer noch nicht getroffen.

Und der Fail-closed-Punkt, den wir bei digital-magazin.de für den eigentlichen Nerd-Kern halten: Kann das Betriebssystem die angeforderte Policy nicht durchsetzen, schlägt die sandboxed Shell mit einem Fehler fehl – statt ohne Sandbox weiterzulaufen. Fail-closed. Kein stiller Fallback auf „dann eben ungeschützt“. Im Ernst: Das ist der Unterschied zwischen einem Sicherheitsfeature und einem Marketing-Toggle.

Default: aus. Settings → Projekt → Sandbox new sessions. Gilt für neue Sessions, nicht für bereits laufende. Änderungen an Filesystem-, Network- und Credential-Settings greifen bei neuen Sessions oder wenn eine bestehende Session neu startet. Für eine aktive lokale Session ohne Änderung des Projekt-Defaults: /sandbox on. Bastelprojekt-Gefühl inklusive – nur dass hier nicht Lego, sondern Credential-Scope auf dem Spiel steht.

Was nicht greift: Cloud-Sandbox-Sessions und Sessions auf Remote Hosts. Copilot-App-Settings und Copilot-CLI-Settings sind getrennt. Wer lokal sandboxt und glaubt, die CLI sei damit mitgeschützt, mischt zwei Konfigurationswelten. Wir bei digital-magazin.de haben das schon bei anderen Copilot-Schichten gesehen – und es endet regelmäßig damit, dass jemand die falsche Oberfläche debuggt.

https://digital-magazin.de/github-copilot/

Fail-closed, wenn das OS nicht mitspielt

Viele Sandbox-Diskussionen enden bei „der Container ist dicht“. Hier endet sie bei: Das OS muss die Policy durchsetzen können. Wenn nicht – Fehler, kein Lauf ohne Sandbox. Das ist unbequem. Und genau deshalb wertvoll.

Stellen Sie sich vor: Eine Entwicklerin schaltet Sandbox ein, das OS liefert die Isolation nicht, und der Agent läuft trotzdem. Dann hätten Sie eine Checkbox, die Sicherheit suggeriert, ohne sie zu liefern. Fail-closed verhindert genau diese Illusion. Der Preis: Session startet nicht. Der Gewinn: Sie wissen, dass Sie ungeschützt wären – statt es hinterher aus dem Incident-Report zu lernen.

Persönliche Einschätzung Nummer eins: Ich halte Fail-closed für die wichtigste Zeile im gesamten Changelog vom 23.9. Nicht die Ordnerlisten. Nicht die Credential-Toggles. Sondern die Weigerung, ohne Enforcement weiterzumachen. Wer das als Bug meldet, weil „es ja nicht startet“, hat das Feature verstanden und gleichzeitig abgelehnt.

Die rhetorische Frage, die Sie sich stellen sollten: Wenn Ihre Umgebung die Policy nicht erzwingen kann – wollen Sie dann lieber einen harten Fehler oder eine Session, die tut, als wäre alles sicher?

Für Teams heißt das konkret: Sandbox-Enablement ist kein reiner App-Klick. Es ist eine Umgebungfrage. OS-Fähigkeit, Enterprise-Policy, Projekt-Settings – und erst dann die Session. Wer das überspringt und nur /sandbox on tippt, aktiviert eine Session-Policy auf einer Maschine, die sie vielleicht gar nicht tragen kann. Dann kommt der Fehler. Gut so.

Filesystem, Network, Credentials – drei Hebel, drei Irrwege

Die Filesystem-Policy ist der Teil, den die meisten zuerst anfassen. Additional read/write, additional read-only, denied. Das klingt nach Allowlist-Denken mit Deny-Ausnahme. In der Praxis heißt das: Sie müssen wissen, welche Pfade der Agent braucht – und welche er niemals sehen soll. .env, SSH-Keys, lokale Credential-Stores, Nachbarprojekte auf derselben Platte. Denied Folders sind kein Nice-to-have. Sie sind die Liste der Dinge, die Sie nach dem Leak nicht mehr drehen können.

Network ist der Hebel, den Teams unterschätzen. Outbound Internet an, lokales Netzwerk an – und plötzlich reicht ein Agent-Lauf, um interne Services anzustupsen oder Secrets an eine URL zu schicken, die im Prompt „hilfreich“ wirkte. Sandbox ohne Network-Nachdenken ist eine halbe Maßnahme. Wer Filesystem dicht macht und Network offen lässt, hat die Tür zum Flur zugemacht und die Fenster aufgerissen.

Credentials: Git HTTPS und GitHub CLI. Das ist der Teil, der Incident-Tickets schreibt. Authentifizierte Git-Operationen und CLI-Auth sind genau die Kanäle, über die Tokens und Identitäten in Agent-Läufe rutschen. Wenn die Sandbox Credentials begrenzt und der Default trotzdem aus ist, läuft der Agent mit dem vollen Credential-Scope der Maschine – Frontier-Modell inklusive. Spoiler: Das Modell ist dann nicht „böse“. Es ist nur mächtig in einer Umgebung, die keine Grenze gesetzt hat.

Nerd-Alarm: Project settings = requested policy. Enterprise kann enger sein. Wenn die Session anders läuft als erwartet, ist nicht zuerst der Agent kaputt. Zuerst ist die Policy-Kette zu lesen: Projekt → Enterprise → OS-Enforcement. In dieser Reihenfolge. Nicht umgekehrt.

Und nochmal der Default: aus. Neue Sessions ohne Sandbox, bis Sie Sandbox new sessions einschalten. /sandbox on rettet die aktive Session – ändert den Projekt-Default nicht. Wer das verwechselt, glaubt nach einem erfolgreichen /sandbox on, das Projekt sei „jetzt sicher“. Es ist eine Session sicher. Die nächste startet wieder ohne, wenn der Default aus bleibt.

https://digital-magazin.de/copilot/

Cloud und Remote sind ausgenommen – und das ist Absicht, kein Bug

Local Sandboxing gilt nicht für Cloud-Sandbox-Sessions und nicht für Sessions auf Remote Hosts. Das steht so im Changelog. Wer Remote-Dev auf SSH, Tunnel oder WSL fährt und lokal sandboxt, hat zwei Welten. Die lokale Policy schützt die lokale Session. Die Remote-Session läuft unter den Bedingungen des Remote Hosts.

Das ist kein Versäumnis im Sinne von „haben sie vergessen“. Es ist eine Grenzziehung: Local Sandboxing ist ein Feature der Copilot App für lokale Repo-/Working-Tree-Sessions. Cloud hat eigene Sandbox-Semantik. Remote Hosts haben die Isolation des Hosts – oder eben nicht. Vermischen Sie die Narrative nicht. Sonst erklären Sie einem Security-Team „wir haben Sandbox an“ und meinen die App-Checkbox, während der produktive Agent auf einem Remote-Host ohne dieselbe Policy läuft.

Copilot App und Copilot CLI: Settings separat. Wer die App härtet und die CLI vergisst, hat die Oberfläche gesichert, die er sieht – und die Schnittstelle offen gelassen, die Skripte und Automatisierung nutzen. Wir bei digital-magazin.de empfehlen, App und CLI bewusst als zwei Konfigurationsflächen zu behandeln. Nicht als „einmal an, überall dicht“.

Zum Rand des Weeklys vom 25.9.: Dort tauchen auch Slack, Teams, JetBrains und VS Code auf. Ein Satz reicht. Assisted Approvals in JetBrains, Dev Containers auf Remote-Hosts in VS Code, Model-Switch in Slack – alles parallel im selben Weekly. Kein Zweitpitch hier. Der Kern dieses Textes bleibt: Local Sandboxing default aus und vier Frontier-Modelle im Picker in derselben Wochenfenster-Logik.

Der Model-Picker vom 25.9.: vier Frontier-Namen, planabhängig

Laut GitHub Copilot Weekly vom 25.9. (Bezug Releases der Woche ab 21.9.) landen vier Modelle im Copilot-Umfeld:

Claude Opus 5.5 – Pro+, Max, Business, Enterprise
GPT-6 Sol – Pro+, Max, Business, Enterprise
GPT-6 Luna – Pro, Pro+, Max, Business, Enterprise
Grok 4.7 – Pro, Pro+, Max, Business, Enterprise

Vendor-Claims, planabhängig. Pro sieht Luna und Grok – nicht Opus 5.5 und nicht GPT-6 Sol. Pro+ und höher bekommen die breitere Palette. Wer im Team „wir haben doch Copilot“ sagt und meint, alle sähen denselben Picker, liegt falsch. Der Picker ist ein Plan-Spiegel. Die Modelle sind nicht „für alle da“, nur weil das Weekly sie in einem Absatz listet.

Persönliche Einschätzung Nummer zwei: Die Reihenfolge der Woche ist das eigentliche Signal. Erst Sandbox (23.9., default aus). Dann Modelle (25.9., Frontier im Picker). Wer nur den zweiten Changelog liest, sieht Power. Wer beide liest, sieht Power ohne erzwungenen Zaun. Das ist kein Zufall der Redaktionsplanung – es ist zumindest das Setup, in dem Incidents entstehen: Agent mit starkem Modell, volle lokale Rechte, Sandbox-Toggle noch unberührt.

Im selben App-Abschnitt des Weeklys steht OpenTelemetry über enterprise-managed Settings. Nebenkontext, kein Hauptpitch. Monitoring ohne Sandbox ist Observability für eine Session, die lokal alles darf. Nützlich. Aber kein Ersatz für die Policy, die den Zugriff erst begrenzt.

Wer GitHub Copilot Agent Mode schon produktiv nutzt, kennt das Muster: Je autonomer der Lauf, desto teurer der Default „alles offen“. Der Picker macht den Lauf nur schlauer und breiter – nicht vorsichtiger.

https://digital-magazin.de/vscode/

Incident-These: Default aus plus Frontier-Picker ist kein Flex

Copilot: Mechanische Tastatur und leere Sticky Notes zu Sandbox — Model-Picker und Default-Policy am Schreibtisch (Symbolbild)

Die These, klar formuliert: Sandbox default aus und vier Frontier-Modelle im Picker ergeben zusammen ein Incident-Setup, kein Feature-Flex. Die Schutzschiene existiert. Sie ist Public Preview. Sie ist opt-in. Die Modelle existieren. Sie sind planabhängig verfügbar. Die Kombination aus „mächtiger Agent“ und „ungeschützter Default“ ist die Schicht, in der Secrets nach dem Lauf verschwinden – und in der danach das Modell die Schuld bekommt.

Debugging-Fehler Nummer eins: Dem Modell die Schuld geben. Das Modell hat den Scope genutzt, den die Umgebung erlaubt hat. Debugging-Fehler Nummer zwei: /sandbox on als Undo behandeln. Es ändert die aktive Session. Es holt keine Secrets zurück. Es schreibt keine Audit-Geschichte rückwärts. Debugging-Fehler Nummer drei: Projekt-Default und Session-Toggle verwechseln. Wer einmal /sandbox on tippt und den Default aus lässt, feiert eine Session und verliert die nächste.

Die Fail-Szene vom Einstieg ist deshalb keine Anekdote. Sie ist der Normalfall, wenn Teams Features nach Changelog-Titel aktivieren und Policies nach Bauchgefühl. Frontier-Modell auswählen, Agent laufen lassen, Diff anschauen, Kaffee holen. Sandbox? Später. Später ist nach dem Leak.

Im Ernst: Opt-in bei Security-Features ist ein bekanntes Muster. Es senkt Reibung beim Rollout. Es erhöht die Wahrscheinlichkeit, dass Power-User ohne Zaun fahren. Public Preview heißt zusätzlich: subject to change. Wer heute die Policy baut, muss damit rechnen, dass sich Hebel und Semantik noch verschieben. Das entschuldigt nicht, den Default zu ignorieren. Es verpflichtet dazu, Enablement und Review als Prozess zu fahren – nicht als einmaligen Klick.

Für Enterprise-Teams kommt die restriktivere managed Policy dazu. Gut. Aber nur, wenn sie gesetzt ist. Projekt-Settings allein sind die Wunsch-Policy der App. Ohne Enterprise-Nachzug und ohne OS-Enforcement bleibt Fail-closed der letzte Schutz – und der schützt, indem er den Start verweigert, nicht indem er den Agent „irgendwie“ einschränkt.

Praktischer Ablauf: was Sie jetzt prüfen, bevor der nächste Agent läuft

Die kurze Version als Checkliste, ohne sie als Marketing-Bullet zu verkaufen:

Copilot App: Projekt öffnen, Sandbox new sessions – bewusst an oder bewusst aus, mit Begründung im Team.
Filesystem: denied Folders für Secrets, Keys, Nachbarprojekte; read-only dort, wo der Agent lesen, aber nicht schreiben soll.
Network: Outbound und Local Network getrennt entscheiden. „Internet an, weil Convenience“ ist eine Entscheidung, keine Voreinstellung, die Sie hinnehmen müssen.
Credentials: Git HTTPS und GitHub CLI – brauchen Sie das im Agent-Lauf? Wenn nein, begrenzen.
Aktive Session: /sandbox on nur als Session-Maßnahme verstehen, Default separat setzen.
Cloud/Remote: nicht einrechnen. Eigene Story, eigene Isolation.
CLI vs App: beide Flächen prüfen.
Model-Picker: Plan-Matrix kennen. Pro ≠ Pro+. Luna/Grok vs Opus/Sol.

Klingt einfach, ist es aber nicht – weil jeder Punkt eine Team-Entscheidung ist, keine Checkbox-Übung. Wer das an eine einzelne Entwicklerin delegiert und hofft, „die stellt das schon ein“, bekommt genau die Varianz, aus der Incidents entstehen: ein Repo sandboxed, das andere nicht; eine Session mit /sandbox on, die nächste ohne; ein Plan mit Opus, ein Plan ohne.

Bezug zu bestehender Copilot-Abdeckung auf dem Portal: Wer die Linie von Enterprise-Sandbox und Keychain schon verfolgt hat, erkennt das Muster wieder – Isolation, Credentials, Cross-File-Risiken. Hier ist der lokale App-Hebel nachgezogen. Nicht identisch. Nicht vermischen. Aber thematisch verwandt: Wer Secrets und Agent-Scope ernst nimmt, liest Sandbox-Changelogs vor Model-Picker-Changelogs.

Und ja, am Rand: Für Teams, die ohnehin zwischen Copilot und anderen Agent-Oberflächen springen – etwa Richtung Claude Code – gilt dieselbe Disziplin. Anderer Vendor, gleiches Prinzip: Default-Policy lesen, bevor der Frontier-Lauf startet.

Was Public Preview für den Alltag heißt

Public Preview, subject to change. Das ist keine Floskel am Changelog-Ende. Das heißt: UI-Labels können wandern, Policy-Semantik kann nachziehen, Fail-closed-Verhalten kann sich in Edge Cases anders zeigen, als Ihr Runbook heute annimmt. Schreiben Sie Enablement deshalb so, dass Sie es ändern können – nicht so, dass eine Checkbox in einem Wiki als ewige Wahrheit steht.

Was sich nicht „wegpreviewen“ lässt, ist die Logik der Woche: Es gibt jetzt einen lokalen Sandbox-Hebel in der App. Er ist opt-in. Es gibt jetzt mehr Frontier-Modelle im Picker. Sie sind planabhängig. Beides zusammen verschiebt die Beweislast. Wer ohne Sandbox und mit starkem Modell produktiv fährt, trifft eine Risikoentscheidung. Keine neutrale Voreinstellung mehr, die „einfach so“ war, weil es den Hebel noch nicht gab.

Nerd-Alarm zum Schluss dieses Blocks: Die Leute, die nach dem Leak das Modell wechseln („nächstes Mal Luna statt Opus“), optimieren die falsche Variable. Modellwahl steuert Fähigkeit. Sandbox steuert Scope. Wer Fähigkeit dreht und Scope ignoriert, kuriert Symptome in der Prompt-Schicht und lässt die Incident-Ursache in der Default-Policy.

Plan-Unterschiede: wer welchen Frontier-Namen überhaupt sieht

Noch einmal die Matrix, weil sie in Meetings sonst untergeht:

Pro: GPT-6 Luna, Grok 4.7 – laut Weekly.
Pro+, Max, Business, Enterprise: zusätzlich Claude Opus 5.5 und GPT-6 Sol; Luna und Grok ebenfalls.

Das bedeutet für Security-Reviews: „Schaltet Sandbox für alle ein, die Opus nutzen“ ist die falsche Regel. Sandbox ist kein Modell-Feature. Sandbox ist eine Session-/Projekt-Policy der App für lokale Läufe. Die Regel muss lauten: Sandbox-Policy für lokale Agent-Sessions – unabhängig davon, welches Modell der Picker gerade anbietet. Sonst härten Sie nur die teuren Pläne und lassen Pro-Läufe mit Luna/Grok ungeschützt, obwohl dieselben Credential- und Network-Risiken gelten.

Bastelprojekt-Warnung: Teams bauen gern „Pilot mit Max-Plan und Sandbox an“ und rollen parallel „Normalbetrieb mit Pro ohne Sandbox“ aus. Das fühlt sich nach kontrolliertem Rollout an. Es ist ein zweistufiges Risiko-Modell ohne Dokumentation. Wenn Sie das tun, dokumentieren Sie es als bewusstes Risiko – nicht als Zwischenstand auf dem Weg zu „irgendwann für alle“.

Und die Enterprise-Schicht: managed Settings können restriktiver sein als Projektwünsche. Das ist der Hebel, mit dem Organisationen Fail-closed und Scope zentraler setzen können, ohne auf individuelle Opt-ins zu hoffen. OpenTelemetry über dieselben enterprise-managed Settings – wiederum Nebenkontext – hilft beim Nachvollziehen, ersetzt aber nicht die Zugriffsbeschränkung.

Warum „nach dem Leak suchen“ die falsche Reihenfolge ist

Zurück zur Einstiegsszene. Secrets suchen, nachdem der Agent gelaufen ist, heißt: Sie forensiken eine Session, deren Scope Sie vorher nicht begrenzt haben. Das Modell bekommt die Schuld, weil es der sichtbare Akteur war. Die Default-Policy bleibt unangetastet, weil sie unsichtbar war – aus, still, ohne Warnbanner, der schreit.

Die richtige Reihenfolge ist langweilig und wirkt pedantisch: Policy setzen, OS-Enforcement prüfen, Session starten, Modell wählen, Agent laufen lassen. Die falsche Reihenfolge ist bequem und wirkt modern: Modell wählen, Agent laufen lassen, bei Bedarf Sandbox. /sandbox on nach dem Leak ist der Moment, in dem Teams glauben, sie hätten reagiert. Sie haben die nächste Session vorbereitet. Die aktuelle Incident-Timeline bleibt.

Spoiler für Postmortems: „Wir haben Sandbox danach eingeschaltet“ ist eine Remediation für die Zukunft. Es ist keine Root-Cause-Fix für den Leak. Root Cause ist: Agent mit Credential-/Filesystem-/Network-Scope ohne Sandbox, Default aus, Frontier-Modell verfügbar. Alles andere ist Detail.

Wer Copilot im Alltag fährt und gleichzeitig VS-Code-Workflows mit Agent-Sessions mischt, sollte die Flächen getrennt reviewen. App-Sandbox schützt App-Lokal. VS Code Remote/Dev-Container-Stories aus dem Weekly sind eine andere Isolationsfrage. Wieder: höchstens Rand, kein Zweitpitch – aber genug, um nicht alles in einen „Copilot ist jetzt sandboxed“-Satz zu pressen.

Einordnung ohne Marketing-Glanz

Local Sandboxing in der Copilot App ist ein nötiger Hebel. Fail-closed ist die richtige Haltung, wenn Enforcement fehlt. Die Trennung von Cloud/Remote und die Trennung App/CLI sind klar kommuniziert – wer sie ignoriert, baut sich selbst die Lücke.

Der Model-Picker mit Claude Opus 5.5, GPT-6 Sol, GPT-6 Luna und Grok 4.7 ist ein Leistungs-Update, planabhängig. Für sich genommen interessant. In derselben Woche wie eine opt-in Sandbox: relevant für Risk.

Die Kombination ist das Thema. Nicht „GitHub liefert Security“. Nicht „GitHub liefert Modelle“. Sondern: GitHub liefert beides in engem Abstand, Sandbox default aus, Modelle greifbar. Wer das als Feature-Flex feiert, hat den Incident noch vor sich. Wer die Default-Policy debuggt, bevor Secrets fehlen, hat den Changelog verstanden.

Im Ernst – und das ist die letzte persönliche Zuspitzung in diesem Text: Ich will den Sandbox-Default nicht romantisch umdeuten. Opt-in ist eine Produktentscheidung. Public Preview ist eine Reifestufe. Beides erklärt, warum der Default aus ist. Es entschuldigt nicht, ihn in produktiven Agent-Läufen mit Frontier-Modellen zu ignorieren. Die Woche vom 23.9. und 25.9. hat den Hebel und die Pferdestärken geliefert. Die Policy müssen Sie selbst umlegen. Bevor der Kaffee kalt ist. Bevor der Agent fertig ist. Bevor jemand im Log nach Secrets sucht und dem Modell die Schuld gibt.