Allow @-includes outside of workspaces (with permission)

[scidomino]

Summary

Allow @-includes outside of workspaces if the user grants permission.

Details

If a user @-includes a path outside the workspaces, we pop up a UI asking if they want to allow the read:

• If they do, we allow-list that path for the session (but don't persist it after restart) and process the text like normal
• If they don't, we process the text like normal, ignoring the files outside the workspace.

Related Issues

Fixes #17135

How to Validate

Attempt to @ include files and folders outside your workspace.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
    • Docker
    • Podman
    • Seatbelt
  • Windows
    • npm run
    • npx
    • Docker
  • Linux
    • npm run
    • npx
    • Docker

[gemini-code-assist]

Summary of Changes

Hello @scidomino, 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 introduces a crucial security and usability enhancement by enabling the inclusion of files from outside the configured workspace, but only after explicit user permission. This change provides greater flexibility for users while maintaining control over file access. It also involves a substantial refactoring of the @-command processing pipeline, making it more robust and extensible, and updates core file system access validation to differentiate between read and write permissions.

Highlights

• External Path Inclusion with User Consent: Introduced a new mechanism that allows users to @-include files located outside their defined workspaces. When such a path is detected, a UI prompt will appear, asking the user for explicit permission to read the file. If granted, the path is temporarily added to a session-specific read-only allow-list.
• Refactored @-Command Processing Logic: The internal handling of @-commands has been significantly refactored for improved modularity and clarity. This includes new functions for categorizing commands (agents, resources, files), resolving file paths (including globs and ignores), checking permissions, and reconstructing the query for the Language Model.
• Granular Path Access Validation: The validatePathAccess method in the Config class now supports a checkType parameter ('read' or 'write'), allowing for more granular control over file system operations. Read operations now first check against a new readOnlyPaths list in the WorkspaceContext.
• Enhanced Workspace Context: The WorkspaceContext now includes a readOnlyPaths set and associated methods (addReadOnlyPath, isPathReadable) to manage paths that are explicitly allowed for reading, even if they are not part of the primary workspace directories.

Changelog

• packages/cli/src/test-utils/mockConfig.ts
  • Added validatePathAccess to the mock configuration for testing purposes.
• packages/cli/src/ui/AppContainer.tsx
  • Imported PermissionConfirmationRequest type and checkPermissions utility.
  • Added a new state variable permissionConfirmationRequest to manage UI prompts for external file access.
  • Modified handleFinalSubmit to asynchronously check for required permissions using checkPermissions before submitting a query.
  • Implemented logic to display a permission confirmation prompt if external files are detected and, if allowed, add them to the readOnlyPaths.
  • Updated useCallback dependencies to include config.
  • Changed handleFinalSubmit call to void handleFinalSubmit to handle its new asynchronous nature.
  • Added permissionConfirmationRequest to the conditions that block input and to the uiState dependencies.
• packages/cli/src/ui/components/DialogManager.tsx
  • Added a new ConsentPrompt component to display and handle permissionConfirmationRequest, presenting a list of external files and asking for user consent.
• packages/cli/src/ui/contexts/UIStateContext.tsx
  • Imported PermissionConfirmationRequest type.
  • Added permissionConfirmationRequest property to the UIState interface.
• packages/cli/src/ui/hooks/atCommandProcessor.test.ts
  • Removed assertions related to debug messages for 'Lone @ detected' and updated the debug message for paths not in the workspace.
• packages/cli/src/ui/hooks/atCommandProcessor.ts
  • Removed unused import DiscoveredMCPResource.
  • Introduced categorizeAtCommands function to separate @ commands into agent, resource, and file types.
  • Added checkPermissions function to identify file paths that require explicit read permission from the user.
  • Refactored handleAtCommand by extracting logic into new helper functions: resolveFilePaths (for globbing, recursion, and ignore handling), constructInitialQuery (for rebuilding the query string), readMcpResources (for MCP resource content), readLocalFiles (for local file content), and reportIgnoredFiles (for logging ignored files).
  • Updated the logic for adding REF_CONTENT_HEADER and REF_CONTENT_FOOTER based on whether content was read from MCP resources or local files.
  • Modified convertResourceContentsToParts to use flatMap for a more concise transformation of resource contents.
• packages/cli/src/ui/types.ts
  • Defined the PermissionConfirmationRequest interface to structure data for permission prompts.
• packages/core/src/config/config.ts
  • Modified validatePathAccess to accept an optional checkType parameter ('read' or 'write'), defaulting to 'write'.
  • Implemented logic within validatePathAccess to first check isPathReadable from WorkspaceContext for 'read' operations.
• packages/core/src/tools/glob.ts
  • Updated calls to validatePathAccess within GlobToolInvocation and GlobTool to explicitly pass 'read' as the checkType.
• packages/core/src/tools/grep.ts
  • Updated calls to validatePathAccess within GrepToolInvocation and GrepTool to explicitly pass 'read' as the checkType.
• packages/core/src/tools/ls.ts
  • Updated calls to validatePathAccess within LSToolInvocation and LSTool to explicitly pass 'read' as the checkType.
• packages/core/src/tools/read-file.ts
  • Updated calls to validatePathAccess within ReadFileToolInvocation and ReadFileTool to explicitly pass 'read' as the checkType.
• packages/core/src/tools/read-many-files.ts
  • Updated calls to validatePathAccess within ReadManyFilesToolInvocation to explicitly pass 'read' as the checkType.
• packages/core/src/tools/ripGrep.ts
  • Updated calls to validatePathAccess within GrepToolInvocation and RipGrepTool to explicitly pass 'read' as the checkType.
• packages/core/src/utils/workspaceContext.ts
  • Added a private readOnlyPaths Set to store paths explicitly allowed for reading.
  • Implemented addReadOnlyPath method to add a given path to the readOnlyPaths set, resolving symlinks.
  • Added isPathReadable method to check if a given path is within the workspace or has been added to the readOnlyPaths set.

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. ↩

[github-actions]

Size Change: +3.87 kB (+0.02%)

Total Size: 23.9 MB

Filename	Size	Change
./bundle/gemini.js	23.9 MB	+3.87 kB (+0.02%)

ℹ️ View Unchanged

Filename	Size
./bundle/sandbox-macos-permissive-closed.sb	1.03 kB
./bundle/sandbox-macos-permissive-open.sb	890 B
./bundle/sandbox-macos-permissive-proxied.sb	1.31 kB
./bundle/sandbox-macos-restrictive-closed.sb	3.29 kB
./bundle/sandbox-macos-restrictive-open.sb	3.36 kB
./bundle/sandbox-macos-restrictive-proxied.sb	3.56 kB

_{compressed-size-action}

[gemini-code-assist]

Code Review

This pull request introduces a new feature allowing file inclusion via @ commands with user permission. A critical security vulnerability was identified regarding misleading UI behavior with symlinks, which could grant unauthorized access to sensitive files. Resolving symlinks before prompting for user permission is crucial. Additionally, a high-severity issue related to cancellation due to an unpassed AbortSignal needs to be addressed.

[jacob314]

🛑 Critical Issues

• Security Vulnerability (Misleading UI): The checkPermissions function in atCommandProcessor.ts does not resolve symlinks before displaying paths in the permission dialog. A user might approve a seemingly harmless path that actually points to a sensitive file (e.g., ~/.ssh/id_rsa). Symlinks must be resolved via fs.realpath before the user is prompted to ensure transparency.
• Complete Lack of Tests: No new tests were added for the core permission checking logic (checkPermissions) or the UI integration in AppContainer and DialogManager. New features must include unit tests and, ideally, integration tests using renderWithProviders and waitFor from the project's test utilities.
• Unaddressed Review Feedback: A previous review mentioned a high-severity issue regarding a missing AbortSignal. The checkPermissions function is asynchronous but does not accept an AbortSignal, which could lead to race conditions if the user cancels or submits a new prompt before the check completes.

🛠 Technical & Style Issues

• Conventional Commits Violation: The PR title "Allow @-includes outside of workspaces (with permission)" does not follow the project's Conventional Commits standard (e.g., it should be feat(core): ... or feat(cli): ...).
• Synchronous I/O in UI Path: WorkspaceContext.addReadOnlyPath uses fs.existsSync and fs.realpathSync. Since this is called from the React handleFinalSubmit workflow, it can cause the CLI UI to hang on slow file systems.
• Inconsistent React Patterns:
  • In AppContainer.tsx, handleFinalSubmit is now async. When called inside useEffect, it uses the void operator, which can lead to unhandled rejections if the component unmounts while the permissions check is still in flight.
  • In handleFinalSubmit, addInput(submittedValue) is called inconsistently (once before the early return for permissions and again at the end of the function).

---

This review was authored by Review Frontend and reviewed by Jacob.

[scidomino]

The abort signal issue is addressed in: #18477

Also added some tests.

[jacob314]