Skip to content
| Marketplace
Sign in
Visual Studio Code>Programming Languages>DebugAI: Root Cause AI Debugger That Reads Your CodebaseNew to Visual Studio Code? Get it now.
DebugAI: Root Cause AI Debugger That Reads Your Codebase

DebugAI: Root Cause AI Debugger That Reads Your Codebase

Mohi Uddin

|
615 installs
| (2) | Free
Reads your codebase, captures terminal errors, returns root cause + 3 ranked fixes in 8 seconds. Cross-file tracing. Diff preview. Python, JS, TS, React, Node.js.
Installation
Launch VS Code Quick Open (Ctrl+P), paste the following command, and press enter.
Copied to clipboard
More Info

DebugAI: AI Debugger That Reads Your Whole Codebase

Every tool can see your errors now. Only DebugAI knows your codebase.

VS Code Marketplace version Open VSX version

DebugAI finds the root cause of Python and JavaScript errors by reading your entire codebase, not just the line that crashed. It traces the error through your real imports and call chains, then returns a ranked fix with a diff you apply in one click. Root cause and 3 ranked fixes in about 8 seconds.

Works in VS Code, Cursor, Windsurf, and VSCodium. Also works as an MCP server for AI agents like Claude Code and Cursor agent mode.

VS Code Marketplace · Open VSX (Cursor, Windsurf, VSCodium) · debugai.io · Free tier, no credit card


What's new in 2.7.6

Debug in Browser could fail without telling you, and the panel could claim a bug was fixed while it was still happening. Both are gone.

  • A capture that saw nothing looked identical to a page with no errors. Debug in Browser attaches to a running page in two halves, the console and the network. The network half could fail to attach and say nothing at all, so the badge read "DebugAI watching" while every failed request went uncaptured. The one class of bug this feature exists for is the one that reaches no terminal, so a silent failure to watch for it is worse than not offering the feature. It now says so in three places: a warning when it happens, a line in the Output channel, and the status bar reading DebugAI watching (console only) for as long as it is true. The check re-arms while an attach is still in progress, so a slow connection is never mistaken for a broken one.
  • The buttons inside the page did nothing. The overlay's own Find and Hide buttons sent a shortened error signature back to the extension, which was holding the full one, so nothing ever matched and clicking did nothing at all, with no error anywhere. They work. Signatures are compared whole, and a shortened one is accepted only when it can identify exactly one capture.
  • Sessions that cannot be asked stopped being asked. Some debug sessions have no execution context and refuse every evaluate. The extension asked them anyway, on every heartbeat, forever, and VS Code logged each refusal. A session that refuses three times is retired for the rest of the run. Timeouts do not count, because a slow answer is not a refusal.
  • "Fixed before" could be a lie. The panel showed that badge whenever a fix had ever been applied for an error, and nothing could take it back. Apply a fix that hides a crash rather than repairing it and the error keeps happening while the badge keeps saying it was fixed. The panel now tracks whether the error came back: it reads A previous fix didn't hold when it did, and reserves "Fixed before" for a fix nothing has contradicted. The analysis behind it is told the same thing, so it stops re-proposing a fix that has already failed.
  • Applying a fix could still write to the wrong line. An import fix whose line number was never checked could overwrite a different import. That edit is refused now unless the line it names imports the same module, and fixes carry line numbers in one coordinate system instead of three.

Previously in 2.7.5 - six defects from running the fix-apply harness against DebugAI itself.

  • Applying a fix could put it in the wrong place. The extension used to trust a line number that came back with the fix, and it could not: nothing the engine shows the model is line-numbered, so the model counts by hand from a snippet, a retrieved file or a stack trace with no label saying which is line one. On one file in one afternoon it was wrong three different ways, each leaving a file that no longer parsed while the panel reported success. The extension no longer reads that number. It finds the fix's own first line in your file and follows the braces to the matching close, and refuses to write anything that would leave a block unclosed.
  • The results panel closed the moment a fix worked. Applying ran a command that closes whatever has focus, and clicking Apply focuses the panel. You lost the root cause, the other fixes and the feedback buttons exactly when something went right. It closes the diff now, by name.
  • With two results open, Apply could use the wrong one. The panel is built once and reused, and it was still resolving Apply against the first analysis you ran in it. Applying from the history sidebar had the same problem in reverse.
  • When DebugAI will not place a fix, it says why. It always had a reason and the panel always discarded it, so declining to touch your file looked the same as a button that did nothing.
  • The panel is readable on light themes. Two colours measured under the accessibility floor, including the border that is the only boundary on the warning box. Both derive from your theme's own foreground now, and contrast is checked on every build.
  • "Not verified" says what it means. Fixes are machine-checked for syntax and import errors and nothing else yet, so most are honestly unchecked. That is different from a check that ran out of time, and the badge now tells you which.

