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

High concern about rg.exe #7656

New Issue
Open
opened 2026-02-16 18:07:50 -05:00 by yindo · 19 comments
yindo commented 2026-02-16 18:07:50 -05:00
Owner
Copy Link
Copy Source

Originally created by @apintorp on GitHub (Jan 26, 2026).

Originally assigned to: @rekram1-node on GitHub.

Question

A file rg.exe under the path "C:\Users\prote.local\share\opencode\bin" start to read all my files.
why it is doing so? It is reading all the files on my computer, I was able to detect it because it start reading files from One drive and One drive notify me about the need to download to many files.

Image Image
Originally created by @apintorp on GitHub (Jan 26, 2026). Originally assigned to: @rekram1-node on GitHub. ### Question A file rg.exe under the path "C:\Users\prote\.local\share\opencode\bin" start to read all my files. why it is doing so? It is reading all the files on my computer, I was able to detect it because it start reading files from One drive and One drive notify me about the need to download to many files. <img width="636" height="185" alt="Image" src="https://github.com/user-attachments/assets/91cfa45b-8036-4c95-8908-2b0d38ceb02b" /> <img width="359" height="636" alt="Image" src="https://github.com/user-attachments/assets/6c70b499-e44c-4882-bdc9-c03e1772c000" />
yindo added the windows label 2026-02-16 18:07:50 -05:00
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 26, 2026):

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

  • #5727: OpenCode Desktop Windows ripgrep always fail
  • #5946: Grep tool fails on Windows: CRLF line ending not stripped from ripgrep path
  • #3389: no such file or directory, uv_spawn 'C:\Users\user.local\share\opencode\bin\rg.exe'

These issues are related to rg.exe (ripgrep) problems on Windows systems. Feel free to ignore if this addresses a different specific case.

@github-actions[bot] commented on GitHub (Jan 26, 2026): This issue might be a duplicate of existing issues. Please check: - #5727: OpenCode Desktop Windows ripgrep always fail - #5946: Grep tool fails on Windows: CRLF line ending not stripped from ripgrep path - #3389: no such file or directory, uv_spawn 'C:\Users\user\.local\share\opencode\bin\rg.exe' These issues are related to rg.exe (ripgrep) problems on Windows systems. Feel free to ignore if this addresses a different specific case.
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@goniz commented on GitHub (Jan 26, 2026):

This is the tool that is being used by OpenCode to implement the Glob/Grep tools.

This might happen if you started an OpenCode session in your user home directory where the OneDrive app puts a link to the cloud-synced folder. If you requested the LLM some operation that resulted in finding files or patterns in files this makes sense.

Make sure to run the OpenCode sessions in the actual project directory.

@goniz commented on GitHub (Jan 26, 2026): This is the tool that is being used by OpenCode to implement the Glob/Grep tools. This might happen if you started an OpenCode session in your user home directory where the OneDrive app puts a link to the cloud-synced folder. If you requested the LLM some operation that resulted in finding files or patterns in files this makes sense. Make sure to run the OpenCode sessions in the actual project directory.
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@apintorp commented on GitHub (Jan 26, 2026):

I can get that, but the thing is that is looking into all the disk, and all the files at the time that Open Code was just setting there idle.
I don't know why the tool is looking into my vacations photos on a place not related to the path the project Open Code is set to work.

@apintorp commented on GitHub (Jan 26, 2026): I can get that, but the thing is that is looking into all the disk, and all the files at the time that Open Code was just setting there idle. I don't know why the tool is looking into my vacations photos on a place not related to the path the project Open Code is set to work.
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@apintorp commented on GitHub (Jan 26, 2026):

By the way, that just happen when I install the version v1.1.36

@apintorp commented on GitHub (Jan 26, 2026): By the way, that just happen when I install the version v1.1.36
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@goniz commented on GitHub (Jan 26, 2026):

Do you happen to have a git directory in the user home directory? Please check

