Ein Sicherheitsproblem in Roo Code wurde mit einem CVSS-Wert von 8,1 bewertet; betroffen war eine Konstellation aus MCP, automatisch erlaubten Dateischreibvorgängen und manipulierten Eingaben. Die offizielle Sicherheitswarnung beschreibt den Fehler und die behobene Version.

Symptom: Roo Code hält Sie bei jeder Dateiänderung, jedem Terminalbefehl und jedem MCP-Aufruf auf, aber eine globale Freigabe wäre Ihnen zu riskant.
Schnellste Lösung: Aktivieren Sie automatische Freigaben nicht vollständig, sondern lassen Sie sie in einer isolierten Umgebung stufenweise für Lesen, begrenztes Bearbeiten, geprüfte Befehle, Browseraktionen und einzelne MCP-Werkzeuge zu.

Dieser Leitfaden ist für Sie gedacht, wenn Sie Roo Code regelmäßig als Coding-Agent verwenden, ihn auf einer Remote-Entwicklungsmaschine oder einem Cloud-Mac unbeaufsichtigt laufen lassen möchten oder als Sicherheits- und Plattformverantwortlicher die Berechtigungsgrenzen eines Agenten abnehmen müssen. Wenn Sie lediglich gelegentlich Code erklären lassen, benötigen Sie diese weitreichende Freigabestrategie nicht.

Die Freigabe ist eine Berechtigungskette, kein Produktivitätsschalter

Roo Code unterscheidet mehrere Werkzeuggruppen: Lesen, Bearbeiten, Terminalbefehle und MCP. Je nach Modus können diese Gruppen unterschiedlich verfügbar sein. Die offizielle Übersicht zu Werkzeuggruppen und Modusberechtigungen beschreibt unter anderem Dateiänderungen, Befehlsausführung und externe MCP-Aufrufe.

Die wichtige Konsequenz lautet: Eine automatische Freigabe beantwortet nicht die Frage, ob eine Aufgabe fachlich sicher ist. Sie beantwortet nur, ob Roo Code den nächsten Aktionsschritt ohne Ihre Rückfrage ausführen darf. Das Risiko entsteht aus der Kombination von:

  • Arbeitsbereich: Darf der Agent nur das geklonte Repository sehen oder auch übergeordnete Verzeichnisse?
  • Dateirechten: Kann er nur Testdateien ändern oder auch Konfiguration, CI/CD-Skripte und Zugangsdaten überschreiben?
  • Shell-Kontext: Wird ein Befehl in einem kontrollierten Verzeichnis mit einem eingeschränkten Benutzer ausgeführt?
  • Netzwerk: Kann der Prozess beliebige externe Ziele erreichen oder nur definierte Paket- und API-Endpunkte?
  • MCP: Welche Werkzeuge stehen zur Verfügung, welche Parameter akzeptieren sie und welche Credentials verwenden sie?
  • Wiederherstellung: Können Sie den Zustand nach einem fehlerhaften Lauf zuverlässig per Git oder Snapshot zurücksetzen?

Die Dokumentation zu automatischen Freigaben behandelt Lesen, Bearbeiten, Befehle, Browser, MCP, Moduswechsel und wiederholte Anfragen als getrennte Aktionsarten. Die Übersicht zur automatischen Bestätigung sollte deshalb gemeinsam mit der konkreten Oberfläche Ihrer installierten Version geprüft werden.

Für den Anfang bleiben daher immer manuell:

  • Lesen oder Schreiben von API-Schlüsseln, Zertifikaten und Umgebungsdateien,
  • Änderungen an Systemverzeichnissen und Agent-Konfigurationen,
  • Installationen aus unbekannten Quellen,
  • Lösch-, Bereinigungs- und Überschreibbefehle,
  • Veröffentlichungen, Deployments und Änderungen an Produktionsressourcen,
  • MCP-Aufrufe mit Schreib-, Zahlungs-, Administrations- oder Datenexportfunktion.

Phase 1: Lesen und begrenztes Bearbeiten sauber abnehmen

