Disable workspace settings when starting GCLI in the home directory.

[kevinjwang1]

Summary

Modified loadSettings to unset the workspace path when the user is in the home directory. Also marked the workspace settings as readonly when in the home directory.

Details

When the user is in the home directory, there are no workspace settings to load in so a new empty settings object is created. Additionally, the workspace path defaults to the current directory, which is identical to the home directory. This can cause conflicts in settings updates, where updates (like disabling skills) are applied to the closest scope first i.e., the workspace scope over the user scope. But since the workspace settings path is identical to the user settings path, this can end up overriding the user settings file.

Related Issues

Fixes #18962

[gemini-code-assist]

Summary of Changes

Hello @kevinjwang1, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a potential conflict in settings management when the command-line interface (GCLI) is run from the user's home directory. By conditionally disabling and marking workspace settings as read-only in this specific scenario, it prevents unintended overrides of user-level configurations, ensuring that settings updates behave as expected without ambiguity between workspace and user scopes.

Highlights

• Workspace Settings Path: Modified the loadSettings function to unset the workspace path (by setting it to an empty string) when the current directory is the user's home directory. This prevents the workspace path from being identical to the home directory path.
• Readonly Workspace Settings: Marked the workspace settings as readOnly within the loadSettings function when the user is operating in their home directory. This ensures that no workspace-specific settings are applied or can override user settings in this scenario.

Changelog

• packages/cli/src/config/settings.ts
  • Modified the loadSettings function to dynamically set the path and readOnly properties for workspace settings based on whether the current workspace directory is the same as the home directory.

Activity

• No specific activity has been recorded for this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to disable workspace settings when the Google Gemini CLI (GCLI) is started in the user's home directory. This change prevents potential accidental or malicious overrides of user-level settings by treating the home directory as a workspace scope. While the PR correctly marks workspace settings as read-only and prevents saving, the current implementation is incomplete as it still loads user settings into the workspace scope, which could lead to a confusing state. A specific comment has been left with a suggestion for a more robust fix, referencing a rule about handling security-sensitive settings across different trust scopes.

[gemini-code-assist]

This change correctly makes the workspace settings read-only and prevents saving them when running in the home directory. However, the fix is incomplete because it doesn't prevent the settings from being loaded in the first place. The workspaceSettings object is likely populated from the user's settings file before this point, causing loadedSettings.workspace.settings to mirror user settings instead of being empty. This is misleading for the user and inconsistent with expectations for disabled scopes. The loading of workspace settings should also be skipped when in the home directory.

References

1. Security-sensitive settings should not use a merge strategy (e.g., MergeStrategy.REPLACE) that allows less-trusted configuration scopes (like a workspace) to completely override more-trusted scopes (like global user settings). This comment highlights a scenario where a less-trusted scope (workspace when in the home directory) could misleadingly reflect or influence more-trusted user settings, which aligns with the principle of preventing unintended interactions between different trust levels of configuration.