Copilot in JetBrains: MCP-Autostart abschalten und Agenten-Modell festlegen

Stellen Sie sich vor, ein Entwickler in Ihrem Unternehmen öffnet morgens seine Entwicklungsumgebung. Im Hintergrund starten, ohne dass er etwas anklickt, mehrere Zusatzwerkzeuge für den KI-Assistenten: eines liest Tickets, eines greift auf ein Dateiverzeichnis zu, eines spricht mit einer Datenbank. Niemand hat bewusst entschieden, dass diese Werkzeuge heute laufen sollen. Sie laufen, weil sie irgendwann einmal eingerichtet wurden. Wenn Sie den Entwickler fragen, welche davon gerade aktiv sind und was sie dürfen, bekommen Sie vermutlich ein Schulterzucken.

Genau an dieser Stelle setzt eine Meldung an, die GitHub am 10. Oktober 2026 im Änderungsprotokoll veröffentlicht hat. Unter dem Titel „New controls and chat improvements in Copilot for JetBrains“ beschreibt GitHub neue Funktionen für Copilot in den JetBrains-Entwicklungsumgebungen. Drei davon sind für Unternehmen interessant: eine „Fix“-Aktion, die Fehler direkt über den Agenten beheben lässt, ein von Administratoren festlegbares Standard-Agentenmodell und eine Einstellung, die den automatischen Start von MCP-Servern abschaltet.

In diesem Artikel ordnen wir ein, was die Quelle belegt, was sie ausdrücklich nicht sagt, und welche Regeln Sie Ihrem Entwicklungsteam geben sollten, bevor Agenten in der Entwicklungsumgebung zum Alltag werden. Wir halten uns dabei eng an den Wortlaut der Quelle. Zahlen, die dort nicht stehen, nennen wir nicht.

Was GitHub am 10. Oktober 2026 gemeldet hat

Der Eintrag im GitHub-Änderungsprotokoll trägt das Datum 10. Oktober 2026 und ist laut Seite in etwa zwei Minuten lesbar. Er fasst mehrere Neuerungen für Copilot in JetBrains-Entwicklungsumgebungen zusammen. Wir geben die drei Kernpunkte in eigenen Worten wieder.

• Standardmodell per Richtlinie: Administratoren können über „Managed Settings“ ein beliebiges verfügbares Copilot-Agentenmodell als Standard für neue Unterhaltungen festlegen. Eine bewusste Auswahl im Modellwähler bleibt für Nutzer weiterhin möglich.
• Fix-Aktion in Diagnosen: Die Diagnosemenüs der Entwicklungsumgebung enthalten eine Aktion „Fix“. Sie öffnet den Inline-Chat und bittet Copilot um eine Reparatur. Genutzt wird dafür der Agent-Modus, sofern er verfügbar ist, andernfalls der Ask-Modus.
• Steuerung des MCP-Starts: Eine neue Einstellung deaktiviert den automatischen Start von MCP-Servern, und zwar für Copilot und für Claude.

Daneben nennt GitHub eine Reihe kleinerer Verbesserungen: klarere Kontobezeichnungen und eine Aktion zum Kontowechsel, einmalige Hinweise für neue Nutzer, nach Gesprächsrunden gruppierte Chat-Nachrichten, kopier- und bearbeitbare Nutzernachrichten und Stabilitätsverbesserungen unter anderem bei der MCP-Konfiguration und bei Worktrees. Außerdem endet die Unterstützung für die JetBrains-Version 2025.1. Benötigt wird 2025.2 oder neuer.

„A new MCP setting lets you disable automatic server startup for Copilot and Claude.“ (GitHub Changelog, 10. Oktober 2026)

Dieser eine Satz ist der Grund, warum wir die Meldung für den Mittelstand für relevant halten. Er ist unscheinbar, benennt aber einen Hebel, den es zuvor in dieser Form offenbar nicht gab: Ein Unternehmen kann entscheiden, dass Zusatzwerkzeuge für Agenten nicht von selbst starten.

