Gemini CLI Release v0.67.0 verbindet Sandbox-Arbeit mit dem Editor

Googles Gemini CLI Release v0.67.0 fügt Editor-Konnektivität innerhalb von Container-Sandboxes hinzu und verschärft zugleich die Kontrolle über Abbrüche, Berechtigungen und Dateiänderungen. Das am 4. November veröffentlichte Update greift ein praktisches Spannungsverhältnis auf: Entwickler möchten nützliche Automatisierung, ohne die Kontrolle über ihre Rechner aufzugeben. Seine Bedeutung hängt davon ab, wie sich diese Grenzen im Arbeitsalltag verhalten.

Das deutlichste Beispiel verbindet eine Sandbox – eine Umgebung, die den Zugriff eines Programms einschränkt – mit dem Editor des Entwicklers außerhalb dieser Umgebung. Diese Verbindung ist relevant, weil Isolation den Feedback-Kreislauf unterbrechen kann, den Entwickler zur Prüfung vorgeschlagener Änderungen nutzen. Das Release soll dieses Feedback erhalten, ohne der Sandbox uneingeschränkten Zugriff auf den Editor zu gewähren.

Claude Code bietet einen hilfreichen Vergleich, weil dessen Dokumentation Berechtigungsentscheidungen ebenfalls von Einschränkungen des Betriebssystems trennt. Das Gemini-Update gehört in diese operative Diskussion. Entscheidend ist, ob ein Agent nützlich bleibt, wenn seine Umgebung begrenzt, was er erreichen, ändern und weiter ausführen kann.

Was Gemini CLI Release v0.67.0 verändert

Dieses Release konzentriert sich auf die Infrastruktur rund um Coding-Assistance: Ausführungsgrenzen, Editor-Kontext und vorhersehbare Kontrolle.

Das offizielle Release-Changelog nennt die Container-Editor-Bridge neben der Modellerkennung und mehreren Verhaltenskorrekturen. Diese Änderungen bedienen unterschiedliche Arbeitsabläufe, teilen jedoch ein praktisches Anliegen. Entwickler müssen verstehen, was der Agent sehen kann und was er als Nächstes tun wird.

Das Update ergänzt einen models-Befehl und ein --list-models-Flag, um verfügbare Modelle zu ermitteln. Außerdem nennt es Korrekturen bei Editor-Workspace-Pfaden, dem mehrfachen Laden von Agenten und Abbrüchen. Diese Einträge beschreiben Produktverhalten, nicht den Nachweis besserer Schlussfolgerungen oder höherer Coding-Genauigkeit.

Diese Unterscheidung ist bei der Bewertung der Ankündigung wichtig. Eine Release-Nummer belegt keine verbesserte Aufgabenerledigung, und ein langes Changelog misst keine Zuverlässigkeit. Die veröffentlichten Änderungen benennen stattdessen konkrete Situationen, die die Maintainer verbessern wollten.

Für Leser, die Änderungen an Gemini CLI verfolgen, ist der Arbeitsablauf die relevante Analyseeinheit. Wer ein kurzes Terminal-Gespräch führt, begegnet anderen Risiken als jemand, der den Agenten in unbeaufsichtigte Jobs einbindet. Auch eine Editor-Verbindung hat unterschiedliche Bedeutung, je nachdem, ob der Agent lokal oder in einem eingeschränkten Container läuft.

Betrachten wir einen beispielhaften Entwickler, der eine automatisierte Codeänderung prüft. Die vorgeschlagene Änderung muss im richtigen Projekt erscheinen und genügend Kontext bieten, damit sie bewertet werden kann. Wenn Editor und Agent sich über den Workspace uneinig sind, kann eine nützliche Generierung dennoch zu einer verwirrenden Review-Erfahrung führen.

Betrachten wir nun eine Hintergrundaufgabe, die durch ihren überwachenden Prozess beendet wird. Ihr wichtigstes Verhalten in diesem Moment ist, ob ausstehende Aktionen anhalten. Die Qualität einer zuvor erzeugten Erklärung bietet wenig Sicherheit, wenn die Ausführung nach dem Abbruch weiterläuft.

Diese Szenarien erklären, warum Wartungsänderungen Aufmerksamkeit verdienen, ohne eine überzogene Schlagzeile zu erfordern. Das Release betrifft die Übergabe zwischen Absicht und Handlung. Diese Übergabe bestimmt, ob ein Entwickler die Automatisierung mit vorhandenen Werkzeugen und Gewohnheiten beaufsichtigen kann.

