VS Code /ide shows IDE context enabled but sends no active file or selection

Resolved 💬 4 comments Opened Jul 25, 2026 by ralphwest1 Closed Aug 13, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the IDE extension are you using?

openai.chatgpt 26.721.41059

What subscription do you have?

ChatGPT Pro 5x

Which IDE are you using?

Visual Studio Code 1.130.0

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 25H2, build 26200.8875)

What issue are you seeing?

Selecting IDE context from the /ide menu adds the gray IDE context indicator to the VS Code Codex composer, but messages sent while that indicator is present contain no active filename, selected text, or open-file IDE context.

There is no visible error. A test message sent while VS Code showed 19 characters selected received the response that no IDE-attached filename or selected text was supplied.

The active temporary profile persisted "composer-auto-context-enabled": true, so the toggle is enabled; the failure occurs when collecting or injecting the IDE payload into the message.

What steps can reproduce the bug?

Feedback ID: 019f989d-64b5-77b0-ac59-180940968b7c

What is the expected behavior?

When IDE context is enabled, a message should include the active filename, current editor selection, open files, and other advertised IDE context. Codex should be able to report the selected file and text without searching the repository.

Additional information

Isolation and control results

Desktop ChatGPT/Codex app was fully closed and was not started after reboot.
Failure reproduces in an empty VS Code Temporary Profile with only the Codex extension installed and no custom settings.
Failure reproduces when the repository folder is opened directly, not through its .code-workspace file.
When opened through the previous .code-workspace, the IDE context indicator did not render and the persisted toggle remained false. When the folder was opened directly, the indicator rendered and the persisted toggle became true, but no IDE payload was sent.
Clicking the gray IDE context indicator removes/disables it; leaving it present when sending still produces no context.
The control command Add to Codex Thread successfully serialized a file and line reference: d:\repos\main\dt-site-svkt\app0\site0\package.json (line 7). This suggests the basic editor attachment bridge can communicate with Codex while automatic IDE-context injection fails.
Workspace is on a healthy Windows Dev Drive using ReFS (D:), but the explicit file/line attachment control succeeds from that drive.
Separate clean-profile test thread: codex://threads/019f98c6-ee77-77a3-8bd2-60b0e19268d3
Feedback upload ID: 019f989d-64b5-77b0-ac59-180940968b7c

No raw logs are manually attached; the feedback upload includes the current session logs.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

#34920

Powered by Codex Action

ralphwest1 · 1 month ago

I reviewed #34920. The missing active-file and selection payload is closely related and may share the RPC serialization failure described there.

I have not independently confirmed that exact exception, and this reproduction differs in one useful way: with extension 26.721.41059, the IDE Context indicator remains present and composer-auto-context-enabled remains true, but no IDE payload is attached.

The failure also reproduces after reboot in a clean VS Code Temporary Profile containing only the official extension. Meanwhile, Add to Codex Thread successfully attaches an explicit file and line reference.

I’m leaving #35333 open for maintainer triage because it documents the behavior on the current extension and is connected to feedback upload 019f989d-64b5-77b0-ac59-180940968b7c. If maintainers confirm the same root cause, I’m happy for it to be closed as a duplicate.

alexr-oai · 15 days ago

Hi, thanks for the report. This issue should be resolved in the Codex IDE extension as of:

Stable: 26.803.41515, released August 7, 2026.
Pre-release: 26.5727.51351, released August 2, 2026.

Please update the Codex IDE extension to one of these versions or a newer version; if the issue persists after updating, please comment with your extension version, editor, and operating system and we can investigate further.

tlbdk · 2 days ago

Regression report: this still reproduces on a substantially newer stable extension build.

Environment

Codex VS Code extension: 26.820.60940
Visual Studio Code: 1.134.0 (110a328ea54b42367b803ec53ee0bf52ef26b419)
macOS 26.5.2, build 25F84, arm64
Local workspace, not Remote SSH or WSL

Observed behavior

The active file and open-file context are not delivered automatically to a Codex thread.
Asking Codex which file is currently open results in no active-file reference being available to the agent.
Selecting text and running Add to Codex Thread works correctly, so explicit editor attachments are functional.
The extension was already updated before the current VS Code window started.

Relevant VS Code renderer error at window startup

Unable to create workbench contribution chat.contextContributions. [createInstance] _St depends on UNKNOWN service chatSessionRoutingProviderService.

Steps to reproduce

Open a local folder in VS Code.
Open a normal file-backed editor.
Open the Codex sidebar and start a thread without explicitly attaching the file.
Ask Codex to identify the active file.
Observe that no active-file or open-file context reached the agent.
Select text and run Add to Codex Thread as a control; the selected context is then received correctly.

Expected behavior
Open files, including the active file, should be supplied automatically as documented. Explicit Add to Codex Thread should not be required merely for Codex to know which file is open.

This appears to be a regression of the fix reported in 26.803.41515. Please reopen or advise whether a fresh regression issue would be preferred.