Previously in 2.7.4 - three things that were visibly wrong to somebody using the extension.

  • The status bar told every paying user "0 left". A monthly tier has no daily limit, so the API sends daily_limit: null on purpose. The badge read that null, fell back to a default of 5, and a Pro account with 12 sessions today saw "0 left" while the server was answering normally. A daily hard cap now counts down, a monthly soft cap shows 12/1000 with no countdown because there is no cliff to count down to, and a shape the badge does not recognise shows no number at all.
  • Locked commands no longer vanish. Debug in Browser and Show Browser Captures are gated on a per-account grant, and the behaviour without one had been wrong in both directions: first a raw "command not found", then hidden from the palette entirely. Both are always listed now, and running one without access explains what it is and offers a way in.
  • Request access opens a form instead of a mail client. The old prefilled mailto: does nothing on a machine with no mail client configured, which is common on work laptops. It opens debugai.io/beta now, where the request lands in a real queue.

Previously in 2.7.3 - a correctness release, every item from running DebugAI against DebugAI and writing down what it got wrong.

  • Applying a fix could write it into the wrong file. A JavaScript stack trace lists the innermost frame first, and the code walked it the other way, so the apply target was the caller rather than the function that actually threw. When a trace named no file at all, which is what a React key warning from inside react-dom looks like, there was no anchor and the write landed in whatever file was open. The extension now resolves the innermost frame that belongs to your project, and when it cannot place a fix with confidence it tells you and does nothing.
  • Debugging a failing test now sends real project context. pytest, jest, vitest and mocha each frame a failure differently, and the parsers handled a plain traceback but not a runner's. That meant no file paths, so no codebase retrieval, on the errors people hit most. All three parsers now agree against a corpus of fourteen real output shapes. Failing tests also group in Team Error Memory and get self-verification, which they did not before.
  • A successful apply is no longer reported as a failure. The write went through and the confirmation said it had not.
  • The overlay no longer hangs on an unanswered debug-adapter call. Every call is bounded, and the status bar names the one that stopped.

Previously in 2.7.0 - Sign in from the editor: run DebugAI: Sign In and the editor gets a short code, opens your browser, and stores the key itself. Works in Cursor, Windsurf and VSCodium, not just VS Code.

Previously in 2.6.0 - Verified badges + mechanical apply: every fix shows whether a mechanical check passed, failed, or never ran, and fixes carry exact old/new edits computed from your own code rather than regenerated text.

Previously in 2.5.0 - Proactive Scan: run DebugAI: Scan Workspace (Proactive) to catch bugs in your changed files before they throw. 20/20 planted bugs caught (12/12 cross-file) with 0 false positives in our 28-case benchmark.

Previously in 2.4.0 - Team Error Memory: "Seen before" and "Fixed before" badges when an error matches one your project already hit.

Full details in the changelog.


What DebugAI does

You hit an error. Instead of pasting it into a chat window and explaining your whole project, you press one shortcut. DebugAI already indexed your code, so it traces the error across files and hands you the fix.

  1. Reads the error from your terminal automatically
  2. Searches your locally indexed codebase for the files that matter
  3. Traces the failure across imports and call chains, not just the crash line
  4. Returns the root cause plus 3 ranked fixes with confidence scores and exact file:line
  5. Shows a diff preview before any change. You approve every edit

Median time from error to fix: about 8 seconds.


Get started in 60 seconds

1. Install the extension
   VS Code: VS Code Marketplace
   Cursor, Windsurf, VSCodium: Open VSX, or search "DebugAI" in the
   extensions panel
2. Ctrl+Shift+P, "DebugAI: Sign In"
   Your browser opens, you confirm a short code, the editor stores the key.
   Nothing to copy or paste. Free account, 10 debugs a day, no card.
   (Already have a dbg_ key? "DebugAI: Set API Key" still takes it.)
3. Ctrl+Shift+P, "DebugAI: Index Entire Workspace"
   One time, about 2 min. Free tier indexes up to 200 files.
4. Hit any error, Ctrl+Shift+P, "DebugAI: Analyze Terminal Error", done

Step by step for your exact editor: debugai.io/start

Free tier: 10 debug sessions per day, no credit card.


Use DebugAI from AI agents (MCP server)

DebugAI ships an embedded Model Context Protocol (MCP) server. Any MCP aware agent can call DebugAI directly to debug errors across your codebase.

  • Claude Code, Cursor agent mode, Windsurf, and other MCP clients can call the debug_error tool
  • The agent sends an error or stack trace, DebugAI returns root cause plus ranked fixes with exact old/new string edits it can apply directly
  • The server registers automatically in VS Code 1.101.0 and later, and reuses the key you already signed in with
  • After applying a fix, the agent calls report_outcome to tell DebugAI whether it worked. Confirmed fixes join the same team error memory that editor users build
  • Responses are agent aware: when you hit your daily quota the tool tells the agent to stop retrying instead of looping