Beginnen Sie in einem eigens angelegten Repository oder einem Testzweig. Verwenden Sie nicht sofort das Arbeitsverzeichnis, in dem Ihre lokalen SSH-Schlüssel, Cloud-Anmeldungen, Produktionskonfigurationen oder privaten Notizen liegen.

Schritt 1: Arbeitsbereich festlegen

Legen Sie den erlaubten Projektpfad eindeutig fest und prüfen Sie anschließend, ob Roo Code tatsächlich nur dort arbeitet. Testen Sie dabei nicht nur normale Dateien, sondern auch:

  1. einen Unterordner mit Testdaten,
  2. eine Datei außerhalb des erwarteten Projektpfads,
  3. einen symbolischen Link auf ein übergeordnetes Verzeichnis,
  4. eine ignorierte Datei mit absichtlich ungefährlichem Inhalt,
  5. eine Datei im .roo-Verzeichnis.

Die Prüfung auf symbolische Links ist wichtig, weil eine scheinbare Projektgrenze nicht automatisch bedeutet, dass jedes referenzierte Ziel ebenfalls innerhalb dieser Grenze liegt. Dokumentieren Sie den erlaubten Pfad, die verwendeten Roo-Code-Einstellungen und die Antwort auf den absichtlichen Überschreitungsversuch.

Durchgangskriterium: Roo Code liest nur die vorgesehenen Dateien und verweigert oder stoppt beim Zugriff außerhalb des Testbereichs.
Stoppkriterium: Der Agent folgt einem Link in einen privaten oder übergeordneten Bereich, ohne eine zusätzliche Freigabe zu verlangen.

Schritt 2: Nur reversible Änderungen erlauben

Aktivieren Sie Bearbeitungen erst, nachdem Sie die Lesegrenze geprüft haben. Verwenden Sie einen Testzweig und erstellen Sie vor dem Lauf einen nachvollziehbaren Git-Stand. Lassen Sie Roo Code eine kleine, klar beschriebene Änderung durchführen, etwa eine Dokumentationsdatei oder einen isolierten Testfall.

Prüfen Sie danach:

  • den vollständigen git diff,
  • neu angelegte und gelöschte Dateien,
  • Änderungen an Dateirechten,
  • Änderungen an versteckten Konfigurationsdateien,
  • Änderungen an .roo-Dateien,
  • die Wiederherstellung mit git restore oder einem gleichwertigen Rückrollmechanismus.

Die Sicherheitswarnung zu einer früheren MCP-Schwachstelle zeigt, weshalb .roo-Konfigurationen nicht wie gewöhnliche Projektdokumentation behandelt werden sollten: In der beschriebenen Angriffskette konnte ein automatisch erlaubter Dateischreibvorgang zusammen mit MCP zu beliebiger Befehlsausführung führen. Lesen Sie die offizielle Sicherheitsanalyse, bevor Sie Schreibfreigaben für Agent-Konfigurationsdateien aktivieren.

Durchgangskriterium: Jede Änderung ist im Diff sichtbar und vollständig rücksetzbar.
Stoppkriterium: Roo Code verändert Zugangsdaten, Agent-Konfigurationen, CI/CD-Dateien oder Dateien außerhalb des Testzweigs.

Als Ergänzung sollten Sie Ihre Datenschutzanforderungen für Remote-Sitzungen, Protokolle und Zugangsdaten festhalten. Die Datenschutzerklärung von SSHMac ist dafür ein sinnvoller Bezugspunkt, ersetzt aber keine eigene Prüfung der von Ihnen eingesetzten Modell-, MCP- und Cloud-Dienste.

Phase 2: Terminalbefehle nach Wirkung statt nach Namen freigeben

Terminalbefehle sind die schwierigste Kategorie, weil der sichtbare Befehlsname wenig über die tatsächliche Wirkung aussagt. npm, make, xcodebuild oder ein internes Skript können je nach Arbeitsverzeichnis, Umgebungsvariablen und Parametern sehr unterschiedliche Konsequenzen haben.

