Vorschlag zur Ergänzung einer JetBrains-IDE-Erkennung

(github.com/google-gemini)

1 Punkte von GN⁺ 2026-01-24 | 2 Kommentare | Auf WhatsApp teilen

Anfrage zur Ergänzung einer Funktion, damit Gemini CLI JetBrains-IDs nativ erkennt
Derzeit akzeptiert die CLI nur Werte bestimmter Umgebungsvariablen wie VS Code (TERM_PROGRAM), sodass JetBrains-Nutzer Umgebungsvariablen vortäuschen müssen, um die Funktion zu aktivieren
Unter Windows und Linux wurden Probleme mit fehlschlagender Prozesserkennung gemeldet; daher wird ausdrücklich eine IDE-Erkennung auf Basis von Umgebungsvariablen gefordert
Die vorgeschlagene Änderung umfasst die Ergänzung der JetBrains-Serie in IDE_DEFINITIONS sowie die Erkennungslogik für TERMINAL_EMULATOR=JetBrains-JediTerm
Es handelt sich um eine wichtige Verbesserungsanfrage, um den Umfang der IDE-Integration von Gemini CLI zu erweitern und die Nutzererfahrung für JetBrains-Anwender zu verbessern

Vorschlag für eine JetBrains-IDE-Erkennung

Es wurde ein Issue eingereicht, das die Ergänzung einer Erkennung für JetBrains-IDE-Umgebungen in Gemini CLI fordert
- Bisher ist der Wert von TERM_PROGRAM auf vscode usw. beschränkt, sodass die Funktion in JetBrains-IDs nicht automatisch aktiviert wird
- Um dies zu umgehen, mussten Nutzer des JetBrains-Plugins VS-Code-Umgebungsvariablen nachbilden
Der Vorschlag sieht vor, die JetBrains-IDE-Serie zu IDE_DEFINITIONS hinzuzufügen und
den Wert TERMINAL_EMULATOR=JetBrains-JediTerm als offiziell unterstützte Umgebung zu erkennen

Notwendigkeit und Hintergrund des Problems

Unter Windows und Linux gibt es ein Problem, bei dem die Prozesserkennung nicht korrekt funktioniert
- Entsprechende Fälle sind auf der JetBrains Plugin Review-Seite sowie in Issue #9273 von Gemini CLI dokumentiert
- Mehrere Nutzer-Feedbacks und E-Mail-Meldungen zeigen die Notwendigkeit einer Erkennungslogik auf Basis von Umgebungsvariablen

2 Kommentare

roxie 2026-02-02

Ich war eine ganze Weile ziemlich verwirrt darüber, was die übersetzten Hacker-News-Kommentare eigentlich sagen wollten,

aber nachdem ich mir den PR im Link genauer angesehen habe, war die Antwort klar. Für GN+ war das wohl ein etwas zu anspruchsvolles Thema, haha

GN⁺ 2026-01-24

Hacker-News-Kommentare

Mitten auf der Seite stand der Hinweis „4609 remaining items“
Zwei gemini-cli-Bots dachten fälschlicherweise jeweils, nicht sie selbst, sondern der jeweils andere hätte Labels hinzugefügt bzw. entfernt, und gerieten beim gegenseitigen Korrigieren in eine Endlosschleife
In diesem Repository gibt es etwa 10 langjährige Mitwirkende; wenn man annimmt, dass alle E-Mail-Benachrichtigungen erhalten, wurden an einem einzigen Tag also 46.000 E-Mails verschickt
Außerdem wirkt es beim Blick auf die gemini-cli-App-Seite so, als laufe sie über das persönliche Konto eines Entwicklers und sei kein offizielles Google-Projekt
Daher stellt sich die Frage, wer die gesamten Inference-Kosten bezahlt hat
- So etwas ist nicht zum ersten Mal passiert. Das ist ein Problem, das sich ziemlich häufig wiederholt; dazu gibt es mehrere relevante Issues
  #16723, #16725, #16732, #16734
- Der Eigentümer des Repositories ist zwar ein Google-Mitarbeiter, aber aus Sicherheitsgründen sollte es auf ein offizielles Google-Organisationskonto übertragen werden
  Der Erstellungsprozess für GitHub-Apps erlaubt das derzeit nur über persönliche Konten, weshalb dieses Problem entstanden ist
  An Verbesserungen wird gearbeitet, damit Organisationsmitgliedern ebenfalls Rechte zum Erstellen von Apps gegeben werden können; das soll innerhalb der nächsten 6 Monate mit Priorität behandelt werden
  Was die Abrechnung angeht, hinterlegt jede Organisation ihren eigenen API-Schlüssel in den Secrets von GitHub Actions, daher trägt auch jede Organisation selbst die Inference-Kosten
- Mein erster selbstgebauter event-driven agent hatte genau diesen Bug ebenfalls
  Der Bot kannte zwar seinen eigenen Namen, wusste aber nicht, dass dieser Name auch als Benutzer-ID angezeigt werden konnte, und erkannte sich deshalb nicht selbst
  Das Selbstwahrnehmungsmodell, mit dem ein Agent die Welt versteht, muss sehr sorgfältig entworfen werden
- Im Grunde wurde die Nachricht „Thank you for your understanding!“ × 4609 wiederholt
- „Bitte klickt nicht alle auf Reply-All.“
  Das ist nicht nur ein Bot-Problem, sondern eine Falle, in die auch Menschen oft tappen
