VS Code: removing IDE Context persists, but UI provides no discoverable way to re-enable it

Open 💬 0 comments Opened Aug 26, 2026 by justingrant

What variant of Codex are you using?

VS Code IDE extension

Extension version

26.820.60940

Issue

The IDE context chip in the Codex composer has an X. Clicking the X appears to disable IDE Context persistently, rather than merely removing it from the current prompt/thread.

After doing this, there is no discoverable way in the normal composer UI to turn IDE Context back on. In particular, the + menu does not contain an IDE Context option, and the extension settings UI does not expose an obvious control for it.

The feature can be restored by typing /ide in the composer and selecting IDE context — Include current selection, open files, and other context, but this recovery path is effectively hidden unless the user already knows the slash command exists.

This caused the extension to silently stop sending the current editor selection and active file. It initially looked like the IDE-context feature was broken: with text visibly selected in VS Code, asking Codex what was selected returned that both selected text and the currently viewed file were unavailable. After /ide was used to re-enable IDE Context, automatic editor context worked again.

Steps to reproduce

  1. Start with IDE Context enabled in the VS Code Codex composer.
  2. Click the X on the IDE Context chip.
  3. Send prompts and/or start another conversation.
  4. Observe that IDE Context remains disabled; active file and selected text are no longer automatically included.
  5. Open the composer + menu and extension settings and try to find a way to restore IDE Context.
  6. Type /ide and select IDE context.
  7. Observe that IDE Context is restored and active-file/selection context works again.

Expected behavior

At least one of the following would make the behavior clear and recoverable:

  • Clicking X should remove IDE Context only for the current prompt, if that is what an X normally implies; or
  • If clicking X intentionally disables the feature persistently, the UI should make that clear and provide a visible way to re-enable it (for example in the + menu and/or Codex settings); or
  • The removal action could offer an immediate Undo / explanation that IDE Context has been disabled and can be restored with /ide.

A persistent preference change should not be represented solely as dismissing a chip when the inverse action is hidden behind an undiscoverable slash command.

Actual behavior

Clicking X silently creates a persistent disabled state. The normal UI provides no apparent inverse control, making it easy to conclude that automatic IDE context is malfunctioning or has been removed.

View original on GitHub ↗