Montagmorgen, IntelliJ offen, Kaffee noch zu heiß. Ich will nur schnell eine Sandbox-Einstellung anpassen — Keychain-Zugriff, weil ein kleines Bastelprojekt mit lokalen Secrets rumfummelt. Klick. Grau. Locked. Und daneben steht sinngemäß: Ihre Organisation verwaltet das. Die IDE schaut mich an wie ein Portier, der den Mitarbeiterausweis schon kennt und trotzdem sagt: Nein. Spoiler: Das war kein Bug. Das war die neue Enterprise-managed Sandbox in Copilot für JetBrains — und sie meint es ernst.

Wer schon länger mit GitHub Copilot in JetBrains arbeitet, kennt das Gefühl: lokal drehen, lokal testen, lokal riskieren. Die kurze Version: Admins können Sandbox-Verhalten jetzt zentral vorgeben. Managed Restrictions schlagen User-Settings. Und während Security die Tür zudrückt, öffnet dasselbe Update an anderer Stelle Produktivitätstüren — Cross-file-Cursor-Sprünge bei Next-Edit-Suggestions, globaler Projektkontext im Chat, plus /ide, das die Copilot-CLI an den JetBrains-Kontext koppelt. Klingt einfach ist es aber nicht. Im Ernst: Hier treffen sich zwei Welten, die sich sonst nur in Slack-Threads streiten.

Ich habe den Changelog gelesen, die Settings-Dialoge im Kopf durchgespielt und mich gefragt, was davon wirklich im Alltag zählt. Nerd-Alarm: Wenn die Sandbox den Keychain sperrt und der Cursor gleichzeitig in eine andere Datei springt, dann ist das kein Feature-Dump. Das ist eine klare These — Security rahmt Produktivität, nicht umgekehrt.

Fail am Keychain: Wenn die Sandbox „Nein“ sagt

Stellen Sie sich vor, Ihr MacBook ist ein etwas pedantischer Mitbewohner. Es hat den Schlüsselbund (macOS Keychain), es weiß, wo die Tokens liegen, und es lässt Copilot normalerweise mitspielen — solange Sie das lokal erlauben. Dann kommt die Organisation und sagt: Fertig mit dem Mitwohnen. Enterprise-managed Sandbox Policies (public preview) erlauben Administratorinnen und Administratoren, Sandbox-Verhalten für Copilot in JetBrains-IDEs zentral zu konfigurieren.

Was steuert die Policy? Unter anderem Sandbox-Enablement, Dateisystem- und Netzwerkzugriff, Proxy-Einstellungen, Zugriff auf Entwickler-Tools, macOS-Keychain-Zugriff und mehr. Die Liste klingt nach Checkliste aus dem Security-Handbuch — und genau so fühlt sie sich an, wenn man sie zum ersten Mal im grauen Zustand sieht. Mein Keychain, bisher eher der nette Nachbar, der die Haustür aufmacht, wenn man klingelt, steht plötzlich hinter einer Org-Mauer.

Wer das als reine Schikane liest, verpasst den Punkt. Ohne Sandbox kann ein Agent (oder die Shell-Befehle, die Copilot anstößt) theoretisch so weit laufen wie Ihr User-Account. Mit Sandbox wird das ein eingezäunter Hof. Managed heißt: Der Zaun kommt nicht mehr aus Ihrer settings.json-Bastelkiste, sondern von oben. Und ja — das ist unbequem, wenn man gerade ein lokales Token-Experiment fahren wollte. Es ist aber auch der Moment, in dem Copilot aufhört, sich wie ein freier Mitbewohner zu benehmen, und anfängt, wie Firmen-Equipment zu wirken.

Mehr Hintergrund zu Copilot in JetBrains und dem, was lokal schon länger rumexperimentiert wird, finden Sie auch in unserem Überblick zu Memory, Ollama und dem JetBrains-Alltag mit Copilot — dort ging es noch stärker um lokale Bastelfreiheit. Heute kippt die Balance.

Was die Enterprise-Sandbox in Copilot für JetBrains wirklich steuert

Die kurze Version: Admins setzen den Rahmen, die IDE zeigt ihn, Entwicklerinnen und Entwickler arbeiten darin. Laut Changelog steuern Managed Policies unter anderem:

ob die Sandbox überhaupt aktiv ist (Enablement),
Dateisystemzugriff (lesen, schreiben, Pfade freigeben oder sperren),
Netzwerkzugriff (outbound, lokal),
Proxy-Einstellungen,
Zugriff auf Developer-Tools,
macOS-Keychain-Zugriff,
und weitere Sandbox-Dimensionen.

Wichtig für den Alltag: Die Sandbox-Einstellungen unter GitHub Copilot > Sandbox erscheinen nicht immer. Sie sind sichtbar, wenn die Organisation den Feature-Flag Editor Preview aktiviert hat — oder wenn ein managed Setting die Sandbox gezielt aktiviert bzw. deaktiviert. Trifft keines von beidem zu, bleiben die Settings unsichtbar. Spoiler: Viele Teams werden erst merken, dass es die UI gibt, wenn Security sie einschaltet. Bis dahin wirkt Copilot wie immer. Danach wirkt es wie ein anderer Produktmodus.

Wer die lokalen Hebel nachlesen will, findet bei GitHub die Doku zu Configuring local sandbox settings. Parallel lohnt der Blick in den offiziellen Changelog-Eintrag zur Enterprise-managed Sandbox in Copilot für JetBrains. Beides zusammen erklärt, warum Ihr graues Häkchen kein UI-Glitch ist.

Im Ernst: Sandbox klingt nach „irgendwas mit Containern“. In der Praxis ist es eher: Copilot darf in diesen Ordner, darf nicht auf jenen Host, darf Secrets aus dem Keychain sehen — oder eben nicht. Alltagsvergleich: Sie lassen die Putzkraft in die Wohnung, aber nicht in den Tresorraum. Managed Sandbox heißt, die Hausverwaltung entscheidet, welche Türen überhaupt einen Schlüssel haben.

Managed schlägt User-Settings: Controls locked, Org gewinnt

Das ist der Satz, den man zweimal lesen sollte: Managed Restrictions take precedence over user settings. Copilot sperrt betroffene Controls in der IDE und kennzeichnet Einstellungen, die von der Organisation verwaltet werden. Klingt technisch. Fühlt sich an wie: Sie drehen am Regler, der Regler dreht nicht zurück.

Nerd-Alarm: Das ist kein Soft-Hint. Das ist Enforcement mit UI-Feedback. Wer lokal „Sandbox aus“ wollte, weil das Skript sonst die Pipeline nicht erreicht, bekommt jetzt eine klare Ansage. Wer Keychain freigeben wollte, weil ein Tool sonst nicht authentifiziert, sieht denselben grauen Zustand. Die Organisation setzt den Mindeststandard — und der Mindeststandard ist oft enger als das, was man sich am Freitagnachmittag selbst gönnt.

Das passt zu dem, was wir schon bei Admin-Review und Standard-Datenhaltung in Copilot gesehen haben: Enterprise-Copilot wird zunehmend über Policy gesteuert, nicht über individuelle Geschmacksfragen. Sitze, Budgets, Reviews — und jetzt Sandbox. Wer die organisatorische Seite nachverfolgen will, findet auch bei den zugewiesenen Enterprise-Sitzen und dem früheren Oktober-Termin den gleichen Grundton: Admin-Werkzeuge kommen nach, nachdem die Features schon im Alltag waren.

Parenthese für alle, die gerade wütend die Settings durchklicken: Policy Diagnostics gibt es genau dafür. Sie können prüfen, ob Policies auf dem Gerät korrekt erkannt und enforced werden. Die kurze Version: Bevor Sie ein Ticket „Bug: Setting lässt sich nicht speichern“ öffnen, einmal Diagnostics. Oft ist es Absicht. Manchmal ist es eine kaputte Erkennung. Beides ist besser als Blindflug.

Geräte-Personifikation, weil sie hier passt: Ihre JetBrains-IDE ist plötzlich der Security-Officer im Raum. Sie lächelt höflich, zeigt auf das Schloss-Icon und sagt: Das entscheiden nicht Sie. Und Copilot? Copilot nickt und arbeitet weiter — nur eben im erlaubten Hof.