Die automatische Freigabe sollte deshalb nicht auf einem globalen „Shell erlaubt“-Schalter beruhen. Erstellen Sie stattdessen eine kleine Allowlist für Befehle, deren Wirkung Sie vorher geprüft haben.

Schritt 3: Vier repräsentative Befehlsgruppen testen

Führen Sie die Abnahme in dieser Reihenfolge durch:

  1. Build: Ein lokaler Build mit festem Arbeitsverzeichnis und ohne Veröffentlichungsaktion.
  2. Test: Unit- oder Integrationstests, die keine externen Daten verändern.
  3. Abhängigkeiten: Eine Installation nur aus einer freigegebenen Lock-Datei und innerhalb einer kontrollierten Umgebung.
  4. Bereinigung: Ein Skript, das ausschließlich bekannte temporäre Verzeichnisse löscht.

Prüfen Sie bei jedem Befehl die vollständige Kommandozeile, nicht nur das erste Token. Achten Sie auf Shell-Operatoren wie &&, ;, Weiterleitungen, Kommandoersetzung, Variablenexpansion und rekursive Pfadangaben. Ein Befehl kann außerdem durch ein verändertes Arbeitsverzeichnis oder eine manipulierte Skriptdatei eine andere Wirkung entfalten als bei der ersten Prüfung.

Durchgangskriterium: Der Befehl ist vorhersehbar, wiederholbar, auf den Testbereich beschränkt und nach einem Fehlschlag wiederherstellbar.
Stoppkriterium: Er benötigt unklare Zugangsdaten, schreibt außerhalb des Projekts, lädt beliebige Skripte nach oder kann mit einer kleinen Parameteränderung Daten löschen oder veröffentlichen.

Veröffentlichen Sie keine globale Liste mit scheinbar harmlosen Präfixen wie git, python oder node, wenn diese Programme beliebige Unterbefehle und Dateien akzeptieren. Sicherer ist eine engere Regel für ein konkretes Skript mit festem Pfad und geprüften Argumenten. Deployment, Datenbankmigration, Secret-Verwaltung, Paketfreigabe und Löschung bleiben manuell.

Roo Code bietet zusätzlich eine Begrenzung der aufeinanderfolgenden automatisch bestätigten Anfragen. Die offizielle Dokumentation nennt als Beispiel eine Grenze von fünf Anfragen; vor der nächsten Anfrage pausiert der Agent und verlangt eine neue Bestätigung. Die Erklärung zu Anfragelimits und Kostenkontrolle beschreibt diese Funktion ausdrücklich als zusätzliche Begrenzung für längere Aufgaben.

Diese Grenze ist kein Ersatz für Rechteentzug. Sie reduziert die Anzahl automatischer Schritte, verhindert aber nicht, dass ein einzelner freigegebener Befehl zu weit reicht.

Phase 3: Browser und MCP-Werkzeuge getrennt behandeln

Browseraktionen und MCP-Werkzeuge wirken oft wie externe Erweiterungen, sind aber Teil derselben Berechtigungskette. Ein Browser kann Formulare absenden oder Dateien herunterladen. Ein MCP-Server kann Daten lesen, schreiben, APIs aufrufen oder weitere Prozesse starten. Deshalb darf „Server vertrauenswürdig“ nicht mit „jedes Werkzeug unkritisch“ gleichgesetzt werden.

Schritt 4: MCP-Server und einzelne Werkzeuge abnehmen

Prüfen Sie zuerst die globale MCP-Freigabe. Danach kontrollieren Sie jedes einzelne Werkzeug, das Roo Code verwenden darf. Die Freigabeebenen müssen getrennt dokumentiert werden:

  • Lesen: Datenbankabfrage, Dateisuche, Dokumentabruf,
  • Schreiben: Datensatzänderung, Datei-Upload, Ticket- oder Eintragsbearbeitung,
  • externe Aktion: Nachricht senden, Deployment auslösen, API-Aufruf mit Seiteneffekt,
  • sensible Ressource: Zugangsdaten, personenbezogene Daten, interne Dokumente oder Produktionssysteme.

