ChromeDevTools / ChromeDevTools/chrome-devtools-mcp

Interactive debugging support

Open
#407 8 comments 12 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

collecting-feedback feature
Dominant language
TypeScript
Stars
52.3k
Forks
4.3k
Avg merge
2d 7h
Merged PRs (30d)
83

Description

Is your feature request related to a problem? Please describe.

FEEDBACK WANTED

1. Problem Statement

AI agents (like those in Gemini CLI, Cursor, etc.) are becoming very effective at static analysis—reading code, understanding logic, and proposing changes.

Currently, an AI's only method for runtime debugging is to:

  1. Read the source code and form a hypothesis.
  2. Add console.log statements.
  3. Run the app and read the console output.
  4. Remove the console.log statements.

This "printf debugging" workflow is slow, intrusive (can create "heisenbugs"), and token-inefficient. Most importantly, it fails to solve entire classes of complex bugs related to application state, silent errors, or race conditions.


2. Problems We Want to Solve

We believe there are three main categories of problems that AI agents currently cannot solve. We would like to know which of these are the most painful.

Problem 1: Non-Intrusive Inspection (The "Logpoint" Problem)
An agent needs to verify a hypothesis by inspecting a variable's value at a specific line of code without modifying the source files.

  • Goal: "I need to know the value of movie.id on MovieCard.vue:129 when the user clicks the button."

Problem 2: Discovering "Unknown Unknowns" (The "Event-Breakpoint" Problem)
An agent needs to find the unknown line of code that is responsible for a known runtime event.

  • Goal (Exceptions): "A silent try...catch is hiding an error. I need to find the exact line that threw the error and inspect the local variables at that moment, before the call stack is lost."
  • Goal (DOM): "Something is adding a disabled attribute to my button, but I don't know what. I need to find the exact line of JavaScript that modified the DOM, even if it's hidden inside a framework's rendering logic."
  • Goal (Events): "A generic click listener is firing by mistake. I need to find which listener is the culprit."

Problem 3: Deep Forensic Analysis (The "Breakpoint" Problem)
When a hypothesis is wrong, an agent needs to do a full "forensic" analysis.

  • Goal: "My hypothesis was wrong. I need to pause execution on a specific line, inspect the entire call stack and all local variables (scope), and then step forward to understand the application's flow."

Foundational Requirement: All these problems must be solved in the context of the authored source code (e.g., .ts, .vue), not the bundled/minified output. Any solution must handle source maps transparently.


3. Key Use Cases (As Problems)
  • As an... AI agent debugging a silent try...catch error, I want to know what the local variables were at the moment the error was thrown, before the stack is unwound.
  • As an... AI agent debugging a UI bug, I want to find the exact line of JavaScript that is incorrectly adding the disabled attribute to my button, even if it's hidden inside a framework's rendering logic.
  • As an... AI agent debugging a complex bug, I want to pause execution on a specific line, inspect the entire call stack and all local variables, and then step forward to understand the application's flow.
  • As an... AI agent, I want to confirm my hypothesis that movie.id is undefined by logging its value on a specific line, without having to modify the file.

4. Feedback Requested

We are posting this to validate our assumptions before designing a solution. We would love to know:

  • Does this capability (runtime debugging for AI) seem useful to you?
    • (Please add a 👍 reaction to this issue if you would find this useful!)
  • Which of the problems described above is the most painful or high-value for you?
    • (Please help us rank them! e.g., "1. Problem 2 (Exceptions), 2. Problem 1 (Logpoints), 3. Problem 3 (Stepping)")
  • What is your "80/20"?
    • (Our research suggests "non-intrusive logging" (Problem 1) would be the 80% use case. Do you agree? Or is full interactive pausing (Problem 3) more critical?)
  • How do you currently work around these limitations?
    • (Are you manually adding console.log statements? Or do you take over from the AI and use DevTools yourself?)
  • What did we miss?
    • (Are there other runtime debugging scenarios or problems that your AI agent faces?)
Describe the solution you'd like

s/o

Describe alternatives you've considered

s/o

Additional context

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No file, test, or implementation entry point is named. Start by reviewing the existing TypeScript MCP capabilities and determining which requested scenario—logpoints, exception or DOM event breakpoints, or interactive stepping—can be scoped first; done should include an agreed design for authored-source debugging and source-map handling.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.