What happened?
When a user selects the "Allow for all future sessions" option in a tool confirmation dialog, the corresponding policy entry is added twice to the auto-saved.toml file. This indicates that the policy saving logic is being triggered twice for a single user action.
Steps to reproduce
- Start Gemini CLI.
- Trigger a tool confirmation (e.g., by running a command like
ls if shell confirmation is enabled, or asking for an edit).
- Choose the option "Allow for all future sessions".
- Open the
auto-saved.toml policy file (typically in ~/.gemini/policies/auto-saved.toml).
- Observe that there are two identical entries for the tool or command prefix.
What did you expect to happen?
Only a single entry should be added to the auto-saved.toml file for each unique tool approval.
Additional context
Initial investigation suggests this is due to redundant UPDATE_POLICY triggers originating from both the individual tool's onConfirm callback and the centralized Scheduler loop.
What happened?
When a user selects the "Allow for all future sessions" option in a tool confirmation dialog, the corresponding policy entry is added twice to the
auto-saved.tomlfile. This indicates that the policy saving logic is being triggered twice for a single user action.Steps to reproduce
lsif shell confirmation is enabled, or asking for an edit).auto-saved.tomlpolicy file (typically in~/.gemini/policies/auto-saved.toml).What did you expect to happen?
Only a single entry should be added to the
auto-saved.tomlfile for each unique tool approval.Additional context
Initial investigation suggests this is due to redundant
UPDATE_POLICYtriggers originating from both the individual tool'sonConfirmcallback and the centralizedSchedulerloop.