Cross-file Next-Edit: Wenn der Cursor die Datei wechselt

Während Security die Sandbox zudreht, macht Next Edit etwas, das sich nach Produktivität anfühlt: Cross-file Cursor Jumps. Next-Edit-Suggestions können den Cursor jetzt in andere Dateien bewegen. Wenn ein vorgeschlagener Change in einer zweiten Datei weitergeht, springen Sie direkt dorthin — statt manuell zu suchen, zu grepfen, zu fluchen.

Spoiler: Das klingt nach Kleinigkeit. Es ist aber genau die Stelle, an der Multi-File-Refactors aufhören, sich wie Schnitzeljagd anzufühlen. Interface hier, Implementierung dort, Test noch eine Datei weiter — der Cursor folgt der Suggestion. Klingt einfach ist es aber nicht, weil Cross-file-Suggestions auch Cross-file-Verantwortung bedeuten. Ein falsches Accept, und Sie haben drei Dateien angefasst, nicht eine.

Alltagsvergleich: Früher hat Ihnen jemand gesagt: „In der Küche fehlt noch Salz, und im Wohnzimmer steht die Lampe schief.“ Sie sind selbst hingelaufen. Jetzt nimmt Sie jemand an der Hand und stellt Sie vor die Lampe. Praktisch. Auch ein bisschen unheimlich, wenn Sie eigentlich nur Salz wollten.

In Kombination mit agentischen Editor-Workflows — siehe auch unseren Text zu agentischen AI-Code-Editoren und autonomen Abläufen — wird klar: Der Editor hört auf, nur Vorschläge in der aktuellen Datei zu machen. Er navigiert. Er orchestriert. Und genau deshalb wird die Sandbox wichtiger, nicht unwichtiger. Mehr Reichweite braucht mehr Zaun.

Wer schon mal unter Stress erlebt hat, wie Editoren und AI-Helfer den Projektkontext überdehnen, kennt das Gefühl aus Code-Editoren unter Stress und der Project-Brain-Cascade. Cross-file-Cursor ist die freundliche Version derselben Dynamik: weniger Chaos beim Finden, mehr Verantwortung beim Annehmen.

Globaler Projektkontext im Chat und Policy-Diagnostics

Copilot Sandbox Cross-file JetBrains — Cross-file-Navigation gegen Sandbox-Policy (Symbolbild)

Chat ohne Kontext ist wie Kochen ohne Einkaufszettel: Man improvisiert, und am Ende fehlt das Salz. Neu: Sie können globale Dateien und Ordner zum Chat-Kontext hinzufügen. Informationen, die projektweit gelten — Guidelines, Architektur-Notizen, Shared Configs — müssen Sie nicht jedes Mal neu anheften. Das reduziert repetitive Context-Setup-Arbeit und hilft Copilot bei Änderungen, die mehrere Bereiche berühren.

Im Ernst: Das ist einer dieser UX-Punkte, die man erst vermisst, wenn man sie kennt. Einmal global rein, und der Chat hört auf, so zu tun, als hätte das Projekt keine gemeinsame Sprache. Gleichzeitig: Mehr Kontext heißt mehr Daten im Prompt — und damit mehr Gründe für klare Org-Regeln, was überhaupt in den Kontext darf.

Enterprise Policy Diagnostics ergänzt das Bild von der anderen Seite. Statt zu raten, ob die Managed Policy greift, prüfen Sie: erkannt? enforced? auf diesem Gerät? Das ist Debugging für Governance. Nerd-Alarm: Endlich ein Diagnoseweg, der nicht nur „bitte Plugin neu starten“ heißt. Für Admins: weniger Ping-Pong. Für Devs: weniger Verschwörungstheorien über „die IT hat wieder irgendwas kaputt gemacht“.

Die These bleibt: Produktivitätsfeatures (globaler Kontext, Cross-file-Sprünge) und Security-Features (Sandbox, Diagnostics) kommen im selben Release-Paket. Das ist kein Zufall. Das ist die Produktphilosophie hinter Enterprise-Copilot in JetBrains: Schneller ja — aber im Rahmen.

`/ide`: Copilot-CLI trifft JetBrains-Kontext

