Changelog

The toast after you connect now leads with Analyze an error

It used to offer one button: Index Workspace Now. Reading production on August 27 we found 154 indexed projects across roughly 30 accounts, and 117 of them belonged to people who have never run a single debug. They installed, signed in, pressed the one button on offer, waited through an index of their entire workspace, and had nothing to show for it. Indexing is setup. It costs minutes and shows you nothing, and what it improves is an answer you have not seen yet, which is a poor trade to ask of somebody in their first thirty seconds. Index workspace is still there, second. VS Code makes the first button the primary one, so the order is the message.

A missing Python package and a mistyped import raised the same error, and got the same answer

Somebody pasted a traceback whose failing line read "import Flask, jsonify, request, render_template, re". DebugAI answered "Package not installed. Run: pip install Flask" at high confidence, in 63 milliseconds. Their agent then told us, through the outcome channel, that flask was already installed in the project virtual environment and the real bug was the import form: a bare "import Flask" asks Python for a module by that name, and there is none, because Flask is a class you import from flask. The install advice was worse than useless there. "pip install Flask" succeeds, against an unrelated deprecated package, the import keeps failing, and the person now has a polluted environment plus the original bug. The interpreter genuinely cannot tell these two apart, because by the time it raises there is only a name it could not resolve. The traceback can, because it prints the offending line. DebugAI now reads that line, and when the failing name is one a package exports rather than a package anyone can install, it says so and tells you to check with pip show before installing anything. It reports how sure it is, separately, because the ordinary install answer is right most of the time and this only overrides it on evidence actually printed in the traceback.

The Unreal errors that are about the build, not the game

A large share of what Unreal developers paste is not a crash in their code. It is the modules dialog that appears when a project was built against a different engine version, a linker error naming a missing Build.cs dependency, or a packaging step that failed forty minutes in. Those have known answers that do not need a model to produce, and the community answers most of them wrong: the standard advice is to delete the Saved, Intermediate and Binaries folders, which destroys the crash logs that were the only evidence anyone had. DebugAI answers them from a fact library instead, in milliseconds, and it knows which folder holds the log you are about to need.

A program that dies natively reports a code, not a sentence

Triage was built to read error text, so a process that exits with a status and no message read as nothing worth analysing. That is most of what a failing build actually produces. Those exits now carry their code through triage rather than being dropped at the door.

Right-click, or Ctrl+Alt+D

The analyze command existed since the first release and was reachable exactly one way: open the command palette and type its name from memory. A palette command has to be remembered, which mostly means it is not. Reading the logs, the people who had never run a single debug were not uninterested. Most of them never found the command. It now sits in the editor context menu, in the terminal context menu where the error usually printed, and on a keybinding.

"Open a code file first" is gone

Running the analyzer with no editor open used to refuse outright. That is exactly the state you are in when an error has just printed in your terminal and there is nothing to select. The paste box that handles this case was already written. A guard three lines earlier stopped anyone from reaching it.

The bundled MCP server sends the project

The npm build has passed project_id since 2.2.0. The copy VS Code auto-registers never did, so the one path that needs no setup at all was the one path where Team Error Memory could not remember anything, silently. It now reads the workspace folder the editor already knows rather than guessing from a working directory, and re-registers when you switch folders.

An agent can say a fix went unused

report_outcome used to accept only "worked" or "failed". An agent that read the answer, disagreed with it, and fixed the bug its own way had nothing honest to report, so that outcome landed as a failure or as nothing. Those are opposite facts and merging them poisons the record. It now takes "unused", plus the fix that actually worked and a free-text note on what DebugAI should have said instead.

A notification was being handed the whole dashboard panel, flattened

The server took an announcement body plus every bullet, joined them with middots, and cut the result at 400 characters. On the web that content is a panel with a headline, paragraphs and a numbered rail. In the corner of an editor it was a wall of fragments sitting over the code you were reading. No shorter cut was going to fix that, because a notification is not a compressed panel. It is a different job: say enough to decide, offer the buttons, stop. The short line is written by hand now rather than derived, capped at 140 characters, and nothing re-derives it. An announcement with no editor line shows its headline and nothing else, which is a perfectly good notification.

Learn more, when there is genuinely more

The notification grows a third button that opens the full announcement in an editor tab, in your own colour theme, with the text, the bullets and the screenshot. That is what makes the short line affordable: the detail moved, it was not deleted. Reading is not deciding, so Learn more records nothing and does not dismiss the notice. Only acting on it does. The detail is fetched when you click and never on the background check, so an announcement carrying a screenshot costs nothing to anyone who never opens it.