@goniz commented on GitHub (Jan 26, 2026): Do you happen to have a git directory in the user home directory? Please check
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Jan 26, 2026):

it's just a ripgrep alternative, it is used for all searches, greps and globbing. If it is reading random files either:

  • you are running opencode in a directory that has those files as children
  • opencode is calling it's grep/globs in directories that have them
@rekram1-node commented on GitHub (Jan 26, 2026): it's just a ripgrep alternative, it is used for all searches, greps and globbing. If it is reading random files either: - you are running opencode in a directory that has those files as children - opencode is calling it's grep/globs in directories that have them
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@apintorp commented on GitHub (Jan 26, 2026):

@rekram1-node thanks sir for the clarify what that file was about, and sorry if I didn't specify properly.
My concern was that it was actually opening files on folders that wasn't under open code directory nor the directory for the project.

@apintorp commented on GitHub (Jan 26, 2026): @rekram1-node thanks sir for the clarify what that file was about, and sorry if I didn't specify properly. My concern was that it was actually opening files on folders that wasn't under open code directory nor the directory for the project.
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@apintorp commented on GitHub (Jan 26, 2026):

@goniz yes, it I have a couple of it under "C:\Users\prote"

@apintorp commented on GitHub (Jan 26, 2026): @goniz yes, it I have a couple of it under "C:\Users\prote"
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@DanceMore commented on GitHub (Jan 26, 2026):

it seems like models enjoy calling rg with arguments that make it consuming 24 CPU cores, read godknows how many files, and basically return never because it takes too long. (this is on Linux using the opencode bundled rg)

@DanceMore commented on GitHub (Jan 26, 2026): it seems like models enjoy calling `rg` with arguments that make it consuming 24 CPU cores, read godknows how many files, and basically return never because it takes too long. (this is on Linux using the opencode bundled `rg`)
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@DanceMore commented on GitHub (Jan 26, 2026):

yeah, it's absolutely doing some dumb massive over-follow / over-traversal; possibly on ../ even ....

it seems to think my Rust code is in .....

.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/...

opencode is basically unusable to me with this issue; I'm gonna install an older version I think....

@DanceMore commented on GitHub (Jan 26, 2026): yeah, it's absolutely doing some dumb massive over-follow / over-traversal; possibly on `../` even .... it seems to think my Rust code is in ..... ``` .proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/... ``` `opencode` is basically unusable to me with this issue; I'm gonna install an older version I think....
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@goniz commented on GitHub (Jan 27, 2026):

Guys, opencode scopes the commands to the working directory of the project.

If you run opencode directly on your home directory, those things will keep happening.

@rekram1-node maybe we need to add some warning or disclaimer when launching opencode on the $HOME ?

@goniz commented on GitHub (Jan 27, 2026): Guys, opencode scopes the commands to the working directory of the project. If you run opencode directly on your home directory, those things will keep happening. @rekram1-node maybe we need to add some warning or disclaimer when launching opencode on the $HOME ?
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@DanceMore commented on GitHub (Jan 27, 2026):

I am absolutely using opencode . in project directories and still watching it escape quite frequently, using all manner of tools and techniques.

@DanceMore commented on GitHub (Jan 27, 2026): I am absolutely using `opencode .` in project directories and still watching it escape quite frequently, using all manner of tools and techniques.
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@goniz commented on GitHub (Jan 27, 2026):

Do you have examples?
In my experience it always asks for permission when out of project command / tool use is detected

@goniz commented on GitHub (Jan 27, 2026): Do you have examples? In my experience it always asks for permission when out of project command / tool use is detected
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@DanceMore commented on GitHub (Jan 27, 2026):

I will admit that I ran opencode . in ~/code instead of ~/code/$projectName; I'm still not sure how/why it chose to recurse upwards and also seemingly operate at infinite depths. definitely not just in homedir, come on, assume humans aren't totally asleep at the wheel ;)

