IDE Extension: gated VS Code debugger integration (inspect/control)
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 disabledinspect: read-only debugger inspection onlycontrol: 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
inspectmode, Codex can help analyze an already paused session but cannot launch or step - in
controlmode, 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, andcontrol - discovery of an existing launch configuration
- launching a Node debug session from that configuration
- stopping on entry / on a
debuggerstatement - 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_
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