Für jedes erlaubte MCP-Werkzeug gehören mindestens diese Angaben in Ihre Abnahmedokumentation:

  • Name und Version des Servers,
  • Zweck und erwarteter Arbeitsablauf,
  • erlaubte Eingabeparameter,
  • erreichbare Netzwerkziele,
  • verwendete Credentials und deren Umfang,
  • Protokollierung der Aufrufe,
  • Vorgehen zum Deaktivieren und Widerrufen.

Die Roo-Code-Dokumentation beschreibt MCP als eigene Werkzeuggruppe. Offizielle Projekthinweise zeigen außerdem, dass Änderungen an den automatischen Freigaben einzelner MCP-Werkzeuge Auswirkungen auf die Serververbindung haben können. Der dokumentierte Fehlerhinweis zur Einzelwerkzeug-Freigabe ist deshalb vor einer Änderung der MCP-Regeln zu prüfen.

Durchgangskriterium: Ein erlaubtes Werkzeug funktioniert mit begrenzten Parametern; nicht erlaubte Werkzeuge werden nicht ausgeführt oder benötigen eine manuelle Freigabe.
Stoppkriterium: Ein Serverwechsel, eine Konfigurationsänderung oder ein neuer MCP-Eintrag erweitert die effektive Berechtigung unbemerkt.

Für Browseraktionen gelten vergleichbare Regeln: Erlauben Sie zunächst nur das Öffnen bekannter Dokumentations- oder Testseiten. Formulare, Downloads, Uploads und Authentifizierungsseiten gehören in die manuelle Prüfung. Besonders riskant ist eine Kombination aus Browser, automatisch erlaubten Dateischreibvorgängen und einem MCP-Werkzeug, das die heruntergeladenen Inhalte weiterverarbeiten kann.

FAQ: Die vier häufigsten Betriebsfragen

Welche Aktionen darf Roo Code ohne Rückfrage ausführen?

Am ehesten eignen sich schreibgeschützte Datei- und Verzeichnisabfragen sowie eng begrenzte, wiederholbare Tests. Bearbeitungen sollten nur in einem festgelegten Repository und auf einem Testzweig freigegeben werden. Terminalbefehle, Browseraktionen und MCP-Werkzeuge benötigen eine eigene Prüfung, weil ihre Wirkung von Parametern, Umgebung, Netzwerkzugang und hinterlegten Zugangsdaten abhängt.

Welche Risiken entstehen durch automatische Terminalbefehle?

Ein scheinbar harmloser Befehl kann durch Parameter, Shell-Verkettungen, symbolische Links oder ein unerwartetes Arbeitsverzeichnis einen größeren Bereich verändern. Besonders kritisch sind Löschbefehle, Installationsskripte, Deployment-Kommandos, Befehle mit Geheimnissen und Werkzeuge, die Daten an externe Dienste übertragen. Erlauben Sie deshalb keine pauschale Shell-Freigabe.

Wie lässt sich die MCP-Nutzung in Roo Code begrenzen?

Aktivieren Sie zunächst nur die MCP-Funktion, die Sie für den konkreten Arbeitsablauf benötigen. Prüfen Sie danach jedes Werkzeug einzeln nach Lesezugriff, Schreibzugriff, externer Aktion und Zugriff auf sensible Ressourcen. Dokumentieren Sie Eingabeparameter, Credentials, Netzwerkziel und Widerrufsmöglichkeit. Ein vertrauenswürdiger MCP-Server macht nicht automatisch jedes darin angebotene Werkzeug sicher.

Braucht ein unbeaufsichtigter Roo-Code-Lauf eine isolierte Umgebung?

Ja, sobald Roo Code ohne laufende Sichtprüfung Befehle ausführen, Dateien verändern oder MCP-Werkzeuge aufrufen darf. Eine Isolation sollte Arbeitsbereich, Benutzerrechte, Netzwerkzugang, Secrets, Protokolle und Abbruchmechanismen trennen. Eine Sandbox beseitigt jedoch nicht jedes Risiko: Fehlkonfigurationen, manipulierte Eingaben und zu weitreichende Zugangsdaten bleiben möglich.

