[Windows] Hardcoded GIT_CONFIG_GLOBAL=NUL causes Git for Windows to fail with fatal: unable to access 'NUL': Invalid argument

ysageev

### What happened? [ACTION REQUIRED] 📎 PLEASE ATTACH THE EXPORTED CHAT HISTORY JSON FILE TO THIS ISSUE IF YOU FEEL COMFORTABLE SHARING IT. ### What did you expect to happen? Since am not allowed to paste or even type in the "What happened?" box, I am putting the meat of this report here. Yes, "Write" was selected. ---- Summary Running any standard git command (such as git status, git log, or git diff) on Windows via the shell execution tool fails immediately with: fatal: unable to access 'NUL': Invalid argument. What Happened In @google/gemini-cli (v0.62.0), the shell execution environment sanitizer sets GIT_CONFIG_GLOBAL to "NUL" on Windows (using os.platform() === "win32" ? "NUL" : "/dev/null"). On Windows, Git for Windows uses an MSYS2/POSIX compatibility layer. When Git evaluates the configuration file path provided in GIT_CONFIG_GLOBAL, it executes an access() check. In the Windows POSIX runtime, calling access on "NUL" returns EINVAL (Invalid argument) because NUL is a DOS character device rather than a valid file path. Consequently, Git aborts immediately with a fatal error before executing the command. Expected Behavior Git commands should execute successfully without failing to access NUL. Git for Windows' POSIX emulation layer already translates "/dev/null" to an empty device. Changing the path to remain "/dev/null" (or an empty string "" on Windows) allows Git for Windows to read an empty configuration and execute cleanly. Proposed Fix In @google/gemini-cli bundle files (chunk-MLY4WQFO.js and chunk-2DHAEQE2.js), change devNullPath from "NUL" to "/dev/null" (or empty string "") on win32. ### Client information * **CLI Version:** 0.62.0 * **Git Commit:** b460678f3 * **Session ID:** 816fcc9e-2755-4d28-8a49-c0a98586844a * **Operating System:** win32 v24.18.0 * **Sandbox Environment:** no sandbox * **Model Version:** gemini-flash-latest * **Auth Type:** gemini-api-key * **Memory Usage:** 669.2 MB * **Terminal Name:** Unknown * **Terminal Background:** #282c34 * **Kitty Keyboard Protocol:** Unsupported ### Login information Gemini API Key ### Anything else we need to know? Code references in `@google/gemini-cli` bundle: - `chunk-MLY4WQFO.js` (lines 313287 and 323565) - `chunk-2DHAEQE2.js` (lines 314963 and 325574) // Current: const devNullPath = os.platform() === "win32" ? "NUL" : "/dev/null"; // Fix: const devNullPath = os.platform() === "win32" ? "" : "/dev/null"; // (or leave as "/dev/null" across all platforms)

gemini-cli[bot]

**Effort Analysis:** The codebase contains environment variable sanitization logic in both `packages/core/src/utils/gitUtils.ts` and `packages/core/src/services/shellExecutionService.ts`. In these files, `GIT_CONFIG_GLOBAL` is set using `os.platform() === 'win32' ? 'NUL' : '/dev/null'`. On Windows, when the shell execution tool invokes a standard Git command, Git's MSYS2 POSIX compatibility layer attempts to execute an `access()` check on the `NUL` path. This fails immediately with an `EINVAL` error because `NUL` is a DOS character device, rather than a recognized POSIX device path. Although the fix itself is a simple string replacement (modifying the Windows fallback to use `'/dev/null'` or `''`), the issue is strictly platform-specific and requires a Windows environment to accurately test and reproduce. Per the guidelines, any bug that is platform-specific MUST NOT be rated as `effort/small` due to testing overhead. Furthermore, because it specifically involves OS-level shell behavior differences between Windows and Linux/POSIX, it meets the exact criteria for `effort/large`.

ocean-sicard-baux

It's a git 2.56 regression, and will be fixed in the next version. When available, update to git 2.56.0.2. In the meantime, revert to git 2.55.5 see https://github.com/git-for-windows/git/issues/6449

swapnil1222589

I checked the latest Git for Windows release notes, and this issue appears to be fixed in version 2.56.0.2. Could someone confirm whether updating Git resolves the problem with Gemini CLI? If it does, we may not need a code change in this repository.

ocean-sicard-baux

Yes, I updated to 2.56.0.2 and I can confirm updating Git resolves the problem with Gemini CLI

swapnil1222589

Confirmed, updating to Git for Windows 2.56.0.2 resolves the issue. Thanks for verifying!

ysageev

Confirmed. Thank you.