Wer Copilot auch in der CLI nutzt, kennt das Terminal-Einsamkeitsgefühl: Die Shell weiß nicht, was die IDE gerade markiert hat. Diagnostics? Dateireferenzen? Selection? Fehlanzeige. Neu in public preview: Mit /ide verbinden Sie eine Terminal-Session mit dem JetBrains-IDE-Kontext — inklusive Selections, Diagnostics und File References.

Die kurze Version: Das Terminal hört auf, blind zu sein. Es sieht, worauf Sie in der IDE schauen. Für Workflows, die zwischen Editor und CLI hin- und herspringen (und seien wir ehrlich: das sind die meisten ernsthaften), ist das der fehlende Stecker.

Dazu kommen Shell-Command-Verbesserungen: Copilot-Shell-Befehle können Environment-Variablen aus dem IDE-Terminal nutzen und den für das Projekt konfigurierten Python-Interpreter. Sie können die lokale Python-venv des Projekts aktivieren. Spoiler: Das klingt nach Detailpflege. Es ist der Unterschied zwischen „Agent startet irgendein Python“ und „Agent startet Ihr Python“. Wer schon einmal mit dem System-Python statt der Projekt-venv debuggt hat, nickt jetzt stumm.

Parenthese: /ide ist public preview. Erwarten Sie Kanten. Erwarten Sie auch, dass Security-Teams fragen: Was genau fließt da vom IDE-Kontext in die CLI-Session? Zu Recht. Produktivität und Policy gehören hier in denselben Review.

Wer agentisches Coding mit Copilot schon in anderen Modell-Konstellationen verfolgt hat — etwa in unserem Stück zu Grok und agentischem Coding in GitHub Copilot —, sieht das Muster: Agenten brauchen Kontext. Kontext braucht Grenzen. /ide liefert Kontext. Die Sandbox liefert Grenzen.

UX, Qualität, OpenTelemetry — knapp, aber ehrlich

Nicht alles in diesem Update ist Sandbox-Drama. Es gibt eine Reihe von UX- und Quality-Fixes, die den Alltag weniger klebrig machen — ohne dass man sie einzeln feiern muss.

Auf der UX-Seite laut Changelog unter anderem:

Model Picker und BYOK-Grouping übersichtlicher,
Subagent-Models: Session-Modell für eingebaute Subagents wählbar,
Ask-User-Card besser für lange Fragen,
MCP-Konfiguration öffnet im originating Project Window,
Plugin-Update-Reminders deutlicher,
Agent-Debug-Log mit Section-Copy (Diagnosen teilen, ohne Screenshot-Archäologie).

Quality-Seite: zuverlässigere MCP- und Agent-Sessions, BYOK-Persistenz, OAuth-Challenge-Kontinuität, wiederhergestellter Server-State, GitHub-Enterprise-Authentifizierung. Dazu Fixes für blanke lokale Chat-Sessions, falsche Working-Set-Zähler, Working-Set-Zoom und Model-Picker-Interaktionen, Read-only-File-Editing, Claude-Plan-Stop-Verhalten, irreführende Diagnostics für nicht geöffnete Dateien, veraltete Global Instructions in „Agent Customizations“ und Chats, die nach automatischer Compaction nicht mehr reagieren.

Und: OpenTelemetry-Settings in „GitHub Copilot – Chat“ sind jetzt GA. Die kurze Version für Observability-Fans: Die Telemetrie-Schalter sind raus aus der Preview-Ecke. Für alle anderen: Sie können ignorieren, bis Security fragt, was da eigentlich wohin fließt — und dann sind die Settings genau der Ort.

Im Ernst: Feature-Dumps langweilen. Was zählt, ist das Muster. Weniger Reibung beim Modellwählen. Weniger Geister-Chats. Weniger „warum ist die Datei read-only und niemand sagt es“. Das sind keine Poster-Features. Das sind die kleinen Reparaturen, die entscheiden, ob man Copilot nach dem dritten Freeze noch mag.

Security vs. Produktivität: Checkliste Admin gegen Dev-Bastelprojekt