Phase 4: Remote- und Cloud-Umgebungen mit einem absichtlichen Fehlversuch prüfen

Ein unbeaufsichtigter Lauf gehört nicht auf Ihre tägliche Arbeitsmaschine, sobald er Schreib-, Shell- oder MCP-Rechte besitzt. Das gilt auch für einen Remote-Entwicklungsrechner oder einen Cloud-Mac. Eine grafische Oberfläche oder eine Sandbox kann die Bedienung vereinfachen, beseitigt aber weder übermäßige Credentials noch fehlerhafte Netzwerkfreigaben oder manipulierte Projektinhalte.

Schritt 5: Zwei gegensätzliche Testaufgaben ausführen

Planen Sie in einer isolierten Remote-Umgebung zwei Aufgaben:

  1. Erlaubte Aufgabe: Roo Code ändert eine definierte Testdatei, führt einen festgelegten Testbefehl aus und erstellt ein nachvollziehbares Ergebnis.
  2. Absichtlicher Überschreitungsversuch: Roo Code soll auf eine Datei außerhalb des Arbeitsbereichs zugreifen, einen nicht erlaubten Befehl ausführen oder ein gesperrtes MCP-Werkzeug verwenden.

Prüfen Sie dabei:

  • Benutzer- und Dateirechte,
  • Netzwerkabgang und DNS-Zugriff,
  • Secret-Injektion und Secret-Redaktion in Protokollen,
  • Sitzungs- und Befehlslogs,
  • Timeout und Prozessabbruch,
  • Git-Diff und Wiederherstellung,
  • Alarmierung bei abgewiesenen Aktionen.

Wenn Ihre Aufgabe Xcode oder andere macOS-Werkzeugketten benötigt, testen Sie diese Fähigkeiten separat auf dem Remote-Mac. Ein Ergebnis aus einem Linux-Container lässt sich nicht automatisch auf eine macOS-Entwicklungsumgebung übertragen. Relevant sind unter anderem Schlüsselbundzugriff, Signaturmaterial, lokale Toolchain-Versionen, GUI-Abhängigkeiten und physische oder virtuelle Geräte.

Durchgangskriterium: Die erlaubte Aufgabe wird korrekt abgeschlossen, der Überschreitungsversuch wird protokolliert und blockiert, und der Testzustand lässt sich vollständig zurücksetzen.
Stoppkriterium: Logs fehlen, Secrets erscheinen im Klartext, der Prozess überlebt den Timeout oder die Netzwerkgrenze lässt sich aus dem Arbeitsablauf heraus umgehen.

Für organisatorische Fragen zu Remote-Sitzungen, Zugang und Support können Sie außerdem das SSHMac-Hilfezentrum heranziehen. Die technische Abnahme der Roo-Code-Berechtigungen müssen Sie dennoch auf der konkreten Maschine und mit Ihren eigenen MCP-Servern durchführen.

Phase 5: Nach Änderungen automatisch wieder auf den Prüfstand

Eine einmal erfolgreiche Abnahme bleibt nicht dauerhaft gültig. Sie müssen die Freigaben erneut prüfen, wenn Roo Code aktualisiert wird, ein MCP-Server ausgetauscht oder konfiguriert wird, sich ein Repository-Skript ändert oder ein neues Secret in die Umgebung gelangt.

Setzen Sie für jedes dieser Ereignisse eine kurze Wiederholungsprüfung an:

  1. Einstellungen und erlaubte Werkzeuggruppen vergleichen,
  2. Testzweig oder Snapshot neu erstellen,
  3. erlaubte Aufgabe ausführen,
  4. absichtlichen Überschreitungsversuch wiederholen,
  5. Diff, Logs, Netzwerk und Rückrolle kontrollieren,
  6. Freigabe beibehalten, verkleinern oder widerrufen.

