@filename lookup broken: “no matches” in trusted roots

[philcockfield]

What version of Codex is running?

0.80.0

What subscription do you have?

Plus

Which model were you using?

Codex (GPT-5) — issue not model-specific

What platform is your computer?

Darwin 24.6.0 arm64

What issue are you seeing?

Summary
After starting Codex in a non‑git folder and choosing “Require approval of edits and commands,” @filename
stops working in trusted workspaces and returns “no matches.” This side effect is non‑obvious and appears
unrelated to safety.

What steps can reproduce the bug?

1. Start Codex in a non‑git folder.
2. Choose “Require approval of edits and commands.”
3. Open a trusted workspace and use @filename.

What is the expected behavior?

@filename resolves consistently in trusted workspaces.

Additional information

I tried removing the persisted trust entry in the TOML config; it sometimes helps after a terminal restart but
not reliably. This suggests the issue isn’t fully resolved by deleting that entry alone.

[yuvrajangadsingh]

I've submitted a fix for this in PR #9279.

The root cause is that FileSearchManager is created once with the initial search_dir and never updated when the session's working directory changes. When you start in a non-git folder and then resume/open a different workspace, the file search still looks in the original directory.

The fix adds an update_search_dir() method and calls it when:

• A new session is created
• A session is resumed (uses resumed session's CWD)
• A session is forked (uses forked session's CWD)