Was die Quelle zur Verfügbarkeit sagt und was nicht

Wir beschreiben Neuerungen nur dann als „jetzt nutzbar“, wenn die Quelle das trägt. Deshalb hier eine nüchterne Bestandsaufnahme.

• Belegt: Die Funktionen stehen im Änderungsprotokoll von GitHub als Teil der Neuerungen für Copilot in JetBrains. Die Entwicklungsumgebung muss in Version 2025.2 oder neuer vorliegen.
• Nicht genannt: Die Meldung nennt weder Tarife oder Preise noch einen Preview- oder Beta-Status einzelner Funktionen noch eine Regionsbeschränkung. Sie nennt auch keine Versionsnummer des Plugins.

Was folgt daraus? Die Quelle enthält keinen Hinweis auf eine Testphase. Sie sagt aber auch nicht, in welchen Tarifen die Funktionen enthalten sind. Insbesondere die Steuerung über „Managed Settings“ richtet sich an Administratoren und setzt voraus, dass Ihr Unternehmen Copilot zentral verwaltet. Ob das bei Ihnen der Fall ist und welcher Tarif dafür nötig ist, müssen Sie in Ihrer eigenen Copilot-Verwaltung und in der offiziellen Dokumentation prüfen. Wir haben die Funktionen nicht selbst getestet und stellen sie daher nicht als erprobt dar.

MCP in zwei Absätzen: Warum ein Autostart überhaupt ein Thema ist

MCP steht für Model Context Protocol. Es ist ein offener Standard, mit dem sich KI-Anwendungen an externe Datenquellen und Werkzeuge anbinden lassen. Anthropic hat ihn Ende November 2024 vorgestellt. Man kann sich MCP wie einen einheitlichen Steckanschluss vorstellen: Statt für jedes Werkzeug eine eigene Schnittstelle zu bauen, bietet ein „MCP-Server“ seine Fähigkeiten in einer einheitlichen Form an, und der Agent kann sie nutzen.

Für die Produktivität ist das ein Gewinn. Für die Sicherheit entsteht eine neue Frage: Jeder MCP-Server erweitert, was der Agent erreichen und auslösen kann. Startet er automatisch, ist er bei jeder Sitzung verfügbar, ob sie ihn braucht oder nicht. Das ist bequem, aber es bedeutet auch, dass ein Entwickler leicht den Überblick darüber verliert, welche Fähigkeiten sein Agent gerade hat. Je mehr solcher Werkzeuge eingerichtet sind, desto größer wird die Fläche, die Sie im Blick behalten müssen.

Die Prüffrage dahinter: das „tödliche Dreigespann“

Der britische Entwickler Simon Willison hat am 16. Juni 2025 auf seinem Blog ein Denkmodell beschrieben, das sich als Prüffrage für jeden Agenten eignet. Er nennt es „The Lethal Trifecta“, auf Deutsch etwa das tödliche Dreigespann. Gemeint sind drei Eigenschaften, die ein Agent gleichzeitig haben kann:

1. Zugriff auf private Daten („Access to your private data“),
2. Kontakt mit nicht vertrauenswürdigen Inhalten („Exposure to untrusted content“),
3. die Möglichkeit, nach außen zu kommunizieren („The ability to externally communicate“).

Sind alle drei zugleich gegeben, kann ein Angreifer den Agenten laut Willison leicht dazu bringen, private Daten auszulesen und an sich zu senden. Der Grund: Sprachmodelle befolgen Anweisungen, die in beliebigen Inhalten stecken, und gegen solche versteckten Anweisungen gibt es bislang keine hundertprozentige Absicherung. Der sicherste Weg ist deshalb, die Kombination zu vermeiden.

