anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-08-24 06:33:01 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

File search with @ doesn't work properly after the first message #1550

New Issue
Closed
opened 2026-02-16 17:31:29 -05:00 by yindo · 16 comments
yindo commented 2026-02-16 17:31:29 -05:00
Owner
Copy Link
Copy Source

Originally created by @agusmdev on GitHub (Aug 31, 2025).

Originally assigned to: @adamdotdevin on GitHub.

File search using "@" doesn't work properly after starting a new session with /new.
If I close the OpenCode terminal and open it again, file search works as expected. However, if I use /new to reset the current session, the "@" syntax for searching files doesn't work as expected—it seems to hang while searching.

Originally created by @agusmdev on GitHub (Aug 31, 2025). Originally assigned to: @adamdotdevin on GitHub. File search using "@" doesn't work properly after starting a new session with /new. If I close the OpenCode terminal and open it again, file search works as expected. However, if I use /new to reset the current session, the "@" syntax for searching files doesn't work as expected—it seems to hang while searching.
yindo closed this issue 2026-02-16 17:31:29 -05:00
yindo commented 2026-02-16 17:31:29 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Aug 31, 2025):

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

  • #2261: @ symbols in Commands that don't resolve to files cause command failure - Similar @ file search functionality issues
  • #2324: Cancelling causes context loss - Session state management problems after reset operations
  • #1810: /exit hangs after new session - Commands hanging specifically after /new session command

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

@github-actions[bot] commented on GitHub (Aug 31, 2025): This issue might be a duplicate of existing issues. Please check: - #2261: @ symbols in Commands that don't resolve to files cause command failure - Similar @ file search functionality issues - #2324: Cancelling causes context loss - Session state management problems after reset operations - #1810: /exit hangs after new session - Commands hanging specifically after /new session command Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@agusmdev commented on GitHub (Aug 31, 2025):

I just realized that this has nothing to do with the /new command, it seems the "@" search command only works when you just start the session, and then it doesn't work anymore

@agusmdev commented on GitHub (Aug 31, 2025): I just realized that this has nothing to do with the /new command, it seems the "@" search command only works when you just start the session, and then it doesn't work anymore
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Aug 31, 2025):

only works when you start session, then doesn't work anymore

What os are you?

Also does this happen regardless of where you are running opencode? Ive only seen this happen for massive projects

@rekram1-node commented on GitHub (Aug 31, 2025): > only works when you start session, then doesn't work anymore What os are you? Also does this happen regardless of where you are running opencode? Ive only seen this happen for massive projects
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@agusmdev commented on GitHub (Aug 31, 2025):

@rekram1-node

only works when you start session, then doesn't work anymore

What os are you?

Macbook M2 Pro - Sequoia 15.6.1

Also does this happen regardless of where you are running opencode? Ive only seen this happen for massive projects

Yes! I usually run opencode inside cursor opening it in the terminal there, also if I open opencode directly in my iterm2 terminal have the same issue.

I also receive this warning everytime I open opencode, might it be related?

opencode
warn: CPU lacks AVX support, strange crashes may occur. Reinstall Bun or use *-baseline build:
  https://github.com/oven-sh/bun/releases/download/bun-v1.2.19/bun-darwin-x64-baseline.zip
panic: reflect: NumField of non-struct type tea.Model

And regarding the size of the project, it's super small, maybe 10 folders and 30-40 files. And I have this issue in all the projects I'm working on

@agusmdev commented on GitHub (Aug 31, 2025): @rekram1-node > > only works when you start session, then doesn't work anymore > > What os are you? Macbook M2 Pro - Sequoia 15.6.1 > Also does this happen regardless of where you are running opencode? Ive only seen this happen for massive projects Yes! I usually run opencode inside cursor opening it in the terminal there, also if I open `opencode` directly in my iterm2 terminal have the same issue. I also receive this warning everytime I open opencode, might it be related? ```bash opencode warn: CPU lacks AVX support, strange crashes may occur. Reinstall Bun or use *-baseline build: https://github.com/oven-sh/bun/releases/download/bun-v1.2.19/bun-darwin-x64-baseline.zip panic: reflect: NumField of non-struct type tea.Model ``` And regarding the size of the project, it's super small, maybe 10 folders and 30-40 files. And I have this issue in all the projects I'm working on
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Aug 31, 2025):