# New session - 2026-01-27T02:57:33.566Z

**Session ID:** ses_4029d7081ffee5xDEovi0fo3Hr
**Created:** 1/26/2026, 6:57:33 PM
**Updated:** 1/26/2026, 7:35:41 PM

---

## User

thread 'main' (634114) panicked at /home/username/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bevy_ecs-0.17.3/src/error/handler.rs:125:1:
Encountered an error in system `acceptance_ui3d_01_press_controls::button_interaction_system`: Parameter `MessageReader<'_, '_, ButtonInteractionEvent>::messages` failed validation: Message not initialized
If this is an expected state, wrap the parameter in `Option<T>` and handle `None` when it happens, or wrap the parameter in `If<T>` to skip the system when it happens.

note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_app::main_schedule::Main::run_main`!
zsh: segmentation fault (core dumped)  cargo run --example acceptance_ui3d_01_press_controls 

---

## Assistant (Plan · @preset/free2-2026-01-24 · 716.9s)

Looking at this Rust panic error from a Bevy ECS application, I can see the issue is related to a system parameter not being properly initialized. Let me search for relevant files to understand the codebase structure and find the specific example that's failing.

```
Tool: glob

**Input:**
```json
{
  "pattern": "**/acceptance_ui3d_01_press_controls.rs"
}
```
**Output:**
```
No files found
```
```

---

## Assistant (Plan · @preset/free2-2026-01-24 · 199.8s)

Let me search more broadly for UI-related examples in this Bevy project:

```
Tool: glob