DebugAI wrote a confident fix for the letter "c"

Somebody pasted a single character. DebugAI returned a root cause and a fix, at high confidence. Somebody else pasted the line their terminal prints before you type anything, twice in one session, and got a diagnosis both times. Neither of them came back. We found this by reading the raw table of what people had actually pasted, which is not the same thing as reading the reviews, and it is the most useful hour we have spent on this product. Most of what arrived was not an error at all: shell prompts, a file path with the message left behind, source code with nothing wrong printed next to it, and in one case a DebugAI answer pasted back into DebugAI. The tool answered all of it, because nothing in it had ever asked whether the input was an error in the first place.

It now says what to paste instead of guessing

A check runs before any retrieval, any cache lookup and any model call. When the text carries no error signal, DebugAI names what it got and what to do instead: that a terminal prompt is what your shell prints before you type, and the useful part is the output that came after the command. Refusals are zero confidence with no code attached, because the damage was never the wrong answer on its own. It was the certainty. A tool whose entire claim is that it tells you what it actually checked cannot afford to sound sure about a prompt line. The check is deliberately lopsided: any error signal anywhere in the text, or in the code you sent with it, and the normal analysis runs regardless of what the rest looks like. Refusing a real error is far worse than analysing one more prompt, so it errs toward letting things through.

PowerShell, MSBuild and .NET errors were being read as nothing in particular

The framework detector knew Python web frameworks, Python machine learning, and the JavaScript and TypeScript ecosystem. It was built for the people we imagined. A large share of real errors matched none of it, and reading them showed why: they were PowerShell cmdlet failures, MSBuild packaging errors and .NET desktop stack traces. Those are detected now, and detection was shipped together with the expert knowledge that makes it worth anything, because a label nobody acts on is not a feature. DebugAI now knows that PowerShell errors do not stop a script by default, so the output you pasted often ends far below the real cause and the first error is the one that matters. It knows that "Cannot bind argument to parameter because it is null" means the previous command returned nothing, so the bug is one line above the line that threw. It knows an MSBuild code prefix names which tool failed, that those have different fixes, and that the last line of a build log is usually a consequence rather than a cause.

A fix confirmed before this week could never be un-confirmed

Last week DebugAI learned to demote a fix whose error keeps coming back: tried twice, still failing, so stop recommending it. Every fix stored before that change was exempt from it, and not by choice. Those rows read as confirmed and had no field the new logic could ever move, so they would have been recommended forever no matter how many times the error returned. That is the exact failure the demotion work existed to end, still running underneath it. Every stored fix is now enrolled, and a fix that does not hold is demoted on its own with nobody watching.

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 report 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, which makes a silent failure to watch for it 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 stays 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 draws its own Find and Hide buttons into the page you are debugging. They sent a shortened error signature back to the extension, which was holding the full one, so nothing ever matched: clicking did nothing at all and nothing was logged anywhere. Each half was valid on its own, which is why it survived a protocol check that never compared the two lengths. Signatures are compared whole now, 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 request. The extension asked them anyway, on every heartbeat, for the life of the session, and VS Code logged each refusal. A session that refuses three times is now retired for the rest of the run. A timeout does not count as a refusal, because a slow answer is not a no.

"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 instead of repairing it, and the error keeps happening while the badge keeps saying it was fixed. Worse, that fix was fed to every later analysis as the leading hypothesis, so the wrong answer reinforced itself every time somebody accepted it again. The system now tracks whether the error came back after a fix was applied. Twice is a pattern, and the fix is inverted: the analysis is told it was tried and did not work, and told not to propose it again. The badge reads "A previous fix didn't hold", and "Fixed before" is reserved for a fix nothing has contradicted.

A fix now has to go where the diagnosis points

DebugAI could correctly name a cause upstream and then rank a patch at the line that threw, which stops the exception and leaves the bug in place, turning a loud failure into a silent one. Nothing in the system had ever connected the two. The rank-1 fix must now edit the location its own root cause names, or say in one clause why it cannot. Confidence scoring stopped rewarding proximity: the line that throws is visible in almost every request, so a symptom patch used to score 95 by construction. Defensive code is still ranked first when the bad value is legitimate rather than a mistake, which is measured separately so the correction could not overshoot into refusing all guards.

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. Underneath it was something simpler and older: the code DebugAI shows the model is often a window from the middle of your file, and nothing in the request had ever said where the window began, so the model had been inferring the offset from a stack trace since the feature shipped. It now receives the real line numbers instead of computing them.

