### What feature would you like to see? Support **absolute paths** and **`~` (home) expansion** in `@` file mentions / fuzzy file search in Codex TUI (and ideally aligned behavior in app-server fuzzy search). Examples that should work: - `@/home/alice/project/src/main.rs` - `@~/project/src/main.rs` - `@~/project/src/mai` (fuzzy completion) ### Why this matters Today, `@` search works well for relative-in-workspace paths, but fails for common path forms users type from shell habit: - absolute

Support absolute paths and `~` expansion in `@` file mentions/fuzzy search

Open 💬 2 comments Opened Feb 17, 2026 by KaminariOS

What feature would you like to see?

Support absolute paths and ~ (home) expansion in @ file mentions / fuzzy file search in Codex TUI (and ideally aligned behavior in app-server fuzzy search).

Examples that should work:

@/home/alice/project/src/main.rs
@~/project/src/main.rs
@~/project/src/mai (fuzzy completion)

Why this matters

Today, @ search works well for relative-in-workspace paths, but fails for common path forms users type from shell habit:

absolute filesystem paths
home-relative paths using ~

This creates friction when referencing files outside current relative context or when users naturally paste absolute paths from terminal/editor.

Current behavior (from source)

From codex-rs current main:

@token query is forwarded as raw text (no path normalization / tilde expansion).
file-search indexes and returns relative paths from search roots.
selected popup match inserts that relative path.

So @~/... is treated literally and absolute-prefix query matching is not first-class.

Suggested behavior

Recognize and normalize path-like @ queries before fuzzy matching:

expand ~ to user home
detect absolute paths
normalize separators and dot segments

Resolve query against active search roots:

if query points inside a configured root, fuzzy-match the relative suffix within that root
if query resolves outside current roots, either:
show a clear "outside search roots" message, or
optionally propose/add as an extra search root (future enhancement)

Preserve current behavior for plain fuzzy tokens (non path-like input).

Nice-to-have

Add tests for:
@~/... expansion
absolute path inside root
absolute path outside root
mixed separator cases (Windows + POSIX)

Align app-server fuzzy file search semantics with TUI for consistency.

Additional information

Related existing issues around @ search UX:

#1261 (support @ fuzzy file search)
#2867 (default list UX)
#8863 (directory selection)
#2952 (gitignore scope)

View original on GitHub ↗

2 Comments

oxysoft · 5 months ago

Linking #14673 here because it feels like the broader sibling issue.

This ticket is specifically about absolute paths and ~ expansion inside @ file mentions / fuzzy search. #14673 generalizes the expectation to the composer itself: if the user is typing path-shaped tokens like /..., ~/..., ../..., or ./... inline, Codex should offer shell-like path completion there too.

These two issues probably want to share backend/path-normalization semantics even if the UI surfaces differ.

Akram012388 · 1 month ago

Confirmed this limitation still exists in Codex CLI 0.145.0 on macOS.

Reproduction:

Start Codex inside a repository.
Type @ followed by an absolute path, ~/..., or ../... pointing outside the repository.
No matching external file is offered.
Start Codex with --add-dir /path/to/external/directory and repeat.
The directory becomes an additional accessible workspace root, but @ autocomplete still searches only the primary cwd.

This is separate from sandbox permissions. It also reproduces with sandbox_mode = "danger-full-access".

It would be useful for @ search to include all explicit --add-dir roots. A persistent config option such as file_search_roots or equivalent would also help users who regularly reference files across repositories, while preserving the current repository as the primary working directory.