**Input:**
```json
{
  "pattern": "**/examples/**/*ui*.rs"
}
```
**Output:**
```
/home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3d_02_toggle_controls.rs
/home/username/.proton/pfx/dosdevices/z:/proc/2456985/task/2456985/cwd/examples/acceptance_ui3d_02_toggle_controls.rs
/home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3d_01_press_controls.rs
/home/username/.proton/pfx/dosdevices/z:/proc/2456985/task/2456985/cwd/examples/acceptance_ui3d_01_press_controls.rs
/home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3dslider_03_ranges.rs
/home/username/.proton/pfx/dosdevices/z:/proc/2456985/task/2456985/cwd/examples/acceptance_ui3dslider_03_ranges.rs
/home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3dsign_70_walk_around.rs
/home/username/.proton/pfx/dosdevices/z:/proc/2456985/task/2456985/cwd/examples/acceptance_ui3dsign_70_walk_around.rs
/home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3d_04_mixed_controls.rs
/home/username/.proton/pfx/dosdevices/z:/proc/2456985/task/2456985/cwd/examples/acceptance_ui3d_04_mixed_controls.rs
/home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3dbillboard_70_walk_around.rs
/home/username/.proton/pfx/dosdevices/z:/proc/2456985/task/2456985/cwd/examples/acceptance_ui3dbillboard_70_walk_around.rs
/home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3dbillboard_01_simple_text.rs
....

this is not the only pathology I've witnessed but this is the one that startled me the most.

@DanceMore commented on GitHub (Jan 27, 2026): I will admit that I ran `opencode .` in `~/code` instead of `~/code/$projectName`; I'm still not sure how/why it chose to recurse upwards and also seemingly operate at infinite depths. definitely not just in homedir, come on, assume humans aren't totally asleep at the wheel ;) # New session - 2026-01-27T02:57:33.566Z **Session ID:** ses_4029d7081ffee5xDEovi0fo3Hr **Created:** 1/26/2026, 6:57:33 PM **Updated:** 1/26/2026, 7:35:41 PM --- ## User thread 'main' (634114) panicked at /home/username/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bevy_ecs-0.17.3/src/error/handler.rs:125:1: Encountered an error in system `acceptance_ui3d_01_press_controls::button_interaction_system`: Parameter `MessageReader<'_, '_, ButtonInteractionEvent>::messages` failed validation: Message not initialized If this is an expected state, wrap the parameter in `Option<T>` and handle `None` when it happens, or wrap the parameter in `If<T>` to skip the system when it happens. note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Encountered a panic in system `bevy_app::main_schedule::Main::run_main`! zsh: segmentation fault (core dumped) cargo run --example acceptance_ui3d_01_press_controls --- ## Assistant (Plan · @preset/free2-2026-01-24 · 716.9s) Looking at this Rust panic error from a Bevy ECS application, I can see the issue is related to a system parameter not being properly initialized. Let me search for relevant files to understand the codebase structure and find the specific example that's failing. ``` Tool: glob **Input:** ```json { "pattern": "**/acceptance_ui3d_01_press_controls.rs" } ``` **Output:** ``` No files found ``` ``` --- ## Assistant (Plan · @preset/free2-2026-01-24 · 199.8s) Let me search more broadly for UI-related examples in this Bevy project: ``` Tool: glob **Input:** ```json { "pattern": "**/examples/**/*ui*.rs" } ``` **Output:** ``` /home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3d_02_toggle_controls.rs /home/username/.proton/pfx/dosdevices/z:/proc/2456985/task/2456985/cwd/examples/acceptance_ui3d_02_toggle_controls.rs /home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3d_01_press_controls.rs /home/username/.proton/pfx/dosdevices/z:/proc/2456985/task/2456985/cwd/examples/acceptance_ui3d_01_press_controls.rs /home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3dslider_03_ranges.rs /home/username/.proton/pfx/dosdevices/z:/proc/2456985/task/2456985/cwd/examples/acceptance_ui3dslider_03_ranges.rs /home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3dsign_70_walk_around.rs /home/username/.proton/pfx/dosdevices/z:/proc/2456985/task/2456985/cwd/examples/acceptance_ui3dsign_70_walk_around.rs /home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3d_04_mixed_controls.rs /home/username/.proton/pfx/dosdevices/z:/proc/2456985/task/2456985/cwd/examples/acceptance_ui3d_04_mixed_controls.rs /home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3dbillboard_70_walk_around.rs /home/username/.proton/pfx/dosdevices/z:/proc/2456985/task/2456985/cwd/examples/acceptance_ui3dbillboard_70_walk_around.rs /home/username/.proton/pfx/dosdevices/z:/proc/2456985/cwd/examples/acceptance_ui3dbillboard_01_simple_text.rs .... this is not the only pathology I've witnessed but this is the one that startled me the most.
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@apintorp commented on GitHub (Jan 27, 2026):

Image Image

This is an example

I had to stop the app rg.exe.

Translation:

When you ran "Grep pattern=Baleira", it started searching across the entire disk. It was reading files outside the directory you had specified. How can we fix this so it doesn’t happen again?

Response

You are absolutely right, and I apologize for that. The mistake was that when executing the grep command (search), I did not specify the path parameter, and by default the tool attempted to search starting from the system root (C:) downward.

Immediate fix for future interactions:

From now on, every time I need to search for something (using grep or glob), I will explicitly force the base path of your Second Brain in the tool’s path parameter.

That is, instead of:
grep(pattern="Baleira") ❌ (Searches the entire disk)

I will always execute:
grep(pattern="Baleira", path="C:/Users/prote/OneDrive/Escritorio/alfredo/IACont") ✅ (Searches only your folder)

I have already registered this restriction in my operational context to protect your privacy and avoid out-of-scope file reads.
@apintorp commented on GitHub (Jan 27, 2026): <img width="562" height="115" alt="Image" src="https://github.com/user-attachments/assets/d4694d71-4644-4f60-a2a6-3d69f42ac0c8" /> <img width="619" height="578" alt="Image" src="https://github.com/user-attachments/assets/fbd05e54-14a6-4a3f-a993-8a4331ad9e4b" /> This is an example I had to stop the app rg.exe. Translation: `When you ran "Grep pattern=Baleira", it started searching across the entire disk. It was reading files outside the directory you had specified. How can we fix this so it doesn’t happen again? ` Response ``` You are absolutely right, and I apologize for that. The mistake was that when executing the grep command (search), I did not specify the path parameter, and by default the tool attempted to search starting from the system root (C:) downward. Immediate fix for future interactions: From now on, every time I need to search for something (using grep or glob), I will explicitly force the base path of your Second Brain in the tool’s path parameter. That is, instead of: grep(pattern="Baleira") ❌ (Searches the entire disk) I will always execute: grep(pattern="Baleira", path="C:/Users/prote/OneDrive/Escritorio/alfredo/IACont") ✅ (Searches only your folder) I have already registered this restriction in my operational context to protect your privacy and avoid out-of-scope file reads. ```
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@goniz commented on GitHub (Jan 27, 2026):

@apintorp @DanceMore Can you share the sessions with the issue?
Try to use the commands:

  1. View the sessions and their IDs using: opencode session list
  2. Export the session as JSON file using opencode export <SESSION_ID>

@rekram1-node Additionally, I've opened a new PR with a fix for the bug that is responsible for rg process not exiting: https://github.com/anomalyco/opencode/pull/10833

@goniz commented on GitHub (Jan 27, 2026): @apintorp @DanceMore Can you share the sessions with the issue? Try to use the commands: 1. View the sessions and their IDs using: `opencode session list` 2. Export the session as JSON file using `opencode export <SESSION_ID>` @rekram1-node Additionally, I've opened a new PR with a fix for the bug that is responsible for `rg` process not exiting: https://github.com/anomalyco/opencode/pull/10833
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@DanceMore commented on GitHub (Jan 27, 2026):

What I gave you is the session /export; that's literally the first thing that session did after I gave it a stack trace was try to find files with rg and then light my CPU on fire.

I'm not comfortable giving out the raw file. I already hand-redacted usernames where I could, but that # New session - 2026-01-27T02:57:33.566Z is the true/literal start session header provided by /export. I ended the session immediately after it went awry instead of attempting to continue work in a now polluted context, so I truncated the enormous file list and me saying "do not use rg" and then tapping escape key. As far as I am aware, there is nothing hiding up my sleeves here.

edit: I guess JSON mode might show more, but /export spits out that markdown I provided.

@DanceMore commented on GitHub (Jan 27, 2026): What I gave you **is** the session `/export`; that's literally the **first** thing that session did after I gave it a stack trace was try to find files with `rg` and then light my CPU on fire. I'm not comfortable giving out the raw file. I already hand-redacted usernames where I could, but that `# New session - 2026-01-27T02:57:33.566Z` is the true/literal start session header provided by `/export`. I ended the session immediately after it went awry instead of attempting to continue work in a now polluted context, so I truncated the enormous file list and me saying "do not use rg" and then tapping escape key. As far as I am aware, there is nothing hiding up my sleeves here. edit: I guess JSON mode might show more, but /export spits out that markdown I provided.
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@goniz commented on GitHub (Jan 27, 2026):