Es gibt zudem Grenzen für das, was dieses Release belegt. Die aufgeführten Änderungen liefern keine vergleichenden Produktivitätsergebnisse, Nutzungsdaten oder unabhängige Sicherheitszertifizierung. Sie stützen eine engere Schlussfolgerung: Das Projekt bearbeitet konkrete Integrations- und Kontrollprobleme.

Gemini CLI Release v0.67.0 verdient daher die Aufmerksamkeit von Teams, die Terminal-Agenten in eingeschränkten Umgebungen bereits bewerten. Seine Relevanz ergibt sich aus den betroffenen Betriebsbedingungen. Leser sollten diese Änderungen an ihren eigenen Arbeitsabläufen messen, statt jeden Eintrag als gleich folgenreich zu betrachten.

Der Druck liegt bei Teams, die Agenten über das Terminal hinaus einsetzen

Am stärksten betroffen sind Teams, die Agentenverhalten über Editoren, Container und unbeaufsichtigte Jobs hinweg reproduzierbar gestalten müssen.

Ein Entwickler, der mit einem Assistenten experimentiert, kann sich oft manuell von einer verwirrenden Sitzung erholen. Ein Plattformteam, das gemeinsame Automatisierung unterstützt, steht vor einer anderen Aufgabe. Es muss erklären können, was geschieht, wenn ein Prozess endet, eine Berechtigung verweigert wird oder eine Integration die Verbindung verliert.

Diese Verantwortung erhöht den Druck auf das umgebende Produktdesign. Ein Agent benötigt Zugriff auf nützlichen Kontext, doch dieser Zugriff muss zu den vorgesehenen Grenzen der Umgebung passen. Entwickler benötigen außerdem eine konsistente Möglichkeit, Arbeit zu prüfen, ohne Ereignisse aus verstreuten Terminal-Ausgaben rekonstruieren zu müssen.

Container-Isolation macht diese Spannung sichtbar. Ein Container bündelt einen Prozess und seine Abhängigkeiten in einer getrennten Umgebung. Wird ein Agent dorthin verlagert, kann sich ändern, wie er Dienste auf dem Host-Rechner erreicht – einschließlich des Editors.

Die daraus entstehenden Unannehmlichkeiten haben operative Folgen. Wenn Reviews umständlich werden, müssen Teams entscheiden, ob sie die Integration verbessern, zusätzliche manuelle Arbeit akzeptieren oder die Umgebung überdenken. Das sind Entscheidungen über Arbeitsabläufe mit unterschiedlichen Wartungskosten.

Dies belegt nicht, dass Entwickler Schutzmaßnahmen regelmäßig deaktivieren, wenn Integrationen fehlschlagen. Das geprüfte Material enthält keine Nutzungsstudie, die diese Behauptung stützt. Es erklärt jedoch, warum Benutzerfreundlichkeit zur Bewertung eingeschränkter Ausführung gehört.

Eine Grenze, die Teams verstehen, lässt sich leichter konsistent betreiben. Eine Grenze, deren Verhalten sich unerwartet ändert, erfordert Untersuchung, Dokumentation und Support. Jede ungelöste Ausnahme wird zu etwas, das ein weiterer Entwickler verstehen muss, bevor er dem Arbeitsablauf vertraut.

Der gleiche Druck gilt für unbeaufsichtigte Ausführung, bei der keine Person jede Antwort verfolgt. Ein überwachendes System benötigt vorhersehbare Ergebnisse, wenn es eine Aufgabe beendet. Andernfalls wird die Feststellung, ob die Aufgabe tatsächlich angehalten hat, zu einer separaten Abgleichsaufgabe.

Für Engineering Manager verlagert sich die Bewertung damit über eine erfolgreiche Demonstration hinaus. Eine Demo kann zeigen, dass ein Agent eine Datei bearbeitet. Eine operative Prüfung fragt, ob das umgebende System die Kontrolle wahrt, wenn der Idealfall endet.

Dokumentation wird Teil dieser Prüfung. Teams benötigen eine Aufzeichnung unterstützter Konfigurationen, bekannter Einschränkungen und Entscheidungen über akzeptablen Zugriff. Eine durchsuchbare Wissensdatenbank kann helfen, diese Entscheidungen neben den technischen Materialien festzuhalten, die Entwickler bereits nutzen.

