IDE Extension: gated VS Code debugger integration (inspect/control)

Resolved 💬 1 comment Opened Apr 9, 2026 by xangma Closed May 10, 2026

What variant of Codex are you using?

IDE Extension

What feature would you like to see?

I’d like to request optional VS Code debugger integration for the Codex IDE Extension.

The main idea is to let Codex inspect real runtime state during explicit debugging tasks by using the VS Code debugger APIs and the workspace’s existing launch configuration entries, while keeping the feature strongly gated and off by default.

Proposed behavior

Suggested setting:

  • chatgpt.debuggerRollout: "off" | "inspect" | "control"

Suggested semantics:

  • off: debugger integration disabled
  • inspect: read-only debugger inspection only
  • control: allow launch/control operations for explicit debugging tasks

Why this would help

Some problems are runtime problems rather than static code problems. Right now Codex can reason about source code, but it cannot directly start and inspect an already paused debug session in the IDE.

That means it cannot easily:

  • inspect paused sessions
  • read a stack trace
  • inspect scopes and variables
  • evaluate expressions in a paused frame
  • inspect breakpoints
  • use an existing VS Code launch configuration
  • step through code for explicit debugging tasks

This would be especially useful for:

  • logic bugs
  • unexpected runtime state
  • stepping through a repro with the user
  • debugging small sample workspaces directly inside VS Code

Suggested capability split

Read-only inspect mode:

  • list debug sessions
  • inspect current debugger state
  • wait for stop events
  • get stack traces
  • get scopes
  • get variables
  • evaluate expressions in the paused frame
  • read console output
  • list breakpoints

control mode:

  • list launch configurations
  • start from an existing launch configuration
  • stop
  • continue
  • pause
  • step over / step into / step out
  • add/remove breakpoints

Suggested guardrails

  • keep the feature off by default
  • only use debugger capabilities for explicit debugging or runtime-investigation tasks
  • prefer inspecting an already paused session before starting a new one

Consider:

  • only start from existing launch.json / launch configuration entries
  • do not have Codex create, edit, or rewrite launch.json

Expected UX

A reasonable behavior model would be:

  • in inspect mode, Codex can help analyze an already paused session but cannot launch or step
  • in control mode, Codex can use the existing VS Code debugger workflow when the task is clearly about debugging
  • if there is exactly one paused session, inspection should reuse it rather than starting another session

Additional information

I validated a local prototype privately against the VS Code extension host in a small sample workspace.

The validation covered:

  • rollout gating for off, inspect, and control
  • discovery of an existing launch configuration
  • launching a Node debug session from that configuration
  • stopping on entry / on a debugger statement
  • reading stack traces, scopes, variables, and expressions
  • stepping through code
  • listing, adding, and removing breakpoints
  • capturing console output with debugger noise filtered out

I’m not posting a raw patch because I’m not sure the packaged IDE extension code/build artifacts are under a public open-source source license, and I’d rather avoid posting a diff that may not be appropriate to publish.

If this is in scope, I’m happy to share a higher-level design outline and validation notes.

Additional information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