Support shell-like path autocomplete directly in the composer

Related tracker context:

• @filename autocomplete bug: #11079
• absolute paths and ~ in @ mentions: #11996
• Tab collision / accidental prompt queueing: #12939

Those issues cover nearby fragments. This issue is the broader composer-level ask: shell-like path completion for inline path-shaped tokens such as /..., ~/..., ../..., and ./..., not just @ mention flows.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #12939
• #13089
• #14621

Powered by Codex Action

The heuristic for this feature request is incomplete. If I start typing src/, it would be a path that does not match the proposed patterns. The @ prefix is an inexpensive alternative to heuristic logic that doesn't have false negatives, and false positives are trivially dismissed.

On the UX of tab completing paths, the problem I have with the existing implementation is not the @ prefix, it's that tab only selects whatever path is currently highlighted in the selector! Shell path completion does incremental segment-based completion. And that's very important for deep and wide directory structures. Scrolling a selection menu dozens of times trying to find exactly the right file is tedious. Typing out a multi-segment prefix just to filter the selection box down enough that the tab key becomes useful is also annoying.

A nice-to-have in this area is fuzzy search matched by Levenshtein or Jaro-Winkler distance to gracefully handle typos and transpositions. But I can do without it if completion is improved.

I’m hitting a related @ mention workflow issue.

When typing @ and selecting a directory from the completion menu, pressing Enter or Tab accepts the directory but exits/hides the @ mention mode. That makes it awkward to keep building a deeper path.

Example workflow:

1. Type @Doc
2. Select Documents/
3. Press Tab or Enter
4. The mention/completion mode closes, so continuing into Documents/ObsidianVault/... is not convenient

The workaround is to move back to the beginning of the partial path and add @ again so Codex treats the path as an indexed file reference.

Expected behavior: accepting a directory completion should keep mention/path-completion mode active, probably inserting a trailing / and showing entries inside that directory. This would make @ file references usable for deep paths without repeatedly restarting mention mode.

I’m hitting a related @ mention workflow issue. When typing @ and selecting a directory from the completion menu, pressing Enter or Tab accepts the directory but exits/hides the @ mention mode. That makes it awkward to keep building a deeper path. Example workflow: 1. Type @Doc 2. Select Documents/ 3. Press Tab or Enter 4. The mention/completion mode closes, so continuing into Documents/ObsidianVault/... is not convenient The workaround is to move back to the beginning of the partial path and add @ again so Codex treats the path as an indexed file reference. Expected behavior: accepting a directory completion should keep mention/path-completion mode active, probably inserting a trailing / and showing entries inside that directory. This would make @ file references usable for deep paths without repeatedly restarting mention mode.

I think the core issue here is that completion is not iterative.

Current behavior:

1. Type a partial path after @
2. Completion menu appears
3. Select a directory
4. Press Tab

At that point:

• the completion is inserted
• the leading @ disappears
• completion mode exits

This makes descending a directory tree awkward because continuing completion requires:

1. moving back to the beginning of the path
2. re-inserting @
3. re-triggering completion

In practice, reaching a deep path can require several rounds of this.

What I expected instead was normal shell/editor-style path completion semantics:

• accepting a directory completion preserves completion state
• repeated Tab continues completion deeper into the tree
• completion remains active while editing the path

For example, after completing:
@src/components

I would expect to be able to continue with:
/but

and immediately continue tab-completing from there, without restarting completion from the beginning of the path.

@Timothy-W-Hilton This is the core issue for me as well.

When navigating through nested directories, the tab behaviour should, at _minimum_:

• if current selection is a directory, use tab to append it to the @ file mention, and present that directory's contents as tab-completable so one can keep building out the filepath
• if current selection is a directory, use enter to append it to the @ file mention, and exit the file navigator
• if current selection is a file, use tab or enter to append it to the @ file mention, and exit the file navigator

@parasyte mentions fuzzy matching - that would be a blessed add-on as well.

This seems so basic at first blush. The current implementation feels like trying to drive a car with a floppy, loose chain for a steering-wheel. Tabbing one's way through filepath completion is pretty basic stuff for anyone used to working in a shell - it's not some novel feature to present as an extra nicety, it's basic ingrained-habit necessity.

_edit:_ I'm probably quite late in learning this, but there is a workflow behaviour that allows for filepath building. Consider the following filepath:

plans/very_large_refactor/service_xyz_blah/04A_long_complex_phase_with_desc.md

If one types a part of each word and then a forward slash, the navigator keeps building forward. So, for the following prompt, one can type the following:

Please read the planning document at @pla/very_lar/service_xy/04A

and then the file navigator will highlight the target file 04A_long_complex_phase_with_desc.md (assuming one has typed enough to uniquely identify it). Then, tab or enter selects it which fully expands the completed (relative) path in the prompt.

It's ugly, but it works.

I still would like to request sensible tab behaviour in filepath navigation/completion.