anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-25 20:55:42 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

grep tool inherits user ripgrep config, which can silently alter search results #8953

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

Originally created by @neodejack on GitHub (Feb 10, 2026).

Originally assigned to: @rekram1-node on GitHub.

Description

Hi opencode team, i was looking at the implementation of grep tool from opencode.

it looks like opencode the grep tool spawns a rg command that could inherit any user-defined ripgrep configuration via the RIPGREP_CONFIG_PATH environment variable (commonly pointing to ~/.ripgreprc).

this causes user-specific ripgrep configuration to silently alter the grep tool behavior.

For example:
i have --max-columns=150 in my ~/.ripgreprc, and in my ~/.zshrc i have set export RIPGREP_CONFIG_PATH=$HOME/.ripgreprc.
this config globally replaces matched line content with [Omitted long matching line] when running rg to search.
when opencode is executing grep tool, this configuration also applies, which could mean useful context is stripped away.

this is not necessarily a bug in a sense that i haven't verified verify there is a degration of opencode performance. however, since user can put anything in the global ripgreprc file, i think it's better not to let user specific configuration affect the tool call execution result.

Plugins

N/A

OpenCode version

1.1.53

Steps to reproduce

these steps verifies that a global ripgreprc file can affect opencode tool call result output

  1. i have created two files ripgreprc and testfile.txt
$ tree
.
├── ripgreprc
└── testfile.txt

1 directory, 2 files

$ cat ripgreprc
--max-columns=10

$ cat testfile.txt
AAAAAAAAAA_FINDME_this_text_is_after_column_10
  1. running opencode debug agent build --tool grep to see that tool execution
    output. firstly we set RIPGREP_CONFIG_PATH to empty. we can see that the
    tool call result output contain the whole line.
$ RIPGREP_CONFIG_PATH="" opencode debug agent build --tool grep \
  --params '{"pattern":"FINDME","path":"/tmp/opencode-grep-test"}' | jq .result.output

## result output
"Found 1 matches\n/tmp/opencode-grep-test/testfile.txt:\n  Line 1: AAAAAAAAAA_FINDME_this_text_is_after_column_10"

then we set RIPGREP_CONFIG_PATH to our ripgreprc. we can see that the
tool call result output is stripped

$ RIPGREP_CONFIG_PATH="ripgreprc" opencode debug agent build --tool grep \
  --params '{"pattern":"FINDME","path":"/tmp/opencode-grep-test"}' | jq .result.output

## result output
"Found 1 matches\n/tmp/opencode-grep-test/testfile.txt:\n  Line 1: [Omitted long matching line]"

Screenshot and/or share link

na

Operating System

macOS 26.2

Terminal

wezterm

Originally created by @neodejack on GitHub (Feb 10, 2026). Originally assigned to: @rekram1-node on GitHub. ### Description Hi opencode team, i was looking at the implementation of grep tool from opencode. it looks like opencode the `grep` tool spawns a `rg` command that could inherit any user-defined ripgrep configuration via the `RIPGREP_CONFIG_PATH` environment variable (commonly pointing to `~/.ripgreprc`). this causes user-specific ripgrep configuration to silently alter the `grep` tool behavior. For example: i have `--max-columns=150` in my `~/.ripgreprc`, and in my `~/.zshrc` i have set `export RIPGREP_CONFIG_PATH=$HOME/.ripgreprc`. this config globally replaces matched line content with `[Omitted long matching line]` when running `rg` to search. when opencode is executing `grep` tool, this configuration also applies, which could mean useful context is stripped away. this is not necessarily a bug in a sense that i haven't verified verify there is a degration of opencode performance. however, since user can put anything in the global `ripgreprc` file, i think it's better not to let user specific configuration affect the tool call execution result. ### Plugins N/A ### OpenCode version 1.1.53 ### Steps to reproduce these steps verifies that a global ripgreprc file can affect opencode tool call result output 1. i have created two files `ripgreprc` and `testfile.txt` ```bash $ tree . ├── ripgreprc └── testfile.txt 1 directory, 2 files $ cat ripgreprc --max-columns=10 $ cat testfile.txt AAAAAAAAAA_FINDME_this_text_is_after_column_10 ``` 2. running `opencode debug agent build --tool grep` to see that tool execution output. firstly we set `RIPGREP_CONFIG_PATH` to empty. we can see that the tool call result output contain the whole line. ```bash $ RIPGREP_CONFIG_PATH="" opencode debug agent build --tool grep \ --params '{"pattern":"FINDME","path":"/tmp/opencode-grep-test"}' | jq .result.output ## result output "Found 1 matches\n/tmp/opencode-grep-test/testfile.txt:\n Line 1: AAAAAAAAAA_FINDME_this_text_is_after_column_10" ``` then we set `RIPGREP_CONFIG_PATH` to our `ripgreprc`. we can see that the tool call result output is stripped ```bash $ RIPGREP_CONFIG_PATH="ripgreprc" opencode debug agent build --tool grep \ --params '{"pattern":"FINDME","path":"/tmp/opencode-grep-test"}' | jq .result.output ## result output "Found 1 matches\n/tmp/opencode-grep-test/testfile.txt:\n Line 1: [Omitted long matching line]" ``` ### Screenshot and/or share link na ### Operating System macOS 26.2 ### Terminal wezterm
yindo added the bug label 2026-02-16 18:11:15 -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 bug
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#8953
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?