ahhh okay that warning may be related that's good to know

@rekram1-node commented on GitHub (Aug 31, 2025): ahhh okay that warning may be related that's good to know
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@ferrants commented on GitHub (Sep 5, 2025):

I experience this too. I run it in tmux inside kitty on ubuntu. I don't see any warnings.

@ferrants commented on GitHub (Sep 5, 2025): I experience this too. I run it in tmux inside kitty on ubuntu. I don't see any warnings.
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@viraj-s15 commented on GitHub (Sep 22, 2025):

I am also experiencing this, on Macos, on both Ghostty and Alacritty, dont see any warnings

@viraj-s15 commented on GitHub (Sep 22, 2025): I am also experiencing this, on Macos, on both Ghostty and Alacritty, dont see any warnings
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Sep 22, 2025):

Hmm that is unexpected how big of a project are you working in? if you try it in a super small one does it work normal?

@rekram1-node commented on GitHub (Sep 22, 2025): Hmm that is unexpected how big of a project are you working in? if you try it in a super small one does it work normal?
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@yoadsn commented on GitHub (Sep 25, 2025):

Seeing the same behavior for a while now - More info. (osx, m1, iterm2, opencode version - I estimate ~0.7 - 0.11)

If you wait long enough (sometimes up to a 30-60s) the list of files eventually catches up.

It seems like after the first uses of @, where you do get proper results, something get's messed up - the @ will show the previous results list, is if frozen, and if you wait long enough as I mentioned the list catches up. I don't yet have a proper repro steps, but it happens all the time. (not rare).

Each key stroke, takes on my machine 15-20 sec to update the list, so for 4 key strokes I need to wait about a min. all the while, the opencode process is at 100% cpu. I can confirm every additional keystroke (or backspace) will drive the CPU up to 100% until it is fully processed.

This is all within the same session, within the same message doing what I described above.

@yoadsn commented on GitHub (Sep 25, 2025): Seeing the same behavior for a while now - More info. (osx, m1, iterm2, opencode version - I estimate ~0.7 - 0.11) If you wait long enough (sometimes up to a 30-60s) the list of files eventually catches up. It seems like after the first uses of @, where you do get proper results, something get's messed up - the @ will show the previous results list, is if frozen, and if you wait long enough as I mentioned the list catches up. I don't yet have a proper repro steps, but it happens all the time. (not rare). Each key stroke, takes on my machine 15-20 sec to update the list, so for 4 key strokes I need to wait about a min. all the while, the opencode process is at 100% cpu. I can confirm every additional keystroke (or backspace) will drive the CPU up to 100% until it is fully processed. This is all within the same session, within the same message doing what I described above.
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@yoadsn commented on GitHub (Sep 25, 2025):

I have noticed that this problem occurs in one of two projects I work on atm.
problem occurs -> A python project - (uv, large data folder with binary data, perhaps not ignored?)
no problem -> a TS monorepo with multiple packages, large node modules - works fast as expected.

Is there a way to debug this and check which folders are scanned? I wonder why the first attempt is fast, but at some point it becomes sluggish if indeed it's a problem of scanning large folders or binary data.

@yoadsn commented on GitHub (Sep 25, 2025): I have noticed that this problem occurs in one of two projects I work on atm. problem occurs -> A python project - (uv, large data folder with binary data, perhaps not ignored?) no problem -> a TS monorepo with multiple packages, large node modules - works fast as expected. Is there a way to debug this and check which folders are scanned? I wonder why the first attempt is fast, but at some point it becomes sluggish if indeed it's a problem of scanning large folders or binary data.
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@asmelkowski commented on GitHub (Sep 25, 2025):

I did some debugging and it seems that fzf returns the matched files quickly. It just that the 'server' is not up to speed and i takes a long time for it to get that latest fzf result and put it in 'UI'