What I gave you is the session /export; that's literally the first thing that session did after I gave it a stack trace was try to find files with rg and then light my CPU on fire.

I'm not comfortable giving out the raw file. I already hand-redacted usernames where I could, but that # New session - 2026-01-27T02:57:33.566Z is the true/literal start session header provided by /export. I ended the session immediately after it went awry instead of attempting to continue work in a now polluted context, so I truncated the enormous file list and me saying "do not use rg" and then tapping escape key. As far as I am aware, there is nothing hiding up my sleeves here.

edit: I guess JSON mode might show more, but /export spits out that markdown I provided.

Yes I specifically wanted to see the json export since it shows tool calls with params and more info about the flow that happened.

@goniz commented on GitHub (Jan 27, 2026): > What I gave you **is** the session `/export`; that's literally the **first** thing that session did after I gave it a stack trace was try to find files with `rg` and then light my CPU on fire. > > I'm not comfortable giving out the raw file. I already hand-redacted usernames where I could, but that `# New session - 2026-01-27T02:57:33.566Z` is the true/literal start session header provided by `/export`. I ended the session immediately after it went awry instead of attempting to continue work in a now polluted context, so I truncated the enormous file list and me saying "do not use rg" and then tapping escape key. As far as I am aware, there is nothing hiding up my sleeves here. > > edit: I guess JSON mode might show more, but /export spits out that markdown I provided. Yes I specifically wanted to see the json export since it shows tool calls with params and more info about the flow that happened.
yindo commented 2026-02-16 18:07:51 -05:00
Author
Owner
Copy Link
Copy Source

