If Gemini CLI runs git for you, this post explains which of your git settings that git still reads in version 0.66.0 and which ones the CLI overrides. It also explains why a fetch or push run by the agent can fail at once where the same command in your terminal asks for a password. Nothing was run for this post: it is based on the source code at v0.57.0 and v0.66.0, release notes, pull requests and issues, the README and shell tool docs, and the git and OpenSSH manuals, all read on 29 October 2026, with times in UTC.
Version 0.66 reads your global git config again
Gemini CLI is Google’s open-source AI agent for the terminal, according to its README. Version 0.66.0 is a stable release, published on 27 October 2026 at 20:26 UTC. Its notes list pull request #29832, titled “preserve user-level ~/.gitconfig in shell and git environments”. The 0.66.0-preview.0 prerelease of 20 October listed the same change.
How an August change broke commits
The problem that 0.66 fixes started with pull request #28792, merged on 13 August 2026. It added a helper called getSafeGitEnv() to build “a clean, non-interactive Git subprocess environment”, and its description says it was applied in ShellExecutionService, WorktreeService, GrepTool and GitService. Its notes appear in the v0.57.0-preview.0 prerelease of 19 August and the stable v0.57.0 of 25 August. In the v0.57.0 code, GIT_CONFIG_GLOBAL, the variable that names git’s user-level config file, pointed at the null device.
Git’s manual says that when GIT_CONFIG_GLOBAL is set, neither $HOME/.gitconfig nor $XDG_CONFIG_HOME/git/config is read. On 1 September a user opened issue #29152, “User-level git config is ignored after pull request #28792”, reporting a commit that failed with “Author identity unknown”.
Pull request #29832 confirms the cause. It says both the shell tool and getSafeGitEnv() “unconditionally set GIT_CONFIG_GLOBAL to /dev/null (NUL on Windows)”. Commits failed whenever the identity was set globally rather than in the repository’s .git/config. The pull request was merged on 20 October and closed issue #29152 the same day.
The same August change also emptied diff.external, the setting that names an external diff program. Pull request #29467 removed that override because the empty value made git diff fail with “cannot spawn”. It was merged on 25 September and shipped in stable v0.63.0 on 6 October.
Seven of your settings are still replaced
Even with your global config back, git run by the agent ignores the machine-wide config and replaces seven settings. In gitUtils.ts at v0.66.0 and in the shell tool’s code, both paths set GIT_CONFIG_NOSYSTEM to 1. Git’s manual says that variable skips the system-wide $(prefix)/etc/gitconfig file.
The seven settings are passed through GIT_CONFIG_COUNT and numbered GIT_CONFIG_KEY_n and GIT_CONFIG_VALUE_n variables. git-config’s manual says these override values in config files but lose to an explicit git -c option. Pull request #29832 kept all seven and says they apply “at the highest precedence”.
| Setting | Value in 0.66.0 | What the git docs read say about this value |
|---|---|---|
credential.helper | empty | resets the helper list to empty |
core.fsmonitor | empty | effect of empty value not stated |
core.hooksPath | empty | effect of empty value not stated |
core.sshCommand | empty | effect of empty value not stated |
core.pager | cat | effect of cat value not stated |
core.editor | empty | effect of empty value not stated |
sequence.editor | empty | effect of empty value not stated |
The credential.helper row comes from gitcredentials. The shell tool also sets GIT_PAGER to cat unless you set its pager, and git’s manual says that value stops git from launching a pager.
Prompts are switched off so background git fails instead of waiting
The second 0.66 fix stops git from freezing the CLI while it waits at a password prompt. Issue #23480, opened on 22 March 2026, reported that a background fetch for private extensions froze the terminal because “the hidden git process hangs waiting for a username/password or SSH passphrase.”
Pull request #29760, merged on 15 October, fixed it in getSafeGitEnv(). The helper now sets GIT_TERMINAL_PROMPT=0, empties GIT_ASKPASS and SSH_ASKPASS, sets GH_PROMPT_DISABLED=1 and GCM_INTERACTIVE=never, and supplies its own GIT_SSH_COMMAND. It builds that from GIT_SSH_COMMAND, else GIT_SSH, else plain ssh, and adds -o BatchMode=yes if missing, or -batch for PuTTY’s plink and TortoisePlink.
Git’s manual says GIT_TERMINAL_PROMPT set to false stops git prompting on the terminal. GIT_ASKPASS names a program git calls for passwords, and GIT_SSH_COMMAND replaces ssh for fetch and push. The pull request author explains why one variable was not enough: git still runs an askpass helper if one is set, and OpenSSH opens /dev/tty for passphrases unless BatchMode=yes is on. OpenSSH’s ssh_config page says that setting disables password prompts and host key confirmation. The pull request says an unauthenticated background fetch “now fails fast and silently”.
The shell tool skips the SSH batch mode
Pull request #28792 described the helper as applied to the shell tool, but the code at v0.66.0 differs. At v0.66.0, the shell tool, run_shell_command, does not call getSafeGitEnv(), and shellExecutionService.ts builds its own environment, while extension cloning and update checks do use the helper.
| Behaviour | Shell tool | getSafeGitEnv() |
|---|---|---|
| System config | skipped | skipped |
| Seven overrides | applied | applied |
Your GIT_CONFIG_* variables | kept | removed, except a set GIT_CONFIG_GLOBAL |
| Terminal and askpass prompts | off | off |
ssh BatchMode=yes | not set | set |
The shell tool also empties DISPLAY and DBUS_SESSION_BUS_ADDRESS, and deletes an empty GIT_CONFIG_GLOBAL so git falls back to ~/.gitconfig. Pull request #29832 names one exception: GitService points GIT_CONFIG_GLOBAL at its own .gitconfig for the checkpointing shadow repository.
The shell tool’s docs page does not mention these overrides
A reader of the shell tool docs at v0.66.0 learns of one variable the tool sets, GEMINI_CLI=1, and a pager setting, tools.shell.pager, that defaults to cat. The page says interactive operations such as git rebase -i are supported, while the code empties core.editor and sequence.editor. The page does not mention the git overrides.
What this does not show
Nothing was run, so no behaviour here was observed. Whether an agent-run git push over HTTPS can authenticate at all in 0.66 is not documented in the sources read. Whether an ssh passphrase or host-key prompt can still appear from the shell tool, which lacks BatchMode=yes, is not documented either. The git docs read do not say what an empty core.hooksPath, core.sshCommand, core.fsmonitor or editor value does.
Pull request #28792 gives one reason for the original change: “predictable, non-interactive execution of internal Git utilities”. Its use in WorktreeService, GrepTool and GitService was not checked at v0.66.0. A v0.67.0-preview.0 prerelease was already published on 27 October, so this may change. No setting to turn the overrides off was found, though git-config’s manual says an explicit git -c option still wins over them.