Diese Dokumentation sollte zwischen dem vom Anbieter beschriebenen Verhalten und lokalen Beobachtungen unterscheiden. Ein erfolgreicher Test in einer Umgebung belegt keine universelle Kompatibilität. Die Aufzeichnung von Umgebung und erwartetem Ergebnis macht spätere Vergleiche hilfreicher.

Der praktische Druck liegt daher sowohl bei Maintainer:innen als auch bei Anwendern. Maintainer:innen müssen Grenzen durch das Produkt verständlich machen. Anwender müssen feststellen, ob diese Grenzen zur tatsächlichen Umgebung passen, in der die Arbeit erfolgt.

Die Editor-Bridge wahrt eine Grenze und stellt zugleich Kontext wieder her

Die zentrale Designentscheidung der Bridge belässt Editor-Anmeldedaten auf dem Host und leitet nur eine begrenzte Anzahl von Interaktionen in die Sandbox weiter.

Der Vorschlag zur Sandbox-Editor-Bridge beschreibt einen Host-Prozess, der die Kommunikation über Container-Ausführung und Standard-Ein-/Ausgabeströme vermittelt. Laut dem Beitragenden bleibt das Authentifizierungs-Token des Editors außerhalb des Containers. Der Host beschränkt zudem zulässige Tools und Dateipfade.

Diese Architektur schließt eine konkrete Integrationslücke: einen auf dem Host laufenden Editor und einen innerhalb eines Containers laufenden Agenten. Der Vorschlag beschreibt Unterstützung für Docker, Podman und gVisor. Windows-Hosts und LXC werden zugleich als außerhalb des Umfangs dieser Änderung genannt.

Der Beitragende berichtet von Linux-Validierung mit Docker und gVisor, während für Podman eine eingeschränktere Validierung beschrieben wird. Diese Einschränkung ist wichtig. Der Vorschlag stützt einen konkreten Implementierungsanspruch, belegt jedoch kein identisches Verhalten über jede Laufzeit- und Host-Kombination hinweg.

Die weiterreichende Bedeutung liegt in der Platzierung von Befugnissen. Eine Bridge kann eine nützliche Anfrage weiterleiten, ohne die Zugangsdaten zu übertragen, die uneingeschränkte Kommunikation autorisieren. Damit wird der Host-Vermittler Teil der Kontrolloberfläche, die Entwickler verstehen müssen.

Dies ist ein architektonischer Kompromiss und keine Behauptung, dass Konnektivität risikofrei wird. Ein Vermittler bringt eigene Lebenszyklus- und Ausfallbedingungen mit sich. Teams müssen weiterhin wissen, was geschieht, wenn er verspätet startet, den Kontakt verliert oder eine unerwartete Anfrage erhält.

Für Nutzer von Gemini CLI-Sandboxes lässt sich der Nutzen am leichtesten anhand einer beispielhaften Review-Sitzung verstehen. Ein Agent schlägt eine Änderung im Container vor, während der Entwickler sie über den Host-Editor prüft. Eine nützliche Integration hält diese Aktivitäten verbunden, ohne die Trennung ihrer Umgebungen aufzuheben.

Die Sicherheitsfrage wird dann konkret: Welche Anfragen dürfen diese Verbindung passieren, und wer prüft ihren Umfang? Die pauschale Aussage, ein Agent sei sandboxiert, kann sie nicht beantworten. Die Verbindung selbst benötigt eine ausdrückliche Darstellung des erlaubten Verhaltens.

Das Design unterstreicht außerdem, warum Zugangsdaten getrennt von der Netzwerkerreichbarkeit betrachtet werden sollten. Einen Dienst erreichbar zu machen und die Befugnis zu erteilen, ihn zu nutzen, sind unterschiedliche Entscheidungen. Eine funktionierende Verbindung sollte nicht automatisch Zugang zu allem bedeuten, was der Dienst ausführen kann.

Diese Unterscheidung ist beim Vergleich konkurrierender Ansätze nützlich. Eine Integration, die einfacher wirkt, kann dennoch mehr Befugnisse verteilen, als ein Team beabsichtigt. Umgekehrt kann ein Vermittler engeren Zugriff bewahren, während zusätzliche Komponenten betrieben werden müssen.

Änderungen an Gemini CLI in diesem Bereich sollten daher sowohl anhand der Benutzerfreundlichkeit als auch des Umfangs beurteilt werden. Erhält der Entwickler die erwartete Review-Erfahrung zurück? Lehnt der Host Anfragen außerhalb des vorgesehenen Workspaces ab?

