anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[PR #8754] fix(tools): sandbox glob and grep to project directory #12857

New Issue
Open
opened 2026-02-16 18:17:44 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 18:17:44 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/anomalyco/opencode/pull/8754

State: open
Merged: No

Summary

Adds path containment checks to glob and grep tools to prevent searches outside the project directory.

Problem

When an AI agent provides a path parameter that resolves outside the project directory (e.g., ~, /Users/username, or ../), the glob and grep tools would happily traverse the entire filesystem. On macOS, this triggers permission dialogs for protected directories like:

  • ~/Library
  • ~/Music
  • ~/Photos
  • ~/Pictures

This is both a security concern and a poor UX (permission dialog spam).

Solution

Mirror the existing sandboxing pattern from bash.ts (line 88) which uses Filesystem.contains() to validate paths:

if (!Filesystem.contains(Instance.directory, searchPath)) {
  throw new Error(`Search path "..." is outside the project directory...`)
}

Changes

  • glob.ts: Add Filesystem import and containment check after path resolution
  • grep.ts: Add path import, Filesystem import, resolve relative paths, and add containment check

Testing

Verified the logic correctly:

  • ✅ Allows searches within project directory
  • ✅ Allows searches in subdirectories
  • ✅ Blocks $HOME directory
  • ✅ Blocks ../ escape attempts
  • ✅ Blocks absolute paths outside project
  • ✅ Blocks protected macOS directories

Related

This fixes the same class of issue that bash tool already handles, bringing glob/grep tools to parity.

**Original Pull Request:** https://github.com/anomalyco/opencode/pull/8754 **State:** open **Merged:** No --- ## Summary Adds path containment checks to glob and grep tools to prevent searches outside the project directory. ## Problem When an AI agent provides a path parameter that resolves outside the project directory (e.g., `~`, `/Users/username`, or `../`), the glob and grep tools would happily traverse the entire filesystem. On macOS, this triggers permission dialogs for protected directories like: - `~/Library` - `~/Music` - `~/Photos` - `~/Pictures` This is both a security concern and a poor UX (permission dialog spam). ## Solution Mirror the existing sandboxing pattern from `bash.ts` (line 88) which uses `Filesystem.contains()` to validate paths: ```typescript if (!Filesystem.contains(Instance.directory, searchPath)) { throw new Error(`Search path "..." is outside the project directory...`) } ``` ## Changes - **glob.ts**: Add `Filesystem` import and containment check after path resolution - **grep.ts**: Add `path` import, `Filesystem` import, resolve relative paths, and add containment check ## Testing Verified the logic correctly: - ✅ Allows searches within project directory - ✅ Allows searches in subdirectories - ✅ Blocks `$HOME` directory - ✅ Blocks `../` escape attempts - ✅ Blocks absolute paths outside project - ✅ Blocks protected macOS directories ## Related This fixes the same class of issue that bash tool already handles, bringing glob/grep tools to parity.
yindo added the pull-request label 2026-02-16 18:17:44 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#12857
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?