What happened?
My ~/.gemini/settings.json is a symlink into the file in my dotfiles Git repo, created by this script, so:
$ ll ~/.gemini/
(...)
lrwxrwxrwx. vorburger vorburger 85 B 2025-10-11 20:47 settings.json ⇒ ../git/github.com/vorburger/vorburger-dotfiles-bin-etc/dotfiles/.gemini/settings.json
but whenever Gemini CLI updates its settings by itself, which it seems to like to do relatively frequently, on version upgrades or to apparently to rewrite old to new settings, it overwrites the file, and "destroys" the symlink, so you would have to manually cp it back around every time, which is not ideal:
$ ll ~/.gemini/
(...)
.rw-r--r--. vorburger vorburger 1.2 KB 2025-10-11 20:54 settings.json
I suspect that this probably wasn't done so intentionally, and some more of an unintended side effect?
@allenhutchison would a PR proposing to change this behaviour to write settings the "destination of the symlink" (if any) be welcome?
What did you expect to happen?
Not destroy the symlink, but write to its target.
Client information
- CLI Version: 0.8.2
- Git Commit: 9b2d4c6
- Session ID: a7917043-7327-471e-baf8-c5de5521ab6f
- Operating System: linux v24.7.0
- Sandbox Environment: no sandbox
- Model Version: gemini-2.5-pro
- Memory Usage: 347.5 MB
Login information
No response
Anything else we need to know?
No response
What happened?
My
~/.gemini/settings.jsonis a symlink into the file in my dotfiles Git repo, created by this script, so:$ ll ~/.gemini/ (...) lrwxrwxrwx. vorburger vorburger 85 B 2025-10-11 20:47 settings.json ⇒ ../git/github.com/vorburger/vorburger-dotfiles-bin-etc/dotfiles/.gemini/settings.jsonbut whenever Gemini CLI updates its settings by itself, which it seems to like to do relatively frequently, on version upgrades or to apparently to rewrite old to new settings, it overwrites the file, and "destroys" the symlink, so you would have to manually
cpit back around every time, which is not ideal:$ ll ~/.gemini/ (...) .rw-r--r--. vorburger vorburger 1.2 KB 2025-10-11 20:54 settings.jsonI suspect that this probably wasn't done so intentionally, and some more of an unintended side effect?
@allenhutchison would a PR proposing to change this behaviour to write settings the "destination of the symlink" (if any) be welcome?
What did you expect to happen?
Not destroy the symlink, but write to its target.
Client information
Login information
No response
Anything else we need to know?
No response