Gemini CLI v0.50.0 fails to load .gemini/settings.json in VS Code Dev Container

[chrisburnham]

What happened?

The Gemini CLI does not load the workspace-level .gemini/settings.json configuration file when running inside a VS Code Dev Container.
This prevents any workspace-specific settings from being applied.

Steps to Reproduce:

1. In a dev container, confirm the workspace root with echo $GEMINI_CLI_IDE_WORKSPACE_PATH.
2. Create a file at <workspace_root>/.gemini/settings.json.
3. Add the following content to the file:

1 {
2 "security.disableYoloMode": false
3 }
4. Ensure the file and directory have correct read permissions (drwxr-xr-x for the folder, -rw-r--r-- for the file).
5. Run gemini in the terminal.

Actual Behavior:
The CLI starts in normal mode and ignores the settings.json file completely, continuing to prompt for all actions. The settings file is not loaded.

What did you expect to happen?

The CLI should start in YOLO mode, as dictated by the settings file.

Client information

Client Information

Run gemini to enter the interactive CLI, then run the /about command.

> /about
│ About Gemini CLI                                                                                                                                                                                             │
│                                                                                                                                                                                                              │
│ CLI Version                                                            0.50.0                                                                                                                                │
│ Git Commit                                                             8d9733d53                                                                                                                             │
│ Model                                                                  Auto (Gemini 2.5)                                                                                                                     │
│ Sandbox                                                                no sandbox                                                                                                                            │
│ OS                                                                     linux                                                                                                                                 │
│ Auth Method                                                            Signed in with Google (<omitted fro privacy>)                                                                                         │
│ Tier                                                                   Gemini Code Assist Enterprise                                                                                                         │
│ GCP Project                                                            <omitted for privacy>                                                                                                                 │
│ IDE Client                                                             VS Code   

Login information

Logged in via google account

Anything else we need to know?

• Gemini CLI Version: 0.50.0
• Gemini CLI Companion Extension Version: 0.20.0
• Host Environment: VS Code with Dev Containers extension

[gemini-cli]

Effort Analysis:
The root cause is located in the interaction between packages/cli/src/gemini.tsx and packages/cli/src/config/settings.ts. Specifically, the main() function calls loadSettings() without arguments, which causes it to default to process.cwd() as the workspace directory. The Storage class in packages/core/src/config/storage.ts, which is instantiated by the settings loader, constructs the settings path by strictly appending .gemini/settings.json to the provided directory. Since the CLI currently lacks an upward directory traversal mechanism for configuration discovery, it fails to find the settings file if the user is in a subfolder.

The fix involves parsing the GEMINI_CLI_IDE_WORKSPACE_PATH environment variable (handling platform-specific delimiters via path.delimiter), identifying the specific workspace root that contains the current cwd (using the isSubpath utility from @google/gemini-cli-core), and ensuring the CLI's bootstrap logic passes this resolved root to loadSettings. This is classified as effort/medium because it requires cross-package coordination between the CLI and Core packages, involves environment-specific variable handling, and falls under the triage guidelines for platform-specific/IDE-integration issues that require more complex reproduction and verification.

[chrisburnham]

To confirm your findings, I performed a series of diagnostic tests and can provide the following results:

1. Test for Settings File Loading: I placed a settings.json file with {"security.disableYoloMode": false} in the workspace root
   ($GEMINI_CLI_IDE_WORKSPACE_PATH).
2. Execution: I then ran the gemini command from that same root directory.
3. Result: The CLI failed to load the settings file and did not enter YOLO mode.

This confirms your analysis that loadSettings() was not correctly identifying the workspace root, even when the CLI was invoked from
there. Your explanation that it defaults to process.cwd() and lacks an upward traversal mechanism perfectly explains the behavior we were
seeing.

In the meantime, in case it helps someone else, I have found that using the --no-ide flag to disable the VS Code integration serves
allows for allowing certain actions to be repeated, but others to require approval, but it does sort of defeat the purpose of running in the VS code extension.

[aniketghavte]

/assign

[gemini-cli]

👋 @aniketghavte, thanks for your interest in this issue! We're reserving self-assignment for issues that have been marked with the help wanted label. Feel free to check out our list of issues that need attention.