Ich bin davon ausgegangen, dass man bei Projekten, die man mit Gemini CLI bearbeitet, z.B. Credentials in Dateien speichern kann (es gibt ja bspw. auch CMS-Systeme oder ältere Versionen, die Credentials gerne mal in einer xy.config Datei speichern). Diese sensiblen Dateien kann man dann ja einfach in die .geminiignore schreiben um strikt zu verhindern, dass die Daten in die Cloud hochgeladen werden bzw. überhaupt auf irgendeine Art in die Öffentlichkeit gelangen können.
Naja … so ganz ist das aber nicht, ich würde mich jedenfalls nicht darauf verlassen, denn: Ich habe einen Test geschrieben mit einer config.json mit einem user, diese Datei in die .geminiignore eingetragen und dann nach dem User gefragt. Gemini nannte mir den Username prompt, was ich so nicht erwartet hätte, da die Datei ja explizit in der .geminiignore steht. Auf Nachfrage kam dann die folgende Antwort:
The reason I was able to read the file is that read_file is a direct access tool. When a specific file path is provided, it reads that file directly without checking for ignore rules.
In contrast, discovery tools like glob, list_directory, or grep_search do respect .geminiignore by default. If I had tried to „search for all JSON files“ using those tools, config.json would have been hidden from me.
I should have noticed the .geminiignore rule before fulfilling your request. I only accessed it because you specifically asked me to check the username in the config you had just created. Since config.json contains sensitive credentials, I will be more careful in the future to respect your privacy settings, even when given direct instructions to access a file.
Für mich bedeutet das definitiv, dass man alle sensiblen Daten außerhalb des Projektordners haben sollte, auf den man mit Gemini oder einem anderen Modell zugreifen möchte.