ERROR 2025-09-25T14:16:03 +0ms service=ripgrep /opt/homebrew/bin/rg --files --follow --hidden --glob='!.git/*' | /opt/homebrew/bin/fzf --filter=<search_term> | head -n 10
ERROR 2025-09-25T14:16:03 +33ms service=ripgrep <some-files-result> 

INFO  2025-09-25T14:16:03 +0ms service=server duration=33 response
INFO  2025-09-25T14:16:03 +0ms service=server method=GET path=/find/symbol request
INFO  2025-09-25T14:16:38 +34681ms service=server duration=38178 response
INFO  2025-09-25T14:16:38 +63ms service=server duration=38074 response
INFO  2025-09-25T14:16:38 +61ms service=server duration=38046 response
INFO  2025-09-25T14:16:38 +35ms service=server duration=38018 response
INFO  2025-09-25T14:16:38 +52ms service=server duration=37549 response
INFO  2025-09-25T14:16:38 +126ms service=server duration=37540 response
INFO  2025-09-25T14:16:39 +189ms service=server duration=37562 response
INFO  2025-09-25T14:16:39 +162ms service=server duration=37091 response
INFO  2025-09-25T14:16:39 +54ms service=server duration=37041 response
INFO  2025-09-25T14:16:39 +20ms service=server duration=36971 response
INFO  2025-09-25T14:16:39 +31ms service=server duration=36912 response
INFO  2025-09-25T14:16:39 +14ms service=server duration=36642 response
INFO  2025-09-25T14:16:39 +3ms service=server duration=36407 response
INFO  2025-09-25T14:16:39 +4ms service=server duration=36275 response
INFO  2025-09-25T14:16:39 +3ms service=server duration=36158 response
INFO  2025-09-25T14:16:39 +1ms service=server duration=36068 response
INFO  2025-09-25T14:16:39 +2ms service=server duration=35857 response
INFO  2025-09-25T14:16:39 +1ms service=server duration=35816 response
INFO  2025-09-25T14:16:39 +2ms service=server duration=35636 response
INFO  2025-09-25T14:16:39 +1ms service=server duration=35505 response
  • those ERROR logs are added by me to see the actual search command along with its result.

EDIT: did some more digging and turns out it's the lsp /find/symbol endpoint that takes very long to complete. Would explain why it seems to only happen in python projects?

@asmelkowski commented on GitHub (Sep 25, 2025): I did some debugging and it seems that fzf returns the matched files quickly. It just that the 'server' is not up to speed and i takes a long time for it to get that latest fzf result and put it in 'UI' ``` ERROR 2025-09-25T14:16:03 +0ms service=ripgrep /opt/homebrew/bin/rg --files --follow --hidden --glob='!.git/*' | /opt/homebrew/bin/fzf --filter=<search_term> | head -n 10 ERROR 2025-09-25T14:16:03 +33ms service=ripgrep <some-files-result> INFO 2025-09-25T14:16:03 +0ms service=server duration=33 response INFO 2025-09-25T14:16:03 +0ms service=server method=GET path=/find/symbol request INFO 2025-09-25T14:16:38 +34681ms service=server duration=38178 response INFO 2025-09-25T14:16:38 +63ms service=server duration=38074 response INFO 2025-09-25T14:16:38 +61ms service=server duration=38046 response INFO 2025-09-25T14:16:38 +35ms service=server duration=38018 response INFO 2025-09-25T14:16:38 +52ms service=server duration=37549 response INFO 2025-09-25T14:16:38 +126ms service=server duration=37540 response INFO 2025-09-25T14:16:39 +189ms service=server duration=37562 response INFO 2025-09-25T14:16:39 +162ms service=server duration=37091 response INFO 2025-09-25T14:16:39 +54ms service=server duration=37041 response INFO 2025-09-25T14:16:39 +20ms service=server duration=36971 response INFO 2025-09-25T14:16:39 +31ms service=server duration=36912 response INFO 2025-09-25T14:16:39 +14ms service=server duration=36642 response INFO 2025-09-25T14:16:39 +3ms service=server duration=36407 response INFO 2025-09-25T14:16:39 +4ms service=server duration=36275 response INFO 2025-09-25T14:16:39 +3ms service=server duration=36158 response INFO 2025-09-25T14:16:39 +1ms service=server duration=36068 response INFO 2025-09-25T14:16:39 +2ms service=server duration=35857 response INFO 2025-09-25T14:16:39 +1ms service=server duration=35816 response INFO 2025-09-25T14:16:39 +2ms service=server duration=35636 response INFO 2025-09-25T14:16:39 +1ms service=server duration=35505 response ``` * those ERROR logs are added by me to see the actual search command along with its result. EDIT: did some more digging and turns out it's the lsp `/find/symbol` endpoint that takes very long to complete. Would explain why it seems to only happen in python projects?
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Sep 25, 2025):

