Prefix `./` to completion of `@{filename}` if the path is not obviously a path

Thanks for the report. I traced this through the TUI file-mention flow, and the selected match is currently inserted as the raw relative path. That means a current-directory extensionless match such as hello is submitted as hello, not ./hello.

A minimal implementation path would be to normalize at the composer insertion point: prefix ./ when the selected path is a single component, extensionless, and not already path-like, while leaving nested paths such as src/main.rs and existing path-like values such as ./hello, ../hello, or .hidden unchanged. This should be applied consistently to both the legacy file-search popup and the mentions v2 file selection path.

I also checked that this can be covered with a focused chat-composer regression test for @he<Tab> -> ./hello, alongside the existing coverage that nested file completion still inserts src/main.rs.

Because external code PRs are invitation-only per docs/contributing.md, I am leaving this as an implementation note rather than opening an unsolicited PR.

🔧 Proposed Solution

Root Cause

The @ mention/completion system completes filenames without any path prefix, making it ambiguous for the agent whether the completed text is a filename reference or just a regular word. Files without extensions (e.g., hello, Makefile) are especially ambiguous.

Fix

1. Add path prefix logic to the completion engine — prefix ./ for extensionless files in the current directory
2. Handle edge cases: skip prefix for files with extensions, subdirectory paths, hidden files, and obvious filenames (Makefile, Dockerfile, etc.)
3. Add completionPrefixDotSlash setting for users who prefer the old behavior
4. Update completion menu display to show the actual inserted text

Files to Modify

• src/cli/completion/file-completer.ts — Add path prefix logic
• src/settings.ts — Add completionPrefixDotSlash setting
• src/tui/completion-menu.ts — Update display to show inserted text

Complexity: Low (1-2 hours, additive prefix logic)

Full solution document: codex-24307-filename-completion-prefix-fix.md

I had the same problem with a PDF. After selecting @Tang_Primer_25K_Dock_60033_Schematic.pdf codex tried to find the file online instead of opening it locally. Because the file had an extension, the proposed ./ prefix would not fix this case. Could @ completions add structured metadata similar to how pasted images work?