🧩 Bug report: @ mention in Codex CLI always returns “no matches”

This behavior is by design. You must type at least one character after the @ for Codex to present a list of possible file matches. Is that working for you? Are you expecting a different behavior?

This behavior is by design. You must type at least one character after the @ for Codex to present a list of possible file matches. Is that working for you? Are you expecting a different behavior?

Thanks for your reply!

You can take a look at my screenshot — I typed @go, but no files were matched.
However, on another device, the same command works perfectly and lists matching files.

On this MacBook Pro, the issue occurs in both zsh and bash (with no shell customizations), and also inside VS Code using the Codex extension — all show “no matches”.

I’ve already tried removing any .codex folder or config files to force a clean start, but it didn’t help.
Because Codex’s logging is quite limited, I’m unable to locate where the problem actually happens.

It feels like something specific to this machine or its environment is preventing the file matcher from initializing properly.

Apologies, I missed the @go in your screen shot.

For large workspaces, it can take a while to enumerate all of the files. Perhaps if you give it more time it will finish enumerating and present you with the matching files? If you try it on a smaller workspace, does it work?

Apologies, I missed the @go in your screen shot. For large workspaces, it can take a while to enumerate all of the files. Perhaps if you give it more time it will finish enumerating and present you with the matching files? If you try it on a smaller workspace, does it work?

I get the same result.

I created a brand-new empty folder (without initializing git) and added a few test files inside it — but Codex still couldn’t find or match any of them when I typed @.

So the issue doesn’t seem related to git or any repo configuration. It looks like the file search / mention feature itself isn’t working on this machine, even in completely clean directories.

<img width="806" height="727" alt="Image" src="https://github.com/user-attachments/assets/edbe6b4e-2f7b-4811-9bc4-ae72d33b520f" />

Thanks for following up — I’ve found the root cause.

There was an accidentally generated .gitignore file in my home directory, created automatically by a Python virtual environment (venv):

# created by virtualenv automatically
*

It seems that this global .gitignore unexpectedly affected Codex’s codex_file_search behavior.
Once I removed that file, @ file matching started working normally again.

What’s confusing is that I thought global ignore rules should only be loaded from .gitignore_global, not from a .gitignore sitting in ~.
So it looks like Codex might be treating the user’s home directory .gitignore as a root-level ignore file for all searches — which feels unintended.

    /// Enables reading a global gitignore file, whose path is specified in
    /// git's `core.excludesFile` config option.
    ///
    /// Git's config file location is `$HOME/.gitconfig`. If `$HOME/.gitconfig`
    /// does not exist or does not specify `core.excludesFile`, then
    /// `$XDG_CONFIG_HOME/git/ignore` is read. If `$XDG_CONFIG_HOME` is not
    /// set or is empty, then `$HOME/.config/git/ignore` is used instead.
    ///
    /// This is enabled by default.
    pub fn git_global(&mut self, yes: bool) -> &mut WalkBuilder {
        self.ig_builder.git_global(yes);
        self
    }

That makes sense — it looks like this behavior actually comes from the ignore library itself.

It doesn’t really distinguish between a repository-level .gitignore and what should be a global gitignore (e.g. .gitignore_global).
So if there’s a .gitignore sitting in your home directory (~), the library just treats it as an active ignore file for all subdirectories — which then ends up hiding everything from Codex’s codex_file_search.

This explains why removing the stray .gitignore in ~ immediately fixed the issue.