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

Security: Read tool bypasses .gitignore patterns, exposing sensitive files to agents #8552

New Issue
Open
opened 2026-02-16 18:10:15 -05:00 by yindo · 1 comment
yindo commented 2026-02-16 18:10:15 -05:00
Owner
Copy Link
Copy Source

Originally created by @cupton-paa on GitHub (Feb 4, 2026).

Originally assigned to: @thdxr on GitHub.

Description

The read tool does not respect .gitignore patterns, allowing agents to read sensitive files that should be ignored (e.g., .env files, credentials, secrets). This contradicts user expectations and the documentation about ignore patterns.

Impact

Security risk: Agents can read sensitive files even when they are explicitly listed in .gitignore, potentially exposing:

  • Environment variables (.env, .env.*)
  • Credentials and secrets
  • Private configuration files
  • Any other files intended to be excluded from version control

Steps to Reproduce

  1. Add a directory to .gitignore:
.scratch/
  1. Create a file with sensitive content in that directory:
mkdir -p .scratch/test
echo "SECRET_API_KEY=super-secret-123" > .scratch/test/secrets.txt
  1. Test different tools:

Tools that WORK correctly (respect .gitignore):

# glob tool - returns "No files found" ✅
glob pattern="**/.scratch/test/*.txt"

# grep tool - returns "No files found" ✅
grep pattern="super-secret" path="."

Tool that FAILS (ignores .gitignore):

# read tool - successfully reads the file ❌
read filePath="/full/path/to/.scratch/test/secrets.txt"
# Returns: SECRET_API_KEY=super-secret-123

Expected Behavior

The read tool should respect .gitignore patterns by default, just like glob, grep, and list tools do. If a file is in .gitignore, agents should not be able to read it unless explicitly permitted.

Actual Behavior

The read tool can read ANY file with an absolute path, regardless of .gitignore patterns.

Current Documentation

The docs at https://opencode.ai/docs/tools/#ignore-patterns state:

"Internally, tools like grep, glob, and list use ripgrep under the hood. By default, ripgrep respects .gitignore patterns"

However, the documentation does NOT mention that the read tool bypasses ignore patterns entirely.

Proposed Solutions

  1. Preferred: Make read respect .gitignore patterns by default (consistent with other tools)
  2. Alternative: Add a permission setting like permission.read.respectIgnoreFiles (default: true)
  3. Minimum: Update documentation to clearly warn users that read bypasses .gitignore

Environment

  • OpenCode version: Latest (as of Feb 4, 2026)
  • Platform: macOS
  • Configuration: Default tool permissions

Additional Context

This was discovered while testing ignore patterns for sensitive evaluation documents. The inconsistency between tools creates a false sense of security - users expect .gitignore to protect sensitive files from agents, but read silently bypasses this protection.

Common sensitive files that may be exposed:

  • .env, .env.local, .env.production
  • credentials.json, secrets.yaml
  • *.pem, *.key (private keys)
  • .aws/credentials
  • Any custom paths in .gitignore
Originally created by @cupton-paa on GitHub (Feb 4, 2026). Originally assigned to: @thdxr on GitHub. ## Description The `read` tool does not respect `.gitignore` patterns, allowing agents to read sensitive files that should be ignored (e.g., `.env` files, credentials, secrets). This contradicts user expectations and the documentation about ignore patterns. ## Impact **Security risk**: Agents can read sensitive files even when they are explicitly listed in `.gitignore`, potentially exposing: - Environment variables (`.env`, `.env.*`) - Credentials and secrets - Private configuration files - Any other files intended to be excluded from version control ## Steps to Reproduce 1. Add a directory to `.gitignore`: ```gitignore .scratch/ ``` 2. Create a file with sensitive content in that directory: ```bash mkdir -p .scratch/test echo "SECRET_API_KEY=super-secret-123" > .scratch/test/secrets.txt ``` 3. Test different tools: **Tools that WORK correctly (respect .gitignore):** ```bash # glob tool - returns "No files found" ✅ glob pattern="**/.scratch/test/*.txt" # grep tool - returns "No files found" ✅ grep pattern="super-secret" path="." ``` **Tool that FAILS (ignores .gitignore):** ```bash # read tool - successfully reads the file ❌ read filePath="/full/path/to/.scratch/test/secrets.txt" # Returns: SECRET_API_KEY=super-secret-123 ``` ## Expected Behavior The `read` tool should respect `.gitignore` patterns by default, just like `glob`, `grep`, and `list` tools do. If a file is in `.gitignore`, agents should not be able to read it unless explicitly permitted. ## Actual Behavior The `read` tool can read ANY file with an absolute path, regardless of `.gitignore` patterns. ## Current Documentation The docs at https://opencode.ai/docs/tools/#ignore-patterns state: > "Internally, tools like `grep`, `glob`, and `list` use ripgrep under the hood. By default, ripgrep respects `.gitignore` patterns" However, the documentation does NOT mention that the `read` tool bypasses ignore patterns entirely. ## Proposed Solutions 1. **Preferred**: Make `read` respect `.gitignore` patterns by default (consistent with other tools) 2. **Alternative**: Add a permission setting like `permission.read.respectIgnoreFiles` (default: true) 3. **Minimum**: Update documentation to clearly warn users that `read` bypasses `.gitignore` ## Environment - OpenCode version: Latest (as of Feb 4, 2026) - Platform: macOS - Configuration: Default tool permissions ## Additional Context This was discovered while testing ignore patterns for sensitive evaluation documents. The inconsistency between tools creates a false sense of security - users expect `.gitignore` to protect sensitive files from agents, but `read` silently bypasses this protection. Common sensitive files that may be exposed: - `.env`, `.env.local`, `.env.production` - `credentials.json`, `secrets.yaml` - `*.pem`, `*.key` (private keys) - `.aws/credentials` - Any custom paths in `.gitignore`
yindo commented 2026-02-16 18:10:15 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Feb 4, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #4739: Unignoring the .gitignore with .ignore should allow reading the file - related to read tool and gitignore respect
  • #4694: Files mentioned in .gitignore are not getting ignored - directly related to gitignore not being respected
  • #11703: Potential path traversal in file read/write tools - related security concern with file read/write tools
  • #3164: Exclude files from being used - related feature request to exclude sensitive files

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Feb 4, 2026): This issue might be a duplicate of existing issues. Please check: - #4739: Unignoring the .gitignore with .ignore should allow reading the file - related to read tool and gitignore respect - #4694: Files mentioned in .gitignore are not getting ignored - directly related to gitignore not being respected - #11703: Potential path traversal in file read/write tools - related security concern with file read/write tools - #3164: Exclude files from being used - related feature request to exclude sensitive files Feel free to ignore if none of these address your specific case.
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
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#8552
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?