Repository navigation
fix(cli): propagate resolved folder trust state in headless mode (#29031) - #29528
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! 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 split-brain issue in headless mode where the Highlights
Using Gemini Code AssistThe 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
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 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
|
|
📊 PR Size: size/L
|
There was a problem hiding this comment.
Code Review
This pull request refactors the useFolderTrust hook to streamline how folder trust is handled in headless mode. Instead of forcing trust to true and hiding the dialog, the hook now correctly propagates the actual trust state (trusted) to onTrustChange and updates the dialog visibility conditionally based on whether headless mode is active. Corresponding unit tests have been updated and expanded to verify these behaviors under different trust scenarios (trusted, untrusted, and undefined). I have no feedback to provide as the changes are clean and well-tested.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request refactors the useFolderTrust hook to simplify headless mode handling by unifying state updates and correctly propagating the actual trust state (rather than forcing true) to onTrustChange. It also adds unit tests covering various trust scenarios in headless mode. The review feedback identifies a critical risk of an infinite loop and performance degradation because onTrustChange and addItem are included in the useEffect dependency array, and recommends capturing these callbacks in refs to avoid unnecessary re-runs.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request refactors the useFolderTrust hook to stabilize its callbacks (onTrustChange and addItem) using useRef, preventing unnecessary re-runs of the trust discovery effect when callback references change. It also updates and adds comprehensive unit tests to verify headless mode behavior and callback stability. The reviewer suggests further optimizing the hook by also storing the settings object in a useRef to safely omit settings.merged from the useEffect dependency array, preventing unnecessary executions when unrelated settings change.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request improves the stability of the useFolderTrust hook by refactoring it to use React refs (useRef) for callbacks (onTrustChange, addItem) and settings. This prevents unnecessary re-runs of the main discovery effect when these callback references or unrelated settings change. Additionally, the headless mode logic is simplified to propagate the correct trust status and show warnings when untrusted, rather than forcing trust. Comprehensive unit tests have been added to verify callback stability and the updated headless mode behavior. I have no further feedback to provide as the changes are well-implemented and thoroughly tested.
Head branch was pushed to by a user without write access
Summary
Fixes an issue where
useFolderTrustin headless mode unconditionally reportedonTrustChange(true)to the parent component (AppContainer) even when the workspace was untrusted (isTrusted === false). This created a split-brain state where the hook's internal state and history log warned of an untrusted folder whileAppContainerand its consumers were informed that the folder was trusted.Details
onTrustChange(true)was hardcoded intouseFolderTrust.ts. In PR feat(cli): secure .env loading and enforce workspace trust in headless mode #25814 (April 2026), workspace trust enforcement was introduced for headless mode, butuseFolderTrust.tswas not updated, leaving the staleonTrustChange(true)logic behind.useFolderTrustmounting logic so thatonTrustChange(trusted)receives the actual resolved trust value (true,false, orundefined).isFolderTrustDialogOpenin headless mode (!isHeadlessMode() && trusted === undefined) so interactive dialogs are not rendered without falsely asserting trust.eslint-disablerules added.packages/cli/src/ui/hooks/useFolderTrust.test.tswith comprehensive coverage for headless mode across all three trust states: untrusted (false), trusted (true), and undetermined (undefined).Related Issues
Fixes #29031
How to Validate
Run the relevant unit and integration test suites:
Manual Verification Matrix
isTrustedonTrustChangefalsefalse(hidden)falsefalsetruefalse(hidden)truetrueundefinedfalse(hidden)undefinedundefinedfalsefalse(hidden)falsefalsetruefalse(hidden)truetrueundefinedtrue(opens dialog)undefinedundefinedPre-Merge Checklist