at-mentions of files is unreliable when using remote connection
Resolved 💬 7 comments Opened Apr 23, 2026 by winoros Closed May 31, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of the Codex App are you using (From “About Codex” dialog)?
26.421.11020
What subscription do you have?
Pro
What platform is your computer?
Windows 11
What issue are you seeing?
Just do some file searching on the remote workspace. The result is unreliable, it's wrong or no response.
The remote workspace is my local headless machine, so the network is robust and fast.
https://github.com/user-attachments/assets/5747346f-9f04-4393-b621-e0750cc2cb21
What steps can reproduce the bug?
I used the codex repo as an example.
What is the expected behavior?
Reliable and fast results.
Additional information
_No response_
7 Comments
And I'll meet the same problem if I use my mbp.
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Can you say more about what you mean by "file searching"? Are you asking the agent to scan for text in your files or search for file names within your project? Are you attempting to at-mention a file in your prompt?
Oh, I mean the
@search when prompting, like what I did in the screen recording.Ok, seems that github will not render the video in the issue description. I copied it here.
https://github.com/user-attachments/assets/ab9a79ae-1100-467f-8e69-dfee4de146b3
Oh, I just tested it in another way:
codex app-server --listen ws://127.0.0.1:4500-Cto specify the working dir.Its result is also unreliable.
If I use
-Cto specify the codex repo dir and then another one.I can see this:
<img width="1956" height="864" alt="Image" src="https://github.com/user-attachments/assets/af54f6a0-f23f-4840-bd21-d5cacc364444" />
Note that the CLI is started under the codex repo. I'm not sure whether this behavior is a bug or by design, and whether it's related to the app bug. Just put it for your information.
It seems that the at-mention v2 has now solved the issue.
@etraut-openai Maybe the issue can be closed, or close it until the feature becomes stable?
I did several simple tries, and they all worked.
Ah, there are unresolved cases, but they may not be in the standard workflow.
If I use
codex app-server --listen ws://127.0.0.1:4500and then usecodex --remote ws://127.0.0.1:4500 -C workdir, the search result is not restricted to the workdir. I would see the search results across all writable roots.