Diese Fragen halten die Diskussion bei beobachtbarem Verhalten. Sie vermeiden zudem, einen stärker verbundenen Agenten mit einem grundsätzlich sichereren Agenten gleichzusetzen. Der Wert ergibt sich aus der jeweiligen Verbindung und den um sie herum angewendeten Grenzen.

Abbruch und Dateiverarbeitung bestimmen, was Kontrolle bedeutet

Der Kontrollvertrag eines Agenten umfasst, auf Aufforderung anzuhalten und das Dateisystemverhalten zu respektieren, auf das Entwickler bereits angewiesen sind.

Die Änderung zur Abbruchbehandlung betrifft nicht-interaktive Ausführung, bei der der Agent ohne ein laufendes Terminal-Gespräch arbeitet. Ihr Beitragender beschreibt verzögerte Tool-Aufrufe, die nach Beendigungssignalen fortgesetzt wurden. Die vorgeschlagene Korrektur verknüpft diese Signale mit dem Abbruch und prüft den Abbruch, bevor weitere Tools eingeplant werden.

Diese Beschreibung betrifft unbeabsichtigte lokale Aktionen nach einer Stopp-Anforderung. Sie belegt nicht, dass jeder Kindprozess oder externe Vorgang stets rückgängig gemacht werden kann. Das Unterbinden weiterer Planung und das Rückgängigmachen einer bereits laufenden Aktion sind unterschiedliche Fähigkeiten.

Ein beispielhafter automatisierter Wartungsjob verdeutlicht diesen Unterschied. Ein überwachendes System beendet den Job, nachdem es entschieden hat, dass dessen Arbeit stoppen soll. Der Betreiber muss dann wissen, ob der Agent nach Erhalt dieser Anweisung noch eine weitere Aktion einplanen kann.

Eine klare Antwort unterstützt sowohl die Nachbereitung von Vorfällen als auch den Routinebetrieb. Ohne sie muss der Operator den Workspace und umliegende Systeme prüfen, um zu rekonstruieren, was geschehen ist. Diese Unsicherheit kann länger bestehen als die ursprüngliche Aufgabe.

Das Verhalten von Dateien schafft eine verwandte Erwartung. Entwickler nutzen Berechtigungen und Dateisystemkonventionen, um zu vermitteln, welche Änderungen akzeptabel sind. Agent-Tools sollten diese Konventionen bewahren, wenn ihr Design verspricht, sie zu berücksichtigen.

Der Fix für Dateiberechtigungen beschreibt eine Regression, die durch atomaren Ersatz eingeführt wurde, bei dem zunächst eine temporäre Datei geschrieben wird, bevor das Ziel ersetzt wird. Laut dem Beitragenden konnte dies schreibgeschützte Dateien ersetzen und hart verknüpfte Pfade voneinander trennen. Harte Links sind unterschiedliche Namen, die auf dieselbe zugrunde liegende Datei verweisen.

Die Änderung fügt eine Prüfung der Schreibbarkeit des Ziels hinzu und verwendet für Dateien mit mehreren harten Links ein direktes Schreiben in die bestehende Datei. Dies sind eng umrissene Implementierungskorrekturen. Sie sollten nicht zu einer Garantie verallgemeinert werden, dass jeder Sonderfall des Dateisystems gelöst ist.

Die zugrunde liegende Lehre reicht über dieses Projekt hinaus. Eine Implementierung kann eine Eigenschaft verbessern und zugleich eine andere verändern, auf die Nutzer angewiesen sind. Eine Datei zu ersetzen und ihren bestehenden Inhalt zu ändern, kann in einem einfachen Test gleichwertig erscheinen, sich andernorts jedoch unterschiedlich verhalten.

Für Engineering-Teams wird Kompatibilität dadurch zu einem Teil der Zuverlässigkeit von Agenten. Eine scheinbar korrekte Bearbeitung muss weiterhin die umgebende Umgebung respektieren. Der relevante Maßstab umfasst sowohl den resultierenden Inhalt als auch die Methode, mit der er erzeugt wurde.

Gemini CLI Release v0.67.0 bringt diese Anliegen gemeinsam mit verbesserter Konnektivität in dieselbe Veröffentlichung. Diese Kombination verdient Aufmerksamkeit, weil eine stärkere Workflow-Integration die Bedeutung eines vorhersehbaren Stopp- und Schreibverhaltens erhöht. Nützlicher Zugriff und verlässliche Zurückhaltung müssen sich gemeinsam entwickeln.