Applying a fix could put it in the wrong place

The extension used to trust a line number that came back with the fix. 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, and there is no label saying which one is line one. On a single file in a single afternoon it was wrong three different ways, and each one left a file that no longer parsed while the panel said the fix had been applied. The extension no longer reads that number. It finds the fix's own first line in your file and, when that line opens a block, follows the braces to the matching close. That is what a person does, and it does not care what the line number said. Two checks sit behind it, and both refuse to write rather than guess.

The results panel closed the moment a fix worked

Applying a fix ran a command that closes whatever has focus, and clicking Apply puts focus on the panel, so the panel is what closed. You lost the root cause, the other ranked fixes and the thumbs buttons at the exact moment something went right, and the only way back was to analyse something else you did not need analysed. It closes the diff now, by name, and leaves everything else alone.

With two results open, Apply could use the wrong one

The panel is built once and reused for every later analysis, and it was still resolving Apply against the first analysis you ran in it. Click Apply on the second result and the first result's fix is what landed, in the first result's file. Applying from an older entry in the history sidebar had the same problem in reverse. Both now use the result you are actually looking at.

When DebugAI will not place a fix, it says why

It has always had a reason and the panel has always thrown it away, so declining to touch your file looked exactly like a button that did nothing. Six different refusals were invisible, including the one that stops a fix landing in a file it has no business in. They are all visible now, in the panel, with what to do instead.

The panel is readable on light themes

The border on the warning and undo boxes measured 2.81:1 against the surface behind it, under the 3:1 floor, and on those boxes it is the only thing separating them from the background. The Cancel label in the diff bar measured 4.29:1 as 12px text, under the 4.5:1 floor. Both now derive from your own theme's foreground rather than a fixed colour, so they hold in themes we have never seen, and contrast is measured on every build instead of by eye.

Not verified says what it means

DebugAI machine-checks fixes for syntax and import errors and nothing else yet, so most fixes are honestly unchecked rather than checked and passed. That is a different thing from a check that started and ran out of time, and both used to read the same. The badge now tells you which one you are looking at.

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. The three cases are now genuinely different: a daily hard cap 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. Inventing a limit is what caused this, so it no longer invents one.

Locked commands stopped vanishing from the palette

Debug in Browser and Show Browser Captures are gated on a per-account grant, and the behaviour for everyone without one had been wrong in both directions: first a raw "command not found", then hidden from the palette entirely. Hiding it is the worse of the two, because a feature nobody can see is a feature nobody can ask for, and a closed beta that recruits nobody produces no feedback. Both commands 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

It used to open a prefilled mailto:, which does nothing at all on a machine with no mail client configured, common on work laptops, and arrived mangled or empty often enough that a good share of requests said nothing useful. It opens debugai.io/beta now, where the request lands in a real queue and gets answered.

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 threw. When a trace named no file at all, which is what a React key warning raised from inside react-dom looks like, there was no anchor and the write landed in whatever file happened to be open. In one of our own sessions that meant appending a JSX snippet to the bottom of index.html. Twice. DebugAI now resolves the innermost frame that belongs to your project, and when it cannot place a fix with confidence it says so and does nothing instead of guessing.

Debugging a failing test finally sends real project context

pytest, jest, vitest and mocha each frame a failure differently, and all three places in the stack that parse error text handled a plain traceback but not a runner’s. The practical effect was 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. Two things follow: a failing test groups with other runs of the same failure in Team Error Memory, and self-verification runs on test-shaped errors where it used to bail out.

A successful apply is no longer reported as a failure

The write went through and the confirmation read the wrong result, so it told you it had not. Nothing was lost, but the message was wrong about the file on your disk.

The overlay no longer hangs on an unanswered debug-adapter call

Every call is bounded, and if one does not come back the status bar names the one that stopped rather than sitting there. Browser stack frames delivered from another OS, such as a Windows path arriving in a WSL or container workspace, now resolve too.

Renamed, and the keyword list nearly doubled