Your coding agent gets a debugging specialist rather than a generic guess. The agent reads the structured fix, applies the patch, reports back, and reruns your code.

No extra install. Sign in once in the extension and the MCP server is live.

Not in VS Code? The same server ships standalone as @debugai/mcp on npm, for Claude Desktop, Zed, Gemini CLI, Cline, and any other MCP client. One command signs you in and writes the config for every client it finds:

npx -y @debugai/mcp setup

Why codebase indexing beats paste and pray

Standard AI debugging: error, copy, paste into chat, explain your stack, get a generic answer, adapt it by hand, try again, repeat.

DebugAI: error, Ctrl+Shift+P, "DebugAI: Analyze Terminal Error", fix.

When the AI already read your project, it traces a NoneType error back to the function that returned None three files upstream, without you explaining anything. That is what real codebase context gives you, and it is why DebugAI catches cross-file bugs that paste based tools miss.


Proactive Scan, for bugs that have not thrown yet

Debugging is reactive: something crashes, then you fix it. Proactive Scan flips that around. It reviews your changed code for latent bugs before they ever throw.

Run DebugAI: Scan Workspace (Proactive) from the Command Palette. DebugAI:

  1. Collects the files you changed on your current git branch (falls back to the active file if your working tree is clean), up to 10 files per scan
  2. Auto-indexes them, then pulls the semantic neighbors from your project index, so it reviews each file with the rest of your codebase in context rather than in isolation
  3. Returns ranked findings, each with a severity, an explanation, the exact file:line, and a suggested fix you preview and apply with the same one-click diff as debug

Because it reads cross-file context, Scan catches defects a single-file linter cannot see: a function called with the wrong arguments defined in another module, a return-shape mismatch between two files, a config value that causes a divide-by-zero two files away, an interface a caller quietly violates.

It is tuned to stay quiet on correct code. A scan that cries wolf is worse than one that says nothing. In our reproducible benchmark of 28 original test cases (written from scratch, not pulled from public repos), Proactive Scan detected 20 / 20 planted bugs, including 12 / 12 cross-file bugs, with 0 false positives on 8 clean-code controls. The corpus and runner ship in the repo under scripts/scan/benchmark/, so the number is reproducible rather than a marketing claim. No competing tool was run against this corpus, and we say so rather than let the number imply a comparison that does not exist.

Scan limits by tier

Tier Scans per day Files per scan
Free 1 (teaser) 1
Pro 20 10
Team 50 10

Errors DebugAI handles

  • Python AttributeError, including 'NoneType' object has no attribute
  • Python TypeError, wrong argument types, None passed where an object was expected
  • Python NameError, ImportError, ModuleNotFoundError, KeyError, IndexError
  • JavaScript and TypeScript TypeError: Cannot read properties of undefined
  • React hooks errors, stale closures, infinite render loops, missing dependencies
  • Runtime exceptions and tracebacks that span multiple files

How to run DebugAI

Open the Command Palette (Ctrl+Shift+P or Cmd+Shift+P) and type DebugAI to see every command. That is the only way to run it, deliberately.

DebugAI ships no default keybinding. Ctrl+Shift+D is VS Code's own Run and Debug view, and an extension that shadows it breaks a core editor feature. If you want a shortcut, bind one yourself in Preferences: Open Keyboard Shortcuts, search debugai, and pick a key that is free on your setup.

Commands

Command What it does
DebugAI: Sign In Browser sign-in. No key to find or paste
DebugAI: Analyze Terminal Error Auto captures the last terminal error
DebugAI: Analyze Error Paste any error from any source
DebugAI: Index Entire Workspace Index your codebase for cross file context (run once)
DebugAI: Index Current File Index a single file
DebugAI: Scan Workspace (Proactive) Scan your changed files for latent bugs before they throw, with cross-file context
DebugAI: Check Index Status See what is indexed
DebugAI: Try Demo Analysis See DebugAI work without a real error
DebugAI: Open Dashboard Open your dashboard on debugai.io
DebugAI: Set API Key Enter an existing dbg_ key by hand
DebugAI: Clear API Key Remove your stored key

Supported languages and frameworks

Python: FastAPI, Django, Flask, Celery, SQLAlchemy, Streamlit, PyTorch, TensorFlow, Pandas, NumPy

JavaScript and TypeScript: React, Next.js, Node.js, Express, Vue, Svelte, Vite, tRPC

Framework detection is automatic. No config files needed.