Yes that would explain it, interesting... thanks for calling it out

@rekram1-node commented on GitHub (Sep 25, 2025): Yes that would explain it, interesting... thanks for calling it out
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@asmelkowski commented on GitHub (Sep 26, 2025):

Switching from default and builtin pyright to basedpyright fixes it.
Based on this issue it looks like microsoft is aware of this but are reluctant to fix:

Pylance, the VS Code language server based on pyright, implements indexing functionality for this purpose.
We don't have any plans to move that functionality to pyright, which is primarily focused on type checking.
@asmelkowski commented on GitHub (Sep 26, 2025): Switching from default and builtin `pyright` to `basedpyright` fixes it. Based on [this issue](https://github.com/microsoft/pyright/issues/1997) it looks like microsoft is aware of this but are reluctant to fix: ``` Pylance, the VS Code language server based on pyright, implements indexing functionality for this purpose. We don't have any plans to move that functionality to pyright, which is primarily focused on type checking. ```
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@yoadsn commented on GitHub (Sep 26, 2025):

Switching from default and builtin pyright to basedpyright fixes it. Based on this issue it looks like microsoft is aware of this but are reluctant to fix:

Pylance, the VS Code language server based on pyright, implements indexing functionality for this purpose.
We don't have any plans to move that functionality to pyright, which is primarily focused on type checking.

@asmelkowski Can you please TLDR; the workaround - how to configure the mentioned "switching" ?

@yoadsn commented on GitHub (Sep 26, 2025): > Switching from default and builtin `pyright` to `basedpyright` fixes it. Based on [this issue](https://github.com/microsoft/pyright/issues/1997) it looks like microsoft is aware of this but are reluctant to fix: > > ``` > Pylance, the VS Code language server based on pyright, implements indexing functionality for this purpose. > We don't have any plans to move that functionality to pyright, which is primarily focused on type checking. > ``` @asmelkowski Can you please TLDR; the workaround - how to configure the mentioned "switching" ?
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@asmelkowski commented on GitHub (Sep 26, 2025):

@yoadsn
Something like this in your opencode.json:

  "lsp": {
    "pyright": {
      "disabled": true
    },
    "ty": {
      "command": ["uvx", "ty", "server"],
      "extensions": [".py"]
    }
  }

Here I achieved similar results with ty but that's a very early version, so basedpyright is probably better choice (although it complains more than pyright).

 "basedpyright": {
      "command": ["npx", "-y", "basedpyright"],
      "extensions": [".py"]
    }
@asmelkowski commented on GitHub (Sep 26, 2025): @yoadsn Something like this in your `opencode.json`: ``` "lsp": { "pyright": { "disabled": true }, "ty": { "command": ["uvx", "ty", "server"], "extensions": [".py"] } } ``` Here I achieved similar results with `ty` but that's a very early version, so `basedpyright` is probably better choice (although it complains more than pyright). ``` "basedpyright": { "command": ["npx", "-y", "basedpyright"], "extensions": [".py"] } ```
yindo commented 2026-02-16 17:31:30 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 27, 2025):

[automated] Closing due to 90+ days of inactivity. Feel free to reopen if you still need this!

@rekram1-node commented on GitHub (Dec 27, 2025): [automated] Closing due to 90+ days of inactivity. Feel free to reopen if you still need this!
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#1550
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?