Übertragen auf die Entwicklungsumgebung heißt das: Ein Coding-Agent liest Quelltext und Tickets (private Daten), verarbeitet Inhalte, die jemand anderes geschrieben hat, etwa Kommentare in einem Ticket oder Dokumente aus einem Repository (nicht vertrauenswürdige Inhalte), und kann über ein angebundenes Werkzeug etwas versenden oder veröffentlichen (Kommunikation nach außen). Ob das bei Ihnen zutrifft, hängt nicht vom Copilot ab, sondern davon, welche MCP-Server angebunden sind. Genau diese Anbindung macht die neue Einstellung steuerbar.

Wir sagen ausdrücklich nicht, dass die Einstellung Angriffe verhindert. GitHub behauptet das auch nicht. Sie verändert nur eine Voraussetzung: Was nicht automatisch startet, muss bewusst gestartet werden. Das ist ein Moment, in dem ein Mensch entscheiden kann.

Standardmodell per Richtlinie: Wer entscheidet, mit welchem Modell gearbeitet wird?

Die zweite Neuerung wirkt auf den ersten Blick wie eine Komfortfunktion, hat aber eine organisatorische Bedeutung. Wenn Administratoren ein Standardmodell für neue Unterhaltungen festlegen können, wird die Modellwahl zu einer Entscheidung des Unternehmens statt zu einer Gewohnheit jedes einzelnen Entwicklers.

Das hat drei praktische Folgen, die wir als Überlegungen verstehen, nicht als Aussagen der Quelle:

• Nachvollziehbarkeit: Wenn das Standardmodell bekannt ist, lässt sich im Nachhinein leichter erklären, womit ein Ergebnis entstanden ist. Das ist hilfreich, wenn ein Kunde oder ein Prüfer fragt, wie ein Stück Code zustande gekommen ist.
• Freiheit bleibt erhalten: Laut Quelle können Nutzer weiterhin bewusst ein anderes Modell wählen. Die Richtlinie legt also einen Ausgangspunkt fest, sie sperrt nicht. Wollen Sie mehr Verbindlichkeit, brauchen Sie zusätzlich eine Absprache im Team.
• Kosten- und Datenfragen: Verschiedene Modelle können unterschiedliche Kosten und unterschiedliche Datenverarbeitungsbedingungen haben. Die Quelle nennt dazu nichts. Klären Sie das mit Ihrem Datenschutzbeauftragten und dem Anbieter, bevor Sie ein Standardmodell festlegen.

Eine Faustregel, die sich in der Praxis bewährt: Legen Sie das Standardmodell nicht nach Leistung allein fest, sondern nach der Frage, für welche Art von Code es gedacht ist. Für interne Hilfswerkzeuge gelten andere Anforderungen als für Code, der Kundendaten verarbeitet.

Die Fix-Taste: schneller, aber nicht ohne Durchsicht

Die dritte Neuerung ist die, die Entwickler im Alltag am ehesten bemerken. Zeigt die Entwicklungsumgebung einen Fehlerhinweis, genügt ein Klick auf „Fix“, und Copilot schlägt im Inline-Chat eine Reparatur vor. Das spart den Weg über das Kopieren der Fehlermeldung in ein Chatfenster.

Für die Frage, wie viel Zeit das spart, gibt die Quelle keinen Wert an. Wir erfinden deshalb keinen. Wenn Sie den Nutzen für Ihr Team abschätzen wollen, hilft eine Beispielrechnung, die wir ausdrücklich als solche kennzeichnen.

Beispielrechnung (keine Messung, keine Quellenangabe): Angenommen, ein Entwickler behebt täglich zehn kleine Diagnosehinweise, und jede Behebung dauert ohne Hilfe im Schnitt fünf Minuten. Das sind 50 Minuten am Tag. Würde die Fix-Aktion davon die Hälfte abnehmen, wären das rund 25 Minuten pro Tag oder gut zwei Stunden pro Woche und Entwickler. Ob diese Annahmen bei Ihnen stimmen, müssen Sie selbst messen. Wichtiger als die Zahl ist die Gegenfrage: Wer schaut sich jede vorgeschlagene Reparatur an, bevor sie in den Code übernommen wird?