Your code and your privacy

  • During indexing: file content is sent over HTTPS, chunked, turned into embeddings by Voyage AI, and stored as a project index on DebugAI servers. Full source files are not stored as is, only semantic chunks for retrieval.
  • During debugging: the error message, a small relevant code snippet of about 800 bytes, and recent git change metadata (file names only, never contents or diffs).
  • When idle: nothing. No background scanning, no telemetry on your code.

API keys are stored in VS Code SecretStorage, never in plaintext settings files. Signing in through the browser never puts the key on your clipboard or in a settings file at any point.

Privacy policy


Pricing

Tier Price What you get
Free $0 10 debug sessions per day, single-file root cause, Claude Haiku 4.5, codebase index up to 200 files, MCP server. Works in VS Code, Cursor, Windsurf, and VSCodium.
Pro $12 per month Cross-file root cause, 3 ranked fixes with confidence scores, Claude Sonnet 4.6, unlimited sessions (soft cap 1,000/mo), unlimited codebase indexing, full session history. Includes a 14-day Pro trial, no card.
Team $18 per seat / month Everything in Pro, plus Team Error Memory (beta). Contact sales, self-serve checkout is not live yet.

Monthly prices shown. Full feature breakdown and annual options live at debugai.io/pricing.

Founding rate, closing soon: lock Pro at $9 per month for life if you upgrade before September 1, 2026. Claim it.


Frequently Asked Questions

What is DebugAI? DebugAI is a VS Code extension and MCP server that finds the root cause of code errors by reading your whole codebase, then returns ranked fixes with a diff you apply in one click.

How do I set it up? Install it, then run DebugAI: Sign In from the Command Palette. Your browser opens, you confirm a short code, and the editor stores the key. There is no key to locate, copy, or paste.

How does DebugAI debug errors across multiple files? It indexes your project locally first. When an error happens, it searches that index, traces the failure through your imports and call chains, and reads the files that actually caused the error, not just the crash line.

Does DebugAI read my entire codebase without asking? No. You run DebugAI: Index Entire Workspace yourself. Only files in your workspace are indexed, and only on your command.

What AI model powers DebugAI? Claude Haiku 4.5 handles analysis. Complex cross-file errors on paid tiers route to Claude Sonnet 4.6. If Claude is ever unavailable, DebugAI falls back automatically to GPT-4o-mini. The response format is identical either way.

Can I use DebugAI with Claude Code or other AI agents? Yes. DebugAI includes an MCP server that exposes debug_error and report_outcome. Any MCP aware agent can call it. Sign in once in the extension and it works automatically in VS Code 1.101.0 and later. Outside VS Code, npx -y @debugai/mcp setup wires up every MCP client on the machine.

Does it conflict with GitHub Copilot? No. DebugAI only runs when you invoke a command. It does not interfere with Copilot, Copilot Chat, or any other extension. It is the debugging companion to your existing AI stack.

Does it work in Cursor, Windsurf, or VSCodium? Yes. DebugAI is a standard VS Code extension, so it runs in any VS Code compatible editor. Install it from Open VSX, and browser sign-in works the same way it does in VS Code.

Does it work offline? No. Indexing and analysis both need a connection to the DebugAI API.

How many free debug sessions do I get? 10 per day, free forever. Need more, upgrade to Pro from debugai.io/pricing.


debugai.io · support@debugai.io · Privacy · Terms

Publishing

Both registries take the version from package.json, so bump that first and let the scripts name the file:

npm run vsce:package     # writes debugai-<version>.vsix
npm run publish:vsce     # VS Code Marketplace
npm run publish:ovsx     # Open VSX

Never ovsx publish *.vsix. This folder keeps every build ever made, the glob expands alphabetically, and on 2026-08-17 that published 1.3.2 instead of 2.7.5. Open VSX orders by semver rather than publish time so nobody was downgraded, but the release simply did not go out. The scripts above pin the filename to $npm_package_version so the glob is never involved.

ovsx is a devDependency, so npm run publish:ovsx resolves it from node_modules/.bin and never depends on a global install. It was not, and on 2026-08-21 the Open VSX half of the 2.7.6 release failed with sh: 1: ovsx: not found after VS Code had already gone out — leaving the two registries on different versions until somebody noticed. vsce is still expected globally, which is the same trap waiting; install it locally too if it ever bites.

Open VSX needs a token: OVSX_PAT in the environment, or -p <token> on the command. Publishing to one registry and not the other is the failure worth checking for afterwards — compare both:

curl -s https://open-vsx.org/api/debugai/debugai | grep -o '"version":"[^"]*"'
  • Contact us
  • Jobs
  • Privacy
  • Manage cookies
  • Terms of use
  • Trademarks
© 2026 Microsoft