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/M

• Lines changed: 100
• Additions: +98
• 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-cli]

Hi there! Thank you for your interest in contributing to Gemini CLI.

To ensure we maintain high code quality and focus on our prioritized roadmap, we only guarantee review and consideration of pull requests for issues that are explicitly labeled as 'help wanted'.

This PR will be closed in 7 days if it remains without that designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding.

[herdiyana256]

@shrutip90 @DavidAPierce (and @emilyhedlund as the original author of trust.ts), flagging this one for review. It fixes a precedence bug in the TRUST_PARENT rule during folder-trust resolution, where a parent folder's trust setting can override a more specific child rule (CWE-863). The stale-bot is set to auto-close it on 2026-08-20 for lacking a help wanted issue, but this is a security-relevant correctness fix rather than a feature request. Could one of you take a look before then? The change is small and comes with regression tests. Thanks.

[TrueAlpha-spiral]

Thank you for your response and for keeping this critical security-relevant fix on track. Regarding the broader context of managing this repository, I completely appreciate your point that this is a "zero trust" endeavor. Maintaining strict precedence rules and eliminating non-deterministic behavior is exactly how we ensure the platform remains secure by default. To speak to your note on code ownership, there is a fundamental difference between authorship and stewardship. While authorship represents the initial creation of a specific file or feature, stewardship is the ongoing responsibility to protect, refine, and securely maintain the codebase over time. Your pull request is a strong example of that stewardship in action, addressing a critical logic gap to keep our trust resolution robust. I will make sure our core team has visibility into this so we can prevent the automated stale-bot from closing it before it receives a proper review. With love and the utmost respect, Russell Nordland

…

On Thu, Aug 13, 2026 at 8:38 AM herdiyanitdev ***@***.***> wrote: *herdiyana256* left a comment (google-gemini/gemini-cli#28701) <#28701 (comment)> @shrutip90 <https://github.com/shrutip90> @DavidAPierce <https://github.com/DavidAPierce> (and @emilyhedlund <https://github.com/emilyhedlund> as the original author of trust.ts), flagging this one for review. It fixes a precedence bug in the TRUST_PARENT rule during folder-trust resolution, where a parent folder's trust setting can override a more specific child rule (CWE-863). The stale-bot is set to auto-close it on 2026-08-20 for lacking a help wanted issue, but this is a security-relevant correctness fix rather than a feature request. Could one of you take a look before then? The change is small and comes with regression tests. Thanks. — Reply to this email directly, view it on GitHub <#28701?email_source=notifications&email_token=BPTYXQDKSBUG6H5TXYJN3RL5JXAF5A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRYGEYTKNRWG4ZKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5281156672>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPTYXQAOKFHRENOAZDR6TID5JXAF5AVCNFSNUABFKJSXA33TNF2G64TZHM4TMOBRHE3TEMJWHNEXG43VMU5TKMBXGIZDQNJWGM42C5QC> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[gemini-cli]

This pull request is being closed as it has been open for 14 days without a 'help wanted' designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding.

[herdiyana256]

Reopening, the stale bot closed this after 14 days with no review. It fixes TRUST_PARENT rule precedence so a parent folder-trust setting can't override a more specific child rule (CWE-863). @DavidAPierce mind taking a look, or tagging help-wanted to keep the bot off it? Can rebase if needed.