No code changed. The extension is now "DebugAI: Root Cause AI Debugger That Reads Your Codebase", and the keywords went from 16 entries to 29. This came out of measuring where the listing actually sits in Marketplace search, which had never been checked: #6 for "ai debugger" but #85 for "ai debugging", same listing and same keywords, so the name is what search matches on and near-literally. "VS Code" was the token spent to make room, since it is redundant on the VS Code Marketplace and wrong on Open VSX, where the readers are on Cursor, Windsurf and VSCodium.

Nothing to relearn

2.7.0 was built with a mistyped build variable, so it shipped a placeholder analytics key and reported no usage events. If you are on 2.7.0 everything works, we simply could not see which parts you use.

Sign in without finding, copying or pasting a key

Run DebugAI: Sign In. The editor gets a short code, opens your browser, and stores the key itself once you confirm. The code lands on your clipboard so you paste rather than retype it, and the wait is cancellable. Free account, 10 debugs a day, no card. Pasting a dbg_ key still works if you prefer it, or if the machine has no browser.

Every "no API key" dead end now signs you in instead

The first-run message, the error you get when analyzing without a key, and the setup nudge all used to send you to a web page to fetch a key by hand. They now sign you in where you already are.

One-click connect works in Cursor, Windsurf and VSCodium

The extension passes its own URI scheme when it opens the dashboard, so the connect link comes back as cursor://, windsurf:// or vscodium:// instead of always assuming vscode://. That link silently did nothing outside VS Code before, which covers every install that came from Open VSX.

The Ctrl+Shift+D keybinding is gone, for real this time

That chord is VS Code’s own Run and Debug view, and shadowing it broke a core editor feature. The 2.0.6 changelog said this was removed; the manifest still declared it, so it never actually was. Every command runs from the command palette, and you can bind your own shortcut in Preferences: Open Keyboard Shortcuts.

Every fix now shows its verification state, all three of them

"Verified" means a mechanical check passed (currently syntax and import resolution). "Failed check" means DebugAI disproved its own fix before you saw it, and capped the confidence hard. "Not verified" means the confidence number is the model’s own estimate, and nothing checked it. We label that third case instead of hiding it; hover the badge for exactly what was (or wasn’t) checked.

Mechanical apply

Fixes now carry exact old/new string edits derived server-side from your own code, not re-generated by the model. Apply uses them first (exact match, fail-closed) and falls back to the proven line-hint applier when they don’t match. Fewer mis-applied patches, same preview-diff-confirm flow.

One outcome pipeline

Fix feedback from the editor and from AI agents (via @debugai/mcp 2.0’s new report_outcome tool) now lands in the same place, so confirmed fixes strengthen your team’s error memory no matter who applied them.

New command, DebugAI: Scan Workspace (Proactive)

Reviews the files you changed on your git branch (or the active file if your tree is clean) for latent bugs before they crash. Auto-indexes them and pulls semantic neighbors from your project index, so each file is reviewed with cross-file context.

Cross-file detection

Catches defects a single-file linter can’t see: wrong arguments to a function defined in another module, return-shape and type mismatches across files, a config value that divides by zero elsewhere, interface violations on a caller.

Ranked findings with one-click fix

Each finding has a severity, explanation, exact file:line, and a suggested fix you preview and apply with the same diff flow as debug.

Tuned against false positives

Benchmarked on 28 original test cases: 20/20 detection (12/12 cross-file), 0 false positives on 8 clean-code controls.

"Seen before" and "Fixed before" badges

When an error matches one your project has hit before, the results panel flags it. If a confirmed fix for that exact error already exists, you get a "Fixed before" badge instead of "Seen before," so you know the answer is proven.

Feedback now feeds the memory

Applying, copying, or rating a fix links back to the originating debug session, so confirmed fixes are promoted into your team’s shared error memory and surface first the next time the same error shows up.

Results panel now matches your VS Code theme

The DebugAI panel uses VS Code's own theme colors, fonts, and codicons instead of a hardcoded dark design. Light themes, high-contrast modes, and custom themes all render natively.

Smarter, safer fixes from the engine

Fixes now target exact line ranges so applied patches land precisely where they should. Confidence scores are honestly calibrated: 90+ means the bug was verified in your actual code. When a large file is only partially analyzed, the engine automatically runs a second pass with the full content before answering.

Debug history on your dashboard

A new History tab on the dashboard lists every debug session: the error, language, framework, model used, confidence, whether the fix was applied, and how long the analysis took. Free plan shows the last 7 days; paid plans keep everything.

Terminal capture without touching your clipboard