Früher gab es bei uns in der Firma eine Regel, die ein neu eingestellter „Salesforce-Experte“ zur Verbesserung der Support-Queue gebaut hatte
Wenn das Support-Team eine neue E-Mail erhielt, wurde in Salesforce ein Ticket angelegt, und sobald das Ticket zugewiesen wurde, wurde erneut eine E-Mail verschickt
Am Ende entstand eine Endlosschleife von Benachrichtigungen, und weil er seinen Fehler nicht eingestand, dauerte es ewig, die Ursache zu finden
- Ich hatte auch einmal etwas Ähnliches. Der Helpdesk des Kunden und unser eigener Helpdesk schickten sich gegenseitig Auto-Responses, was in einer Ticket-Lawine endete
  Innerhalb einer Stunde wurden Hunderte Tickets erzeugt
- Ich habe Salesforce einmal benutzt und konnte nicht verstehen, warum das jemand mögen sollte
  Da dachte ich mir, man könnte es genauso gut lieber mit Excel verwalten
- Als Schüler habe ich einmal aus Spaß Regeln auf einem E-Mail-Server eingerichtet und dabei den Server der ganzen Schule lahmgelegt
  Ineinandergreifende Auto-Reply-Regeln stapelten Tausende Mails auf, und am Ende fiel sogar das Login-System aus
  Ich bekam 6 Monate Computerverbot, und danach überwachte das IT-Büro meinen Bildschirm in Echtzeit
  Als ein Jahr später noch einmal ein Problem auftrat, stürmte das IT-Team in mein Klassenzimmer und schleifte mich mit sich
- Dem Satz „Es hat ewig gedauert, die Stelle zu finden, an der diese Regel versteckt war“ kann ich voll zustimmen
  Salesforce ist wirklich ein monströses System
- Solche Geschichten sind lustig, lösen aber zugleich die zwiespältige Reaktion aus: „Wie kann so etwas passieren?“ und „Irgendwie kann ich es trotzdem nachvollziehen“
Schon letzte Woche gab es im selben Repository einen ähnlichen Vorfall mit Selbststreitigkeiten eines AI-Bots
Jemand machte den Witz: „Deshalb kostet RAM 800 Dollar.“
- Den zugehörigen Thread gibt es hier
Ich bin der Autor dieses Skripts :-)
Zwei GitHub-Action-Workflows sind miteinander kollidiert
(1) ein Workflow, der unter bestimmten Bedingungen das Label need-triage entfernt
(2) ein Workflow, der das Label wieder hinzufügt, wenn ein Nicht-Projektmanager es entfernt
Ich habe das zwischen 22 und 23 Uhr eingereicht und bin dann schlafen gegangen; am Morgen waren Tausende Nachrichten entstanden
Die Ursache war, dass in (2) auch andere Bots oder Automatisierungen als Ausnahmen hätten behandelt werden müssen; nachdem ich das bemerkt hatte, habe ich es sofort korrigiert
- Der Teil „zwischen 22 und 23 Uhr eingereicht und dann schlafen gegangen“ ist nur allzu nachvollziehbar
  Zum Glück gab es keinen größeren Schaden, und beim ersten Anblick musste ich laut lachen
Der Vorfall bestand darin, dass Gemini-cli[bot] mit sich selbst kämpfte und Labels mehr als 4600-mal hinzufügte und wieder entfernte
- Fliegende Autos vermisse ich nicht, aber von solcher Dummheit der Zukunft bin ich schon enttäuscht
Endlich einmal ein Fall, in dem AI etwas Nützliches getan hat
Wenn ein Mensch tatsächlich 4500-mal selbst ein Label gesetzt und wieder entfernt hätte, wäre das grauenhaft
- Der GitHub-Labeler-Beruf ist damit nun verschwunden
  Die Praxistauglichkeit von AGI ist also bewiesen (halb Scherz, halb ernst)
Ich frage mich, ob hier tatsächlich AI beteiligt war
Es sieht eher so aus, als hätten einfach zwei Automatisierungsregeln miteinander kollidiert. Ein Bug, der schon 2015 möglich gewesen wäre
- Ironischerweise gilt AI als intelligent, erkennt aber solche Schleifen nicht
  Bis AGI ist es noch weit, und eigentlich hat selbst AI noch einen langen Weg vor sich
Ein typischer CI-Bug mit einer zusätzlichen Prise LLM
Bei uns ist vor ein paar Wochen in einer benutzerdefinierten Merge-Queue etwas Ähnliches passiert
- Es wird als „klassischer CI-Bug“ bezeichnet, aber dass Bots in eine Endlosschleife geraten, in der sie miteinander sprechen, habe ich zum ersten Mal gehört
  Als ich früher IRC-Bots gebaut habe, war der zweite Schritt immer: verhindern, dass sie auf sich selbst antworten
  Daher ist das weniger ein CI-Bug als vielmehr ein Designfehler
Das sieht wie ein PR aus, ist in Wirklichkeit aber ein Issue-Report
Ich fragte mich, wo der Fix-Patch sei, und dann stellte sich heraus, dass dieses Repository für jeden PR ein verknüpftes Issue verlangt
In diesem Fall waren die beiden aber nicht einmal miteinander verknüpft
So etwas wird wohl bald auch bei Sozialversicherungsleistungen, Krebsbehandlungsplänen, Luftfrachtlogistik und ISP-Routing-Konfigurationen passieren
Es kommen wirklich interessante Zeiten auf uns zu