gemini-cli - 💡(How to fix) Fix `ide.enabled: false` in settings.json does not prevent IDE client from corrupting trustedFolders.json [1 participants]

What happened?

I tried to set up Gemini CLI in the terminal of VS Code with a Podman sandbox, but after setting up the Podman sandbox, I can't get Gemini to trust my project folder. I got the error message Error in /home/[user]/.gemini/trustedFolders.json: EACCES: permission denied, open '/home/[user]/.gemini/trustedFolders.json' Please fix the configuration file and try again. So I tried deleting trustedFolders.json, I tried setting "ide": { "enabled": false } in ~/.gemini/settings.json, but every single time I try to launch Gemini, I get prompted to trust the folder and the error happens all over again. I also got this error message after changing the IDE setting: [DEBUG] [IDEClient] IDE integration disabled. To enable it again, run /ide enable

What did you expect to happen?

With ide.enabled: false in settings.json, the IDE client should not run at all, and trustedFolders.json should be written correctly and persist between sessions without errors.

Client information

I can't run /about due to this bug, but my Gemini CLI version is v0.40.0, my operating system is Bazzite DX, and my Node.js version is v20.20.2

Login information

I'm using the free Gemini Code Assist for individuals plan by logging in with a Google account.

Anything else we need to know?

Claude Sonnet was helping me with my set up and helped me identify this bug. It wrote the following:

This issue began occurring immediately after configuring Podman sandbox support by setting GEMINI_SANDBOX=podman and SANDBOX_SET_UID_GID=true in ~/.gemini/.env. The issue did not occur before sandbox setup. It's possible the sandbox launch sequence creates a race condition or timing issue between the IDEClient and the trustedFolders.json write that doesn't occur in a non-sandboxed launch.

This is related to but distinct from issue #25032. That issue describes a trust mismatch when the IDE companion extension is active. This issue reproduces even with IDE integration explicitly disabled via settings.json. The [IDEClient] debug message suggests the IDE client code path is still executing despite the setting, and its interaction with the trust flow is what corrupts the file.

Also, here's the contents of my ~/.gemini/.env file:

GEMINI_SANDBOX=podman SANDBOX_SET_UID_GID=true export SANDBOX_FLAGS="--security-opt label=disable" GEMINI_TRUST_WORKSPACE=true