Die verfügbaren Belege bleiben die Release-Aufzeichnungen der Maintainer und Beschreibungen der Beitragenden. Sie benennen beabsichtigte Korrekturen und deren Begründung. Sie ersetzen weder lokale Validierung noch belegen sie einen gemessenen Rückgang operativer Vorfälle.

Weniger Berechtigungsabfragen erfordern weiterhin klare Vertrauensregeln

Weniger wiederholte Bestätigungen sind nur dann nützlich, wenn Entwickler weiterhin verstehen können, welche Eingaben einer Prüfung unterliegen.

Die Änderung des Genehmigungsumfangs unterscheidet externe Ausgabe von Ausgabe, die durch die eigenen Shell-Befehle des Agenten erzeugt wurde. Laut dem Beitragenden bleiben genehmigte Flags und Root-Befehle für die Sitzung genehmigt. Ausgabe aus externem Abruf löst weiterhin die entsprechenden Prüfungen aus.

Dies ist eine Anpassung der Nutzbarkeit innerhalb einer Vertrauensrichtlinie. Sie belegt nicht, dass lokal erzeugte Ausgabe harmlos ist. Die engere Aussage betrifft, welche Informationen die Prüfungen des jeweiligen Flags als externe Eingabe behandeln.

Diese Unterscheidung verhindert eine naheliegende Fehlinterpretation des Releases. Weniger Abfragen bedeuten nicht automatisch schwächeren Schutz, und mehr Abfragen bedeuten nicht automatisch besseren Schutz. Der Nutzen einer Abfrage hängt davon ab, ob sie eine sinnvolle Frage stellt.

Eine Bestätigung, die wiederholt nach derselben bereits verstandenen Aktion fragt, kann Reibung erzeugen, ohne neue Informationen hinzuzufügen. Eine Genehmigung, die sich stillschweigend über ihren erwarteten Umfang hinaus ausweitet, schafft ein anderes Problem. Gutes Interaktionsdesign muss diesen Umfang nachvollziehbar machen.

Für Teams, die Sandbox-Workflows von Gemini CLI bewerten, gehört das Genehmigungsverhalten neben Ausführungsbeschränkungen. Berechtigungen legen fest, ob eine Aktion erlaubt ist. Isolation begrenzt, was der Prozess während ihrer Ausführung erreichen kann.

Die Dokumentation zu den Sandbox-Grenzen von Anthropic bietet einen relevanten Vergleich. Sie beschreibt Betriebssystembeschränkungen für die Shell-Befehle von Claude Code und weist zugleich darauf hin, dass andere Tools und Prozesse außerhalb dieser Grenze liegen. Die Dokumentation unterscheidet ausdrücklich zwischen Sandboxing und Berechtigungsregeln.

Die Produkte sollten anhand dieser Beschreibungen allein nicht eingestuft werden. Sie beschreiben unterschiedliche Komponenten und Geltungsbereiche, ohne hier eine gemeinsame Bewertung zu liefern. Der nützliche Vergleich liegt in der Verpflichtung, zu erklären, wo jede Grenze beginnt und endet.

Diese Verpflichtung wird besonders wichtig, wenn ein Agent mehrere Tools verwendet. Eine Beschränkung der Shell-Ausführung beschreibt nicht zwingend das Verhalten von Datei-Tools oder externen Integrationen. Produktbezeichnungen können diese Unterschiede verschleiern, wenn Leser annehmen, jede Aktion folge demselben Pfad.

Es gibt eine skeptische Lesart von Geminis Update, die Raum verdient. Die Korrekturen zeigen, dass gewöhnliche operative Erwartungen zusätzliche Arbeit erforderten. Sie erinnern Anwender außerdem daran, dass eine ausgefeilte Interaktion mit überraschendem Verhalten in weniger sichtbaren Ausführungspfaden einhergehen kann.

Das ist kein Beleg für ungelöste Ausnutzung und kein Grund, einen Vorfall zu erfinden. Es ist ein Grund, Aussagen verhältnismäßig zu halten. Ein Changelog dokumentiert Änderungen, während Absicherung eine Bewertung erfordert, die zur Umgebung und ihren Folgen passt.