@DanceMore commented on GitHub (Jan 27, 2026):

I found the executive function within myself to go find and list the things.

...
      },
      "parts": [
        {
          "id": "prt_bfd6df978001Spjubie9WhGRlf",
          "sessionID": "ses_4029d7081ffee5xDEovi0fo3Hr",
          "messageID": "msg_bfd6d8062002cnq71GDGcS9MYQ",
          "type": "step-start"
        },
        {
          "id": "prt_bfd6df97b0013tEaNNEstC1ihu",
          "sessionID": "ses_4029d7081ffee5xDEovi0fo3Hr",
          "messageID": "msg_bfd6d8062002cnq71GDGcS9MYQ",
          "type": "text",
          "text": "Let me search more broadly for UI-related examples in this Bevy project:",
          "time": {
            "start": 1769483403171,
            "end": 1769483403171
          }
        },
        {
          "id": "prt_bfd6dff2c001i2L3Eoi271BYj3",
          "sessionID": "ses_4029d7081ffee5xDEovi0fo3Hr",
          "messageID": "msg_bfd6d8062002cnq71GDGcS9MYQ",
          "type": "tool",
          "callID": "call_200219fc115aa03b",
          "tool": "glob",
          "state": {
            "status": "completed",
            "input": {
              "pattern": "**/examples/**/*ui*.rs"
            },
            "output":  <what appears to be my entire File System listed>
...

so I'd guess this glob => "**/examples/**/*ui*.rs" is too ** ?

setting a default max-depth might help mitigate this. I had to do that with UNIX find when it was causing issues for endusers.

@DanceMore commented on GitHub (Jan 27, 2026): I found the executive function within myself to go find and list the things. ``` ... }, "parts": [ { "id": "prt_bfd6df978001Spjubie9WhGRlf", "sessionID": "ses_4029d7081ffee5xDEovi0fo3Hr", "messageID": "msg_bfd6d8062002cnq71GDGcS9MYQ", "type": "step-start" }, { "id": "prt_bfd6df97b0013tEaNNEstC1ihu", "sessionID": "ses_4029d7081ffee5xDEovi0fo3Hr", "messageID": "msg_bfd6d8062002cnq71GDGcS9MYQ", "type": "text", "text": "Let me search more broadly for UI-related examples in this Bevy project:", "time": { "start": 1769483403171, "end": 1769483403171 } }, { "id": "prt_bfd6dff2c001i2L3Eoi271BYj3", "sessionID": "ses_4029d7081ffee5xDEovi0fo3Hr", "messageID": "msg_bfd6d8062002cnq71GDGcS9MYQ", "type": "tool", "callID": "call_200219fc115aa03b", "tool": "glob", "state": { "status": "completed", "input": { "pattern": "**/examples/**/*ui*.rs" }, "output": <what appears to be my entire File System listed> ... ``` so I'd guess this glob => `"**/examples/**/*ui*.rs"` is too `**` ? setting a default max-depth might help mitigate this. I had to do that with UNIX `find` when it was causing issues for endusers.
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 windows
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#7656
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?