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

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.

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

@ symbols in Commands that dont resolve to files cause command failure #2261: @ symbols in Commands that don't resolve to files cause command failure - Similar @ file search functionality issues
Cancelling causes context loss #2324: Cancelling causes context loss - Session state management problems after reset operations
/exit hangs after new session #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.

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

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

@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

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

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

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

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?

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.

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.

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?

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

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

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

@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"]
    }

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

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

github-actions commented on Aug 31, 2025

agusmdev commented on Aug 31, 2025

rekram1-node commented on Aug 31, 2025

agusmdev commented on Aug 31, 2025

rekram1-node commented on Aug 31, 2025

ferrants commented on Sep 5, 2025

viraj-s15 commented on Sep 22, 2025

rekram1-node commented on Sep 22, 2025

yoadsn commented on Sep 25, 2025

yoadsn commented on Sep 25, 2025

asmelkowski commented on Sep 25, 2025

rekram1-node commented on Sep 25, 2025

asmelkowski commented on Sep 26, 2025

yoadsn commented on Sep 26, 2025

asmelkowski commented on Sep 26, 2025

rekram1-node commented on Dec 28, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions