fix(core): fix TRUST_PARENT rule precedence in folder-trust resolution

[herdiyana256]

Summary

LoadedTrustedFolders.isPathTrusted() picks the winning trust rule for a given location by "longest match wins" -- intended to make the most specific configured rule take precedence (this is exactly what the existing should handle isPathTrusted with longest match test verifies). For a TRUST_PARENT rule, the boundary it actually applies to is dirname(rulePath) -- one directory level shallower than the rule's own configured path -- but the specificity comparison used rulePath.length (the rule's own, deeper path) instead of the effective boundary's length.

This overstates a TRUST_PARENT rule's specificity by the length of the child path segment it explicitly strips away via dirname(), letting it silently outrank a genuinely more specific sibling rule (e.g. an explicit DO_NOT_TRUST) that sits exactly at that parent boundary, whenever the TRUST_PARENT rule's own configured path string happens to be longer.

Verified with the real LoadedTrustedFolders class (not a reimplementation):

const config = {
  '/home/victim/repos/some-long-legit-project-name': 'TRUST_PARENT',
  '/home/victim/repos/evil': 'DO_NOT_TRUST',
};
loaded.isPathTrusted('/home/victim/repos/evil'); // => true (pre-fix) -- should be false

"Trust parent folder" is one of only three choices in the standard folder-trust dialog shown the first time any folder is opened (FolderTrustDialog.tsx), so ending up with a TRUST_PARENT rule recorded under a common parent directory is an ordinary, frequently-chosen outcome -- not a contrived configuration. Once such a rule exists anywhere under a shared parent, an unrelated sibling folder the user has explicitly marked DO_NOT_TRUST (or left unconfigured, if the rule's path length exceeds a sibling TRUST_FOLDER's -- less likely but structurally the same class of bug) can silently resolve as trusted, enabling project-sourced hooks and auto-connecting project-configured MCP servers against a folder the user never actually trusted.

Fix

Compare using the normalized effective path's length instead of the raw configured rulePath length, so specificity reflects the boundary a rule actually applies to rather than the length of an arbitrary child segment TRUST_PARENT strips away. No behavior change for TRUST_FOLDER/DO_NOT_TRUST rules, where effectivePath === rulePath already.

Test plan

• Added a regression test reproducing the exact scenario above (trust.test.ts), confirming the explicit DO_NOT_TRUST sibling now correctly wins, while unrelated siblings still correctly inherit the TRUST_PARENT grant.
• npx vitest run --root packages/core packages/core/src/utils/trust.test.ts -- 13/13 passing (was 12/12 pre-fix, +1 new)
• npm run typecheck --workspace=@google/gemini-cli-core
• npx eslint on both changed files -- clean

[github-actions]

📊 PR Size: size/S

• Lines changed: 42
• Additions: +40
• Deletions: -2
• Files changed: 2

[gemini-code-assist]

Summary of Changes

Hello, 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 bug in the folder-trust resolution mechanism where TRUST_PARENT rules were incorrectly prioritized due to an inaccurate specificity calculation. By using the normalized effective path length, the system now correctly identifies the intended boundary for trust rules, ensuring that more specific sibling rules are respected and preventing unintended trust grants.

Highlights

• Trust Rule Precedence Fix: Updated the folder-trust resolution logic to use the effective path length instead of the raw rule path length when determining rule precedence.
• Regression Testing: Added a new test case to verify that TRUST_PARENT rules no longer incorrectly override more specific sibling rules like DO_NOT_TRUST.

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 the 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 counterproductive. 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.

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 fixes a specificity issue in the trust utility by comparing effective path lengths instead of raw rule path lengths, and adds a corresponding regression test. The reviewer identified a critical security concern where rules resolving to the same effective path length could lead to non-deterministic trust resolution, and provided a code suggestion to enforce a secure-by-default tie-breaker prioritizing DO_NOT_TRUST.

[gemini-code-assist]

When two rules resolve to the exact same effective path boundary (for example, an explicit DO_NOT_TRUST on /home/user/project and a TRUST_PARENT on /home/user/project/.gemini), they will have the exact same normalizedEffectivePath.length.

Under the current implementation, the rule that is processed first in Object.entries(configToUse) will win because of the strict > comparison. Since object key ordering can be non-deterministic or depend on insertion order, this could lead to a security bypass where a folder explicitly marked as DO_NOT_TRUST is resolved as trusted.

To enforce a "secure by default" methodology and make the resolution deterministic, we should add a tie-breaker for equal lengths where DO_NOT_TRUST always takes precedence, and explicit TRUST_FOLDER takes precedence over inherited TRUST_PARENT.

        if (normalizedEffectivePath.length > longestMatchLen) {
          longestMatchLen = normalizedEffectivePath.length;
          longestMatchTrust = trustLevel;
        } else if (normalizedEffectivePath.length === longestMatchLen) {
          if (
            trustLevel === TrustLevel.DO_NOT_TRUST ||
            (trustLevel === TrustLevel.TRUST_FOLDER &&
              longestMatchTrust === TrustLevel.TRUST_PARENT)
          ) {
            longestMatchTrust = trustLevel;
          }
        }

References

1. Security checks should be implemented in a 'fail-closed' manner. If there is ambiguity or a tie in trust resolution, the system should default to the most secure option (e.g., rejecting trust).