Hier liegt der eigentliche Punkt. Ein Fix, den ein Agent vorschlägt, ist ein Vorschlag. Er kann richtig sein, er kann aber auch einen Fehler nur verdecken, eine Prüfung abschwächen oder an anderer Stelle etwas verändern, das niemand erwartet. Je einfacher die Bedienung wird, desto wichtiger ist die Regel, dass vorgeschlagene Änderungen vor der Übernahme angesehen werden.

Welcher Agent von Amazing Agents dazugehört: der Code-Operator

Auf amazing-agents.com beschreiben wir den Agenten „Code-Operator“ so: Er erfasst Fehler, schreibt Korrekturen und erstellt Pull-Requests, vom Ticket bis zum Einsatz, nachvollziehbar und mit Freigabe an den kritischen Stellen. Die Beschreibung der Webseite führt als Umfeld DevOps, GitHub und CI/CD an.

Wichtig für die Einordnung: Copilot in JetBrains ist ein Produkt von GitHub und nicht Teil unseres Angebots. Wir ordnen die Meldung dem Code-Operator zu, weil sie dasselbe Muster betrifft, das wir bei diesem Agenten bearbeiten: ein Agent, der im Entwicklungsumfeld Fehler behebt, und die Frage, welche Werkzeuge er erreichen darf und wer seine Änderungen freigibt. Wir behaupten nicht, dass der Code-Operator mit Copilot zusammenarbeitet.

Aus der Arbeit am Code-Operator ergeben sich vier Fragen, die wir auch für jeden anderen Coding-Agenten stellen würden:

1. Reichweite: Welche Systeme, Dateien und Werkzeuge kann der Agent erreichen? Gehört jedes davon zur Aufgabe?
2. Start: Startet ein Werkzeug von selbst oder erst, wenn jemand es bewusst aktiviert?
3. Freigabe: Wer prüft eine Änderung, bevor sie in das gemeinsame Projekt gelangt?
4. Spur: Lässt sich später nachvollziehen, was der Agent getan hat und womit?

Die neue Einstellung von GitHub unterstützt die zweite Frage. Die anderen drei beantwortet keine Funktion, sondern Ihre Organisation.

Mit und ohne Freigabe-Schritt: ein konkreter Vergleich

Der Kern unserer Arbeit ist der Unterschied zwischen einem Agenten ohne Rahmen und einem Agenten mit Grenzen und Freigabe-Schritt. Am Beispiel der Entwicklungsumgebung sieht er so aus.

Ohne Freigabe-Schritt gilt: Angebundene Werkzeuge starten von selbst, jeder Entwickler arbeitet mit dem Modell, das ihm gerade einfällt, und vorgeschlagene Reparaturen landen direkt im Code. Das funktioniert, solange nichts passiert. Kommt es zu einem Fehler oder zu einer Manipulation durch einen Inhalt, den der Agent gelesen hat, gibt es keinen Moment, an dem ein Mensch die Chance hatte, einzugreifen.

Mit Freigabe-Schritt gilt: Welche Werkzeuge starten dürfen, ist festgelegt. Das Standardmodell ist eine bewusste Entscheidung. Vorgeschlagene Änderungen gehen erst nach Durchsicht in den gemeinsamen Code. Der Autostart eines Werkzeugs, das viel erreichen kann, ist abgeschaltet, und es wird nur bei Bedarf gestartet.

Der Unterschied kostet etwas Zeit, nämlich die Minuten für die Durchsicht und einmalig die Stunden für die Regeln. Er verschafft Ihnen dafür etwas, das ein schneller Agent allein nicht liefert: die Möglichkeit, zu erklären, was geschehen ist, und Fehler früh zu bemerken.

Das können Sie diese Woche tun

Auch wenn Sie die Funktionen noch nicht aktivieren, können Sie die Grundlagen jetzt legen. Drei Schritte reichen für den Anfang.