Die stärkste Interpretation ist daher konkret. Das Projekt verfeinert das Zusammenspiel von Berechtigungsentscheidungen, lokaler Ausführung und Nutzerkontrolle. Ob diese Verfeinerungen eine bestimmte Bereitstellung verbessern, bleibt eine beobachtbare Frage und keine Schlussfolgerung, die von der Versionsnummer geliefert wird.

Was nach dem Release zu beobachten ist

Die nächsten nützlichen Belege werden Kompatibilität, Abbruchverhalten und die Klarheit von Genehmigungsentscheidungen betreffen.

Das erste Signal sind Folgeberichte zur Editor-Konnektivität über unterstützte Container-Konfigurationen hinweg. Erfolgreiche Berichte sollten den beteiligten Host, die Laufzeitumgebung und das Prüfverhalten benennen. Berichte über reproduzierbare Fehler würden die praktische Reichweite der Bridge eingrenzen.

Das ist wichtig, weil Architektur und Kompatibilität unterschiedliche Fragen beantworten. Die Bridge beschreibt, wie die Kommunikation funktionieren soll. Bereitstellungserfahrungen zeigen, ob Entwickler sich in den Umgebungen, die sie tatsächlich betreuen, auf dieses Verhalten verlassen können.

Das zweite Signal sind Regressionsbelege rund um das Stoppen und Dateiänderungen. Eine Regression ist die Rückkehr eines Verhaltens, das eine frühere Änderung korrigieren sollte. Tests und reproduzierbare Berichte sollten zwischen ausstehenden Aktionen und bereits laufenden Aktionen unterscheiden.

Belege dafür, dass ein Abbruch zuverlässig neue Planung verhindert, würden das Vertrauen in unbeaufsichtigte Workflows stärken. Wiederholte Berichte über Aktionen nach einem Abbruch würden dieses Vertrauen schwächen. Dieselbe Logik gilt für die Bewahrung von Berechtigungen bei Dateibearbeitungen.

Das dritte Signal ist, ob sich das Genehmigungsverhalten leichter erklären lässt, ohne externe Eingaben zu verschleiern. Nützliche Belege würden zeigen, wann eine Abfrage erscheint, was eine vorherige Genehmigung abdeckt und wann die Genehmigung zurückgesetzt wird. Berichte über einen verwirrenden Umfang würden auf weiteren Arbeitsbedarf hinweisen.

Dieses Signal ist wichtig, weil Vorhersehbarkeit die Aufsicht unterstützt. Entwickler sollten eine Entscheidung anhand der angegebenen Regeln vorhersehen können. Wenn sie das nicht können, werden weniger Unterbrechungen allein keine bessere Erfahrung belegen.

In den kommenden Monaten werden diese Signale eine solidere Grundlage für ein Urteil bieten als die Länge des Changelogs. Sie verbinden das Release mit konkreten Betriebsbedingungen. Sie lassen außerdem Raum sowohl für erfolgreiche Einführung als auch für dokumentierte Einschränkungen.

Die daraus resultierende Bewertung sollte dem Umfang der Belege angemessen bleiben. Eine funktionierende Editor-Bridge würde die Integrationsaussage stützen. Zuverlässiger Abbruch würde die Kontrollaussage stützen. Keines der beiden Ergebnisse allein würde belegen, dass Gemini einen anderen Agenten bei Programmieraufgaben übertrifft.

Für Leser, die entscheiden, was sie als Nächstes prüfen sollten, beginnt die Untersuchung bei dem Workflow, der in ihrer Umgebung die größten Folgen hat. Halten Sie die Release-Aufzeichnung neben Ihre eigenen Beobachtungen und trennen Sie erwartetes Verhalten von verifizierten Ergebnissen. Wenn Sie auf Container angewiesen sind, prüfen Sie die Editor-Verbindung und ihren Umfang. Wenn Sie unbeaufsichtigte Aufgaben ausführen, prüfen Sie das Stoppverhalten und den resultierenden Workspace. Wenn Berechtigungsabfragen die Arbeit unterbrechen, prüfen Sie, was eine Genehmigung tatsächlich autorisiert. Gemini CLI Release v0.67.0 bietet für diese Bewertungen konkrete Änderungen zur Untersuchung. Nutzen Sie diese Konkretheit, um eine fundierte Einführungsentscheidung zu treffen, und bewahren Sie die Erkenntnisse auf, damit der nächste Entwickler verstehen kann, warum der Workflow ihr Vertrauen verdient.