Die offizielle Dokumentation beschreibt Modusberechtigungen und benutzerdefinierte Modi als getrennte Steuerungsmöglichkeiten. Die Anleitung zu benutzerdefinierten Modi zeigt, dass Werkzeuggruppen und Dateigrenzen zusammen betrachtet werden müssen. Ein Modus mit Lesezugriff ist daher nicht automatisch sicher, wenn MCP weiterhin sensible externe Ressourcen erreicht.

Verkleinern Sie die Freigabe, wenn ein Befehl unerwartete Dateien berührt, ein MCP-Server seine Eingabeparameter erweitert, Logs unvollständig sind oder die Rückrolle nicht deterministisch funktioniert. Widerrufen Sie sie vollständig, wenn Zugangsdaten, Produktionssysteme oder nicht überprüfbare externe Aktionen betroffen sind. Die Frage ist nicht, ob Roo Code bisher „nichts kaputt gemacht“ hat, sondern ob Sie die Wirkung jedes erlaubten Schritts nachweisen können.

Abnahmeentscheidung für die Praxis

Die folgende Matrix ist kein Ersatz für einen Testlauf, hilft Ihnen aber bei der Entscheidung, welche Kategorie zuerst geöffnet werden darf:

Aktionsbereich Typische Wirkung Automatische Freigabe bei Manuelle Freigabe oder Sperre bei Abnahmeevidenz
Lesen Dateien und Verzeichnisse abrufen festgelegtem Repository und ohne Secret-Pfade übergeordneten Pfaden, Schlüsselbund, privaten Dokumenten Einstellung, Pfadtest, abgewiesener Zugriff
Bearbeiten Dateien anlegen, ändern oder löschen Testzweig, klarer Dateibereich, Git-Rückrolle Konfiguration, CI/CD, .roo, Produktionsdateien Diff, neue Dateien, Rückrolltest
Terminal Builds, Tests, Skripte geprüfter Befehl, fester Pfad, begrenzte Parameter Löschen, Installieren aus unbekannter Quelle, Deployment, Secrets vollständige Kommandozeile, Log, Exit-Status
Browser Seiten öffnen und Aktionen ausführen bekannte, schreibgeschützte Testseiten Formulare, Uploads, Downloads, Authentifizierung Zielseite, Netzwerklog, blockierter Seiteneffekt
MCP externe Daten und Aktionen einzeln geprüftes Werkzeug mit begrenzten Eingaben Schreiben, Administration, Export, sensible Ressourcen Serverversion, Parameter, Credential- und Widerrufstest

Wenn Sie Roo Code derzeit auf einem lokalen Rechner, einer gemeinsam genutzten Remote-Umgebung oder einer unisolierten Cloud-Instanz betreiben, liegen die typischen Nachteile in der fehlenden Trennung von Arbeitsbereich und persönlichen Daten, in zu weitreichenden Shell-Rechten und in schwer nachvollziehbaren MCP- oder Netzwerkzugriffen. Ein speziell isolierter Mac-Arbeitsplatz kann diese Grenzen klarer abbilden, ersetzt aber weder die Allowlist noch die Protokoll- und Rückrollprüfung.

Für einen kurzfristigen Test, einen reproduzierbaren CI/CD-Lauf oder eine getrennte Remote-Entwicklungsumgebung kann es deshalb sinnvoll sein, einen Mac über SSHMac zu mieten, statt automatische Freigaben auf Ihrer täglichen Arbeitsmaschine dauerhaft zu erweitern. Das passt besonders dann, wenn Sie die Umgebung nach der Abnahme wieder verwerfen möchten oder Xcode- und macOS-Werkzeugketten benötigen. Für dauerhafte Hochlast, spezielle Hardwareanschlüsse oder streng kontrollierte interne Daten ist ein eigener Mac weiterhin die ehrlichere Wahl.

Beginnen Sie nicht mit der bequemsten Einstellung. Kopieren Sie diese Abfolge in Ihre Betriebsdokumentation, führen Sie zuerst einen risikoarmen Lauf in einer isolierten Umgebung aus und erweitern Sie die Roo-Code-Freigaben erst dann, wenn Protokollierung, Überschreitungsblockade und Rückrolle gemeinsam bestanden sind.