1. Bestandsaufnahme (ein Gespräch mit Ihrem Entwicklungsteam): Fragen Sie, welche KI-Assistenten genutzt werden, in welchen Entwicklungsumgebungen und welche MCP-Server angebunden sind. Lassen Sie die Antworten aufschreiben. Gibt es keine Antwort, ist das bereits ein Ergebnis.
2. Prüffrage anwenden: Gehen Sie für jeden angebundenen Server die drei Eigenschaften des tödlichen Dreigespanns durch. Hat ein Agent Zugriff auf private Daten, liest fremde Inhalte und kann etwas nach außen senden, braucht er eine Einschränkung oder einen Freigabe-Schritt, bevor er nach außen kommuniziert.
3. Regel festhalten: Schreiben Sie in einem Satz auf, welche Werkzeuge automatisch starten dürfen, wer ein Standardmodell festlegt und dass keine Agenten-Änderung ohne Durchsicht in das Hauptprojekt gelangt. Prüfen Sie dann in Ihrer Copilot-Verwaltung, ob und in welchem Tarif die Steuerung für Sie verfügbar ist.

Falls Ihr Team bisher keine Coding-Agenten nutzt, ist das kein Versäumnis. Nutzen Sie die Zeit, um die vier Fragen aus dem vorigen Abschnitt zu beantworten, bevor der erste Agent startet. Dann beginnen Sie mit Regeln statt mit Aufräumarbeiten.

Was die Quelle nicht hergibt: Grenzen dieser Einordnung

Der Vollständigkeit halber nennen wir, was wir nicht belegen können.

• Die Quelle nennt keine Messwerte zu Zeitersparnis oder Qualität. Die Rechnung in diesem Artikel ist ein Beispiel.
• Die Quelle nennt weder Tarife noch einen Preview-Status noch Regionen. Wir können deshalb nicht sagen, ob und für welche Kunden die Funktionen im Detail verfügbar sind.
• Die Meldung beschreibt ausdrücklich Copilot und Claude bei der MCP-Einstellung. Für andere Assistenten oder andere Entwicklungsumgebungen haben wir nichts geprüft.
• Das Denkmodell des tödlichen Dreigespanns stammt von Simon Willison und ist keine Aussage von GitHub. Wir verwenden es als Prüffrage, nicht als Bewertung des Produkts.
• Die Ankündigung ersetzt nicht die offizielle Dokumentation. Prüfen Sie die Details dort, bevor Sie Regeln für Ihr Team ableiten.

Fazit

Die Meldung von GitHub ist eine kleine, aber aufschlussreiche Verbesserung. Sie zeigt, wohin sich der Alltag mit Coding-Agenten entwickelt: weg vom einzelnen Chatfenster, hin zu Werkzeugen, die sich mit der Umgebung verbinden und die ein Unternehmen deshalb steuern können muss. Dass es nun eine Einstellung gibt, mit der sich der automatische Start von MCP-Servern abschalten lässt, ist ein Zeichen dafür, dass die Anbieter dieses Bedürfnis ernst nehmen.

Der Unterschied, auf den es am Ende ankommt, ist der zwischen einem Agenten ohne Rahmen und einem Agenten mit Grenzen und Freigabe-Schritt. Der erste arbeitet schnell, bis etwas Unerwartetes passiert. Der zweite arbeitet planbarer, weil vorab geklärt ist, welche Werkzeuge er erreicht, was er tun darf und was ein Mensch prüft. Werkzeuge wie die neue Einstellung machen diesen zweiten Weg ein Stück einfacher. Er bleibt aber eine Entscheidung Ihres Unternehmens.

Quellen: GitHub Changelog, „New controls and chat improvements in Copilot for JetBrains“, 10. Oktober 2026 (github.blog/changelog/2026-10-10-new-controls-and-chat-improvements-in-copilot-for-jetbrains/). Simon Willison, „The Lethal Trifecta for AI Agents“, 16. Juni 2025 (simonwillison.net/2025/Jun/16/the-lethal-trifecta/).