Analyze Terminal Error now reads command output and exit codes directly through VS Code shell integration. The old clipboard method only remains as a fallback for shells without integration support.

Webview security and telemetry compliance

The results panel runs under a strict Content-Security-Policy with per-render script nonces. The extension now fully respects VS Code's global telemetry setting, including turning it off mid-session.

Model upgrade across all tiers

Analysis runs on Claude Haiku 4.5 across the board, with Claude Sonnet 4.6 handling complex cross-file errors on paid tiers.

DebugAI is now an MCP server

The extension exposes a debug_error tool over the Model Context Protocol. Claude Code, Cursor agent mode, and any MCP-aware agent can call DebugAI directly and get root cause plus ranked fixes across your codebase. Auto-registers in VS Code 1.101+ and uses your existing API key.

Agent-aware error handling

Quota and rate-limit responses now tell the calling agent whether retrying makes sense, so agents stop hammering the API once you hit your cap.

Connect VS Code with one click, no copy-paste

Your dashboard now has a "Connect VS Code" button in the Setup and Settings tabs. Click it: VS Code opens, your key is stored in encrypted SecretStorage, and the connection is verified automatically. No command palette, no pasting, no manual steps.

Secure URI auth handler in the extension

The extension registers a vscode://debugai.debugai/auth handler. Keys are validated for correct format and length, stored encrypted, and confirmed against the API before marking as connected.

Safe override when a key already exists

If you already have a key configured and click Connect VS Code from a different account, VS Code shows a confirmation dialog before replacing anything.

Manual key entry still works as fallback

Ctrl+Shift+P → "DebugAI: Set API Key" remains fully functional. If the URI flow does not work (VS Code not installed, browser policy), the copy method is shown immediately below the button.

Walkthrough no longer interrupts users who already have a key

The Getting Started walkthrough now only opens for new users without an API key. Existing users upgrading to a new version will no longer see the onboarding flow.

Step 1 walkthrough rewritten, no more false "indexing" message

The first walkthrough step previously claimed your codebase was being indexed before you had set a key. It now correctly explains the sign-in flow and what happens after your key is connected.

Demo panel now prompts you to get a key

After viewing the demo analysis, a "Debug your own code → Get free key at debugai.io" button appears so you can act on what you just saw without hunting for a sign-up link.

Status bar tooltip updated to Ctrl+Shift+P

Tooltip now reads "Ctrl+Shift+P → DebugAI: Analyze Error" across all status bar states, matching the actual command palette workflow.

Sign-up nudge delay extended to 90 seconds

The follow-up prompt after clicking "Get Free Key →" now waits 90 seconds instead of 30, giving you time to complete sign-up before being asked to paste your key.

"See Demo →" in install notification

New users can now try a live demo instantly from the install notification, no API key needed.

Follow-up prompt after sign-up

30 seconds after clicking "Get Free Key →", DebugAI reminds you to paste your key into VS Code.

Fixed Clerk webhook, welcome emails now send

The Next.js middleware was intercepting /api/webhooks/clerk before the route handler. Excluded from matcher, so user.created events now reach the handler and trigger Loops welcome email.

Install notification now links to sign-up

New users see "Get Free Key →" which opens the dashboard directly. No more dead-end prompt asking for a key you don't have yet.

Status bar guides new users

When no API key is set, the status bar shows "Get Free Key" and opens the dashboard on click.

Walkthrough re-shows on each version update

The Getting Started walkthrough now re-opens with every extension update so existing users see new features.

Fixed broken logo and dashboard links on setup page

The DebugAI logo and "Open Dashboard" button on debugai.io/start were broken. Both now navigate correctly.

Fixed keybinding conflict with VS Code debugger

The Ctrl+Shift+D shortcut conflicted with VS Code's built-in Run and Debug view. Removed: use Ctrl+Shift+P → DebugAI commands instead.

Smarter error routing

Simple errors like NameError and SyntaxError resolve in under 2 seconds. Complex cross-file errors get deeper analysis automatically.

Better root cause detection

Files mentioned in your stack trace are always analyzed, even when they are not semantically similar to the error message. Config files, session managers, and decorators are now found reliably.

Git-aware debugging

Recent file changes are included with every debug request. When a regression causes a bug, DebugAI surfaces it immediately.

Reliable during outages

Automatic retry with fallback means you get results even when the primary AI service has issues.

Guided first-run experience

A new walkthrough shows you how to use DebugAI before your first error.

Demo command

Try DebugAI without needing an error ready.