Hier die klare These, ohne Weichspüler: Managed Sandbox bedeutet — der Admin gewinnt gegen lokale Bastel-Freiheit. Cross-file Next-Edit und /ide bedeuten — Produktivitätsgewinn, aber im Policy-Rahmen. Beides gehört zusammen. Wer nur Security predigt, verliert Adoption. Wer nur Speed predigt, verliert Secrets.

Checkliste für Admins:

Sandbox-Enablement bewusst setzen (nicht „mal schauen, was Default ist“).
Filesystem- und Network-Policies an reale Build-/Test-Pfade anpassen — sonst umgehen Teams die Tools, statt die Regeln.
Keychain-Zugriff nur freigeben, wenn es einen nachvollziehbaren Grund gibt.
Proxy und Developer-Tool-Access mit dem bestehenden Security-Stack abgleichen.
Policy Diagnostics als Standard-Schritt im Onboarding und bei Support-Tickets etablieren.
Editor Preview bzw. managed Enable/Disable so setzen, dass die Sandbox-UI für die Zielgruppe sichtbar ist — unsichtbare Controls erzeugen nur Support-Chaos.

Checkliste für Entwicklerinnen und Entwickler:

Graue Settings nicht als Bug behandeln, bevor Diagnostics gelaufen sind.
Cross-file Next-Edit bewusst accepten — eine Suggestion kann mehrere Dateien berühren.
Globalen Projektkontext pflegen (und wissen, was dort landet).
/ide ausprobieren, aber mit dem Wissen, dass IDE-Kontext in die CLI fließt.
Lokale Bastelprojekte mit Secrets: in erlaubte Pfade und erlaubte Tools verlagern, statt gegen die Sandbox zu kämpfen.
Feedback-Kanäle nutzen (In-Product, Issues), wenn Policy und Alltag kollidieren — stille Workarounds sind schlechter als ein Ticket.

Alltagsvergleich zum Schluss dieses Abschnitts: Die Firma gibt Ihnen einen Dienstwagen mit Tempomat und Geschwindigkeitsbegrenzer. Sie kommen trotzdem ans Ziel. Nur nicht mit 220 über die Landstraße, weil „geht ja technisch“. Managed Sandbox ist der Begrenzer. Cross-file und /ide sind die bessere Navigation. Beides im selben Auto.

Wer noch tiefer in die Konzeptseite will: GitHub erklärt Cloud- und Local-Sandboxes auch unter About cloud and local sandboxes for GitHub Copilot. Lesenswert, bevor man in der Settings-UI wild klickt.

Wenn der Portier bleibt und der Cursor trotzdem springt

Zurück zum Montagmorgen. Der Keychain bleibt locked. Die Sandbox-Settings tragen den Org-Stempel. Ich murre, trinke den inzwischen trinkbaren Kaffee und lasse den Cursor in die nächste Datei springen, weil die Next-Edit-Suggestion dort weitermacht. Spoiler: Das ist der Deal. Weniger lokale Bastelfreiheit, mehr geführte Produktivität — und ein Admin, der endlich zentral sagen kann, wie weit Copilot in JetBrains laufen darf.

Nerd-Alarm zum Abschied: Wer jetzt nur „meine Freiheit!“ schreit, übersieht die Cross-file- und /ide-Gewinne. Wer nur „endlich Kontrolle!“ ruft, übersieht, dass zu enge Sandboxes Teams zurück in unsichere Eigenbauten treiben. Die Kunst liegt dazwischen. Managed Restrictions first. Dann Diagnostics. Dann die neuen Sprünge und Stecker nutzen, statt gegen graue Checkboxen zu kämpfen.

Die kurze Version noch einmal: Enterprise-managed Sandbox in Copilot für JetBrains ist public preview, schlägt User-Settings, kennzeichnet und lockt Controls, steuert unter anderem Keychain, Filesystem, Network, Proxy und Developer-Tools. Parallel kommen Cross-file Cursor Jumps, globaler Chat-Kontext, Policy Diagnostics und /ide. UX und Quality werden mitgeschliffen, OpenTelemetry in Chat ist GA. Security rahmt Produktivität. Und der Portier an der IDE-Tür? Der bleibt. Gut so — solange Sie wissen, warum er da steht.