IDE extension should send file path and line/column metadata for selected editor context #14592
Description
What version of the IDE extension are you using?
26.311.21342
What subscription do you have?
ChatGPT Plus
Which IDE are you using?
VS Code 1.111.0
What platform is your computer?
Darwin 25.3.0 arm64 arm
What issue are you seeing?
When I select text in the editor and ask Codex a question about that selection, it looks like Codex gets the raw selected text and maybe some general file/tab context, but not the exact file path plus line/column range for the selection.
That creates avoidable ambiguity whenever the selected text is short or duplicated. A concrete example: I highlighted a repeated function call in a JavaScript file and asked what "this" was doing. Codex could see the selected snippet, but not which occurrence I meant, so it answered about the wrong one until I pasted a larger chunk manually.
This feels like an IDE integration gap more than a model-quality issue. The extension already knows the active file and the exact selection range, so it should pass that through as structured context when a user asks about the current selection.
What steps can reproduce the bug?
- Open a file that contains repeated short snippets, like multiple
functioncalls in a JavaScript file. - Select one of those snippets in the editor.
- Ask Codex a question that depends on the exact location, like "should this call change?" or "what does this line do?"
- Notice that Codex can often see the selected text, but not the exact location you selected, so it may answer about a different matching snippet.
This is easy to reproduce with very short or repeated selections like 1, true, a repeated key, or a common function call.
What is the expected behavior?
If text is selected in the editor, Codex should receive the selection as structured editor context, not just raw text.
At minimum, that context should include:
- active file path
- start line and column
- end line and column
- selected text
- multi selections if user has multi selections
Even if the UI doesn't show those details directly, the model should have them so it can disambiguate "this line" / "this selection" questions and point back to the right location in its response.
Additional information
This is related to the general "selected editor context" UX, but it's not the same as asking for a new @-mention flow. Even with the current UX, including selection metadata would make Codex much more reliable when the selected text is short or repeated.
Related but different: issue #12413 asks for a keyboard-bindable command to insert the current selection as an @ mention. That issue also mentions the lack of line/range support, which is adjacent, but the request here is specifically about what metadata the IDE extension sends to Codex when the user is already asking about a selection.
For reference, I reproduced this on VS Code 1.111.0 with extension 26.311.21342 on Darwin 25.3.0 arm64 arm.