Changelog

lookup_error asks the project before anything else

A new MCP tool, in the extension and in @debugai/mcp 2.6.0. It answers from your project's memory in under a second, with no model call and nothing counted against your daily limit: whether the error was seen here before, how often, the fix that held, and fixes this project recently reported as failed. An agent that spent a week with DebugAI skipped it on five errors because a full analysis felt slower than fixing them itself, and every skipped error is one memory never learns. Agents are now told to call it first. In Claude Code, a hook can call it on every failed command, so it does not depend on the agent remembering.

The fix is aimed at the check you will run

debug_error takes the command that reproduces the failure and what it should print once fixed. Fix #1 is aimed at making that command pass, and each fix's check becomes that command instead of a syntax check, which is what every answer in that week offered for bugs no syntax check could see. DebugAI never runs the command; your agent does, in its own shell.

Outcomes can say what actually happened

A fix that worked only after the agent changed it is reported with the code that held, and that code is what the project remembers. The fix that worked is remembered whichever rank it was. A fix reported as failed is shown to the next analyses in the project for a week as one not to repeat, and if an answer brings it back anyway it is capped at 60% and says so.

Every answer says where it was filed and which build wrote it

An agent was started in one folder and worked in another all week, so every error was filed under the wrong project and memory never matched. The agent can now name the repository, and every answer ends with the project, whether memory was on, the MCP server's version and the engine build. A server older than the newest release is told so once a day, and the installer now writes a config that always starts the newest one.

Seven more shapes count as an error

A month of turned-away pastes was read one by one instead of counted. A game server console that "Couldn't find" its resources was refused twice in a minute, while "could not find" had been accepted for weeks - the contraction was the whole difference. A process that exits 1 without printing the word "code" was refused. So was a bug stated the way people state this kind: it works under one runner and fails under the other. So was a paste of VS Code's own Problems panel. All seven now go through, in the editor and the engine alike.

An offline build is answered with what it already has

One project ran Gradle with no network. Its own error said "No cached version of constraintlayout 2.1.4 available for offline mode" - and three minutes later, on a different failure, DebugAI recommended 2.1.4. The developer restored the version that was cached and filed ours as failed. A build that says it cannot download is now told apart from one that can, and the answer stays inside what is on disk, with the one command that lists it.

"Could not open file" has three causes, and now they all get named

A YARA compiler said it could not open the file it was meant to write. We said the directory was missing; it existed. The real cause was argument order - that build takes the source first and the output last, so it was trying to READ its own output. The message cannot tell those apart, so DebugAI now names all three causes and leads with the two commands that separate them instead of picking the likeliest.

Half a PowerShell error is answered as half a PowerShell error

PowerShell prints the message first and the identifiers last, so a paste that keeps the end of the terminal keeps "ErrorId : CommandNotFoundException" and loses the sentence naming what failed. Nine times in a month, across four accounts, that arrived here and got a paragraph saying it could not tell which command - and three times it was answered as a TypeScript error, because MissingEndParenthesisInMethodCall reads like one. DebugAI now says what was pasted, gives the one command that prints the whole record, and reads what the identifier already tells it, including the cmdlet name it carries.

A fix that names a method in somebody else's library says what it does not know

One .NET project went round four build errors in about a minute, each one produced by applying the fix for the last, every answer at 92%. DebugAI cannot see inside an installed package, so the replacement method was a guess wearing a high number. Answers to "this member does not exist" are now capped at 75% and name the one command that lists what the installed version really has - unless the fix simply removes the call, which is the answer that worked that day and is checkable from your own code.

Errors whose fix is outside your code start from the right check

Eight shapes from production were answered from nothing, and the model reached for the most familiar cause each time: a client race for a Firestore denial whose rules were deployed to another database, a stale client for a Stripe key that was simply wrong, a new Dockerfile when one existed but was never committed, dotenv for credentials that were placeholders. Each now starts from the check that tells its causes apart.

A scratch script is not your project, and several failures are ranked

An error from a throwaway script in a temp folder was blamed on the project's own build files. The path says where the script lives, and now the answer does too. A console pasted whole with a 401, a TypeError and two 422s was explained from the first line printed; the failures are now listed and the one that blocked what you were doing is chosen before any is explained.

Edits that cannot do what they say are not handed over

A rewritten Python function replaced only its first line and left the old body under the new return. A fix already present in your code was shown at 92% as the missing piece. A Python edit that would stop a file that parsed from parsing is refused before an agent can apply it blind. And a parameter placed where the API ignores it, like think inside Ollama's options, is checked against Ollama's own source rather than recalled.

Memory reaches cached answers, and an error is named by its class

A fix confirmed after an answer was cached did not reach the next person within the hour; memory is now read before the cache. And 103 of 458 stored errors carried a sentence or a path as their error class, so two wordings of one failure never met in memory. The class is now the error's own, or honestly unknown.

The bundled MCP server accepts every language it can diagnose

It declared six languages and rejected the rest, so an agent naming java, csharp, css or lua had its call refused and retried with auto, and every one of those rows recorded the language as unknown. It now accepts all 24.

Your operating system's own messages are errors

"The filename, directory name, or volume label syntax is incorrect." is Windows error 123, and the extension turned it away before it reached the engine. Those messages are now sent. A project path with a space in it no longer truncates, which had decided which file a fix was written into.

Your files are now split by function, not by line count

Every piece of code DebugAI had stored about your project was a fixed 50-line window, cut wherever the count landed. A window that starts halfway through one function and ends halfway through the next is a poor thing to search, and it is what every cross-file answer has been built from. Files are now split along their real structure, so a stored piece is a whole function, a class, or an import block. The change applies the next time a project is indexed. Nothing you do differently, and nothing to install.

A traceback from a command you typed is no longer blamed on your project

An agent debugging your code often runs a quick one-liner to check something, and when that one-liner has a typo the traceback points at no file you own. DebugAI could already tell, and said so only when nothing else matched, which meant the commonest case never heard it: a syntax error in a one-liner looked like a syntax error, so it was answered as one, and the advice was to hunt a missing bracket in a file that does not exist. It now says where the failing line actually lives whatever else it has to say, and for a one-liner that will not parse it names the two things that usually cause it.

The version your project pins is now part of the question

The MCP server sends what your project declares, with versions, read from package.json, requirements.txt, pyproject.toml, .csproj and nested manifests in a monorepo. Where a version is pinned exactly, answers about that package are grounded in that release. Where it is a range, or where nothing declares it at all, DebugAI says it does not know rather than guessing. Your .env is never opened; only the fact that one exists is reported.

A fix that caused the next error is not offered again

Four errors at the same file and line, sixty seconds apart, each one produced by applying the fix given for the one before it. Error memory could not see it, because four different compiler codes look like four unrelated errors. DebugAI now remembers by position as well, so a repeated failure at the same line is told what was already suggested there and what happened next.

Java, C# and your build config are indexed

Indexing accepted five file extensions. Reading what our users said actually fixed their bugs, more of those fixes landed in a Dockerfile or a tsconfig.json than in every language we did not cover put together. Java, C#, .mjs, .cjs, .csproj and a named list of build and deploy files are now included. Config files are admitted by exact name, never by extension and never by folder, and your .env is not on that list and will not be.

Your source files get the slots before your snapshots do

A project larger than your plan indexes used to fill its budget in whatever order the file search returned, so a large repository could spend the whole thing on snapshots, fixtures and migrations and never store the file your error is in. Source comes first now, build config keeps a small reserved share, and tests and generated trees come last. The choice is stable, so re-indexing picks the same files rather than quietly rotating them.

Indexing says what it could not store

A project bigger than your plan indexes reported that DebugAI could now trace an error across your codebase, with most of the project missing. It now tells you how many files are not in the index and that nothing failed and there is nothing to retry. A repository larger than the search limit used to report itself as exactly the size of that limit; the walk now looks at the whole project.

Installing on a day when nothing is broken now works

Three screens greeted a new install and two of them asked for an error. The walkthrough opened with the heading "Your project is being indexed", which could not be true, because that page appears only when there is no API key and indexing needs one; its button offered to check indexing status and answered "Set your API key to start indexing". After signing in, a toast led with "Analyze an error". Indexing finished and a second toast led with it again, and pressing it read a terminal that was empty because the editor had only just opened. Nobody installs a debugger on the day nothing is broken. The walkthrough now opens on the one step that matters with no key, which is signing in, by one browser confirmation rather than by copying a key by hand, something this extension has supported since 2.1 and that page never mentioned. Neither toast offers to analyse an error any more; the feature and its command are untouched, they are only gone from the two moments where they could not work. And the panel that lists the files DebugAI actually read, and offers a Proactive Scan, now opens after you sign in and index in the same window. It used to open only when the extension started, so on the commonest first run there is it was skipped entirely and you saw it a window restart later or never.

A one-line typo is no longer reported as a high-severity bug

A Proactive Scan on a Python file with a misspelled import on line 1 reported it as high severity. The finding was right and the fix was right; the grade was not. An import that cannot resolve is the loudest failure Python has and the interpreter names it at that line the first time you run. The cause was that severity had stopped describing severity and was grading whether the scan could prove its own claim, which the panel already shows beside every finding in its own label, so the red badge was a second copy of the chip next to it. Across every finding this product has ever produced there were 23 high, 18 medium, and not one low. Severity now describes what the failure costs you and whether you would find it yourself: high is it breaks and nothing tells you, medium is it breaks loudly and by name the first time that line runs, low is narrow. Results cached under the old grading are retired rather than re-served.

Your daily count was counting requests you were never charged for

The dashboard could show 13 debugs used against a limit of 10, with nothing actually broken and nobody ever blocked early. When DebugAI declines to analyse something, such as a shell prompt or one of our own answers pasted back, the attempt is free and the slot is handed straight back. The counters that enforce your limit knew that; the numbers on your dashboard did not and counted those refusals as debugs. They also left out answers served from cache, which do use a slot. Two errors pulling in opposite directions, so no two screens agreed. Every screen now shows what you actually spent today.

Team Error Memory reaches the bundled MCP server

DebugAI ships two copies of the same MCP server: the @debugai/mcp package you install, and one bundled into the extension that VS Code registers automatically with no setup. The bundled one is the copy an agent is most likely to be on, precisely because nobody has to configure it. Team Error Memory shipped to the installed copy in August and never reached the bundled one, so for its entire life that server told every agent it remembered this project and printed nothing. It now prints the section it promised, in four states rather than two: a fix that was applied and kept failing says so, and the agent is told not to propose it again. The files DebugAI read off disk are named rather than counted, so you can see when it looked at the wrong thing.

DebugAI notices when its own parts stop working

Three failures inside the extension this week were found by reading code, not by anything reporting them. One was a button that rendered correctly and had no click handler at all. The extension now counts the failures it swallows on the paths where that changes your answer or loses a measurement, and it notices a click that produced no effect by observing the press where it happens rather than where it is handled. It counts nothing that is merely a file you do not have or a socket that closed, because an instrument reporting a hundred normal things is one nobody reads. Action names and integers only, batched onto a request already being made, and only when your editor allows telemetry.

A missing module has three causes and only one of them is a missing package

ModuleNotFoundError: No module named 'numpy' came back as pip install numpy. One person got that answer three days running while numpy sat in their project .venv the whole time, because the interpreter that ran the script was the global one and no amount of installing was going to change that. Somebody else got pip install ip_connection_monitor for a file sitting next to the one that failed to import it, and there is no such package, so that command either fetches an unrelated project off PyPI or fails. A read of every one of these DebugAI has answered found five of eight rejected by the person or agent who received them, for three different reasons: the package was installed under a different interpreter, the missing name was a local file, or the import line itself was malformed. The first thing DebugAI says now is the check that tells those apart, python -c "import sys; print(sys.executable)" and pip show <name>. Two commands, a few seconds, and they cannot damage anything if the ordinary guess was going to be right. pip install is still named and is still correct for the plain case. It stops being the first thing said.

DebugAI reads your project before it tells you to install something

The analysis runs on a server, and a server has never been able to see your machine. Your editor can. It now looks at the three files it was already reading for other reasons, package.json, requirements.txt and pyproject.toml, plus whether the project has a virtual environment and which interpreter VS Code has selected. A name that turns out to be one of your own .py files is named as one, and no install command is offered at all. A package your project declares but has not installed gets pip install -r requirements.txt rather than one package name, because installing one of several missing declarations leaves you with the next error. A .venv your editor is not pointed at gets said out loud, which is the most common reason a package looks missing when it is sitting right there. Nothing is executed. Every one of these is a file read or a setting VS Code already holds, so there is no new permission to grant and no new prompt, and your editor sends the dependency names your own manifests spell while the comparing happens on the server. A short list is never read as an absence: if only part of your project could be read, DebugAI says so and answers the way it did before, instead of telling you with confidence that something is not there.

A comment on an import line stopped making the answer worse

import Flask, jsonify, request # type: ignore is the shape this whole feature was written for, and the trailing comment was enough to break it. The rule that reads an import line ended at the end of the line, so any comment after it failed to match, and the answer fell from naming the fix to suggesting you check whether the package is installed. Nothing errored. The answer just got quieter, which is why it survived as long as it did, and # type: ignore, # noqa and # pylint: disable= live on import lines more than on any other kind of line because import lines are where linters complain. Two smaller things in the same area. import numpy as np is read properly now; it was never a mistake, but the analysis has to see the line to conclude that. And when DebugAI rewrites a malformed import it leaves alone any name it does not recognise, which is what stops re being dragged onto a flask import, but send_file was one of the names it did not recognise so the corrected line silently lost it. An incomplete fix is quieter than a wrong one and much harder to notice.

Three of our own answers that were wrong quietly

Found by writing the release test for the changes above, not by anyone reporting them, which is the whole problem with this kind of bug. First, a corrected import dropped every name but the one that failed: given import Flask, jsonify, request, render_template, the code block offered back read from flask import Flask. That is a correct line, and it also loses three working imports, so pasting it makes the error go away and hands you a different one a minute later with nothing to connect it to. The full list was being computed the whole time and printed in the explanation; it never reached the block you copy. Second, the Fix button on a scan finding could do nothing and say nothing: if the panel had been open across a later scan the finding it pointed at was gone and the click was swallowed. It now tells you to run the scan again, and still refuses rather than reaching for whatever finding sits in that position now, because that would apply a fix judged against one scan to a file judged by another. Third, nothing was recording what you did with a scan finding. Pressing Fix, cancelling or undoing has been reported back since 2.9.3 so we can measure whether the verified-fix labels mean anything, and it was posting to the wrong address the entire time. Nobody could have noticed, because that call is deliberately silent so it can never interrupt applying a fix, which also meant it could never announce that it was broken.

Errors from your operating system were being called “not an error”

Paste “Access is denied.” or “The system cannot find the file specified.” or “No space left on device” and DebugAI told you there was no error in that text. These are the plainest errors there are, the ones Windows and your shell hand you when something fails, and they carry none of the shapes DebugAI was looking for: no colon, no exception class, no stack trace, and not one instance of the word error. A check of thirty ordinary operating-system errors found twenty-eight of them refused. The worst part is what it looked like from your side, because refusing a real error costs nothing at the moment you paste it and leaves you nothing to retry differently. One person ran seven debugs and the last two were this, back to back. Twenty-five patterns added, covering the Windows system messages and the POSIX strings underneath them, and terminal capture picks these up now too. Everything that was correctly refused before is still refused, checked against the actual junk this has been sent rather than against examples.

A Python syntax error is no longer diagnosed as a JavaScript one

SyntaxError is the name of a Python exception and also a JavaScript one, and the rule that recognised it only knew the JavaScript half. So a Python parse failure arrived at the model already labelled as JavaScript, with advice to go looking for unclosed template literals, which Python does not have. That label was not a note in a log, it was handed over as the leading theory to check first, which is the worst place for a wrong one. Python syntax errors now get advice written for Python: read the line above the caret as well as the one it marks, and look for the unclosed bracket or the missing colon that actually caused it.

The framework DebugAI reports is now read from your error, not your folder

A Flask import failure was being reported as Django, and a PowerShell script as React. The guess came from scanning package.json and requirements.txt, which answers what your project is built with rather than what just broke, so any repository containing more than one framework reported the wrong one for everything in it. The error text decides now, and the project-level guess only answers when the error itself says nothing.

Credentials pasted by accident are no longer stored

If an API key, a token or a password appears in the text you send, it is replaced before anything is written down and before the request reaches a model. This came out of finding two real credentials sitting in our own logs, neither of them ours to hold. What replaces them names the kind of key it was, so an error about a rejected Stripe key still reads as an error about a rejected Stripe key. Nineteen real error messages are checked byte for byte to make sure ordinary text is never touched.

PowerShell 7 users get the instant answer again

PowerShell 5 says a command is not recognized as the name of a cmdlet. PowerShell 7 says a name of a cmdlet. DebugAI only knew the older wording, so on PowerShell 7 a missing command took six seconds and a model call instead of a tenth of a second from the pattern library, and the answer was worse for it. Both wordings are recognised now.

Monorepos were being skipped entirely

If your repository has a frontend and a backend, or packages, or apps, DebugAI indexed almost none of it. A rule added in March skipped any file more than one directory deep inside a folder that had its own package.json or requirements.txt, which is the definition of the layout it was breaking. Affected projects indexed zero files, scanned zero files, and were told nothing, because every path that hit it treats a skipped file as ordinary. The rule is gone and nothing replaced it: the directories that actually matter were always excluded separately, and the file walk was already capped.

Open a file rather than a folder and DebugAI now says so

Opening a single file leaves VS Code with no workspace folder, and without one there is no index, no cross-file tracing and no memory of past fixes. That was silent. Debugging still worked, so there was no error to notice, and the answer was simply thinner than it should have been for as long as you kept working that way. You now get one notice, once, with a button that opens the folder. It never blocks a debug and it never appears on startup.

The panel that opens after your first index had been failing silently

If you installed or updated to 2.9.2 or 2.9.3 and indexed a project, the panel that should have opened afterwards never appeared. Not an error, not a notification, nothing in the logs. It threw on its first line and a catch written to protect activation swallowed it. The line was wrong in a way the type checker had been reporting since the day 2.9.2 shipped, and it was not caught before release because packaging is done by a bundler that does not check types, so the broken code built cleanly and the warning was only ever on a screen nobody was required to read. Publishing now runs the type check first and refuses to build if it fails, which is the part that stops this recurring.

The scan learns from what you apply, not from what we bought

Every number we have about how often a scan finding is right came from a corpus run somebody paid for and read by hand. The last one produced five organic findings, on which two errors give a range of roughly 7 percent to 81 percent, and a range containing both "excellent" and "unusable" settles nothing. You grade every finding for free by pressing Fix or not pressing it, and until now that answer was thrown away. Opening a fix, applying it, cancelling the diff and undoing one you already applied are each reported against an id the server issued with the finding. No code and no file contents leave your machine on that path: the id is a hash we computed and sent you, and the reply is one word. It makes one question answerable that no corpus can answer, because a corpus has no user. The scan labels every fix verified, unverified or rejected, and the whole claim of that ladder is that a verified finding is worth more than an unverified one. If both get applied at the same rate, the ladder is decoration and we should stop describing it.

A long-time user is no longer greeted as a stranger

2.9.0 started showing the first-run panel to everybody, because the marker it checks is per project and nobody had one yet. That is the right delivery and the wrong words: a window that opens unbidden and says DebugAI has read your codebase tells a long-time user nothing. It now recognises an upgrade and explains itself. Every index built before this week stored around sixty files while reporting five hundred, so cross-file answers were working from part of your project. The re-index that runs when the extension starts repairs it, and the panel says so out loud rather than fixing it quietly. Something that was wrong for months should not be corrected in silence. That notice appears once per version, not once per project: six repositories, one explanation.

A notification where a window is not possible

Restricted-mode workspaces and some remote hosts refuse to create a webview, and the failure is silent. Those users would have received the release as nothing at all, and we would never have heard, because there is no signal for a window that did not open. The offer now falls back to a notification carrying the same two buttons. It is a worse experience on purpose, and it is not silence.

The first scan offered ten files while the server accepted eighteen

The first-scan work shipped in three parts and only two of them were real. The API raises a first scan to eighteen files and the engine analyses up to twenty, and the editor capped its own list at ten before sending it, so the wider first scan has never actually happened. Both halves were individually correct and only their relationship was wrong, which is why 2,836 tests passed over it. The cap now lives in one named constant on each side with a test that reads the other file as text and fails if the two numbers stop matching.

Four panels rendered a dash that is banned in our own writing

Em dashes in the welcome flow and the scan panel, in strings a user reads. Now checked by a test that renders every state of both panels, strips the markup and reads what is left.

Run "DebugAI: Index Workspace" once after updating

The endpoint that stores your indexed files sat on the wrong rate limiter, sixty requests per fifteen minutes keyed by address. Indexing a workspace sends up to five hundred files in batches of ten, so a whole repository arrives in about ten seconds: sixty were stored and four hundred and forty were refused. The extension could not tell the difference, because the function doing the storing caught every error and returned nothing, so the counter incremented on all five hundred. The toast said five hundred, the status bar said five hundred, and analytics reported five hundred. Every cross-file capability reads that index, so scan neighbours, stack-trace retrieval, Team Error Memory and both MCP servers have been reasoning over a fraction of every repository larger than sixty files while telling everybody the codebase was fully indexed. The endpoint now has its own limiter keyed by account rather than address, and the extension counts only what the server confirmed it stored. Your existing index is almost certainly short, and re-indexing is the only way to repair it.

Indexing now ends in a window instead of a notification

When indexing finished, the notification offered to analyze an error, which requires you to have an error. Nobody installs a debugger on a day when nothing is broken, so the slowest and most committed step in the product ended by asking for something most people did not have. It now opens one panel listing the files it actually read, with an offer to scan them, and the results appear in the same window. Once per project, and a setting turns it off for good. The offer says what the scan does and never what it will find: on a healthy codebase the honest outcome is nothing, and a flow that needs bugs to feel successful is a flow that will eventually invent them.

The Fix button on a scan finding now means the edit applies

A fix used to be a suggestion, and roughly half of them were prose ending in advice to refactor something manually, which is not a fix. A fix is now an exact old and new string, and before you see it the engine locates that text in your real file, applies the replacement to a copy, and re-parses the result. If it cannot be found, if it matches in more than one place, or if the file stops parsing afterwards, the edit is stripped and no button appears. A rejected fix does not refute its finding: the bug can be real while our patch is wrong, so you still see the problem and the line. Dropping a genuine defect because we wrote a bad patch for it would hide the defect and protect nobody.

The scan panel reports what it checked, not only what it found

Findings are sorted with verified ones first and open at their line on a click. The panel carries the number of findings that were dropped because they did not hold up against your source, and distinguishes a scan that hit its time limit from one that stopped early having found enough, and both from a scan that read nothing at all. Those three used to print identically.

The first scan of a project reads more, and reads it better

Eighteen files rather than ten, stopping as soon as it has three findings worth showing, and always on the stronger model whatever tier you are on. It happens once per project, and it is the impression that decides whether anybody comes back. Measured on a seeded corpus of nine open source repositories, the model tier moved recall from 29 percent to 67 percent, and the cheaper model read a guaranteed TypeError twice without mentioning it. Scans also analyse files in parallel now, so eighteen files take about as long as five used to.

Twenty-one families of real failure were being refused

Reading every refusal in production over fourteen days turned up thirteen, across seven people, and at least two of them were genuine errors somebody had pasted and been told were not errors: "Unexpected token 'const' while loading SouthSudanShootout.html" and an Invoke-WebRequest that returned HTTP 500. Probing forty-two ordinary error shapes against the rules refused thirty-one of them. The blind spot had one shape, and it was the same one twice before: every rule needed either a colon, the word error, or a phrase somebody had thought of. React, Postgres, HTTP clients, bundlers, TLS and out-of-memory kills use none of those, so "Too many re-renders", "relation users does not exist", "EADDRINUSE", "certificate has expired", "ChunkLoadError" and "process exited with code 137" were all read as you did not paste an error.

It mattered more after the last release, not less

The previous version stopped capturing terminal output it did not recognise, which was the right fix for shell prompts and the wrong outcome for a real error the rules had never learned. A JavaScript syntax error sitting in your terminal was served by neither release: the older one sent it and came back with a refusal, the newer one quietly captured nothing at all.

DebugAI now reads the command that failed, not the one you ran last

Run a build that fails, then run your tests, then ask DebugAI, and it used to tell you no error was found in the terminal while the error sat in the buffer the whole time. The extension keeps the last five command outputs and joined them together, so the analyser only ever saw the tail of whatever ran most recently, and three thousand characters of passing tests were enough to bury a failed build. VS Code reports the exit code of every command, and DebugAI had been recording it since terminal capture was first built without ever reading it once. It reads it now, and analyses the most recent command that both failed and printed something that reads like an error. A non-zero exit that printed nothing useful is skipped, so a grep with no matches does not become your error, and tools that report failure while exiting zero behave exactly as they did before.

The widening is bounded, and both halves are tested

A signal match skips every check for prompts, banners and pasted source, so growing the list carelessly would bring back the bug the last release fixed. Both halves are pinned now, on the engine and in the editor: the new shapes must be recognised, and the exact shell prompts from the sessions that started this must still be refused.

Applying a fix can no longer overwrite what you typed while reading it

Every write followed the same shape: read the file, build the change, show you a diff, wait however long you took, then write the version built before you started reading. Anything typed in between was gone, and nothing said so. DebugAI now re-reads the file at the moment it writes, and if it moved it stops and tells you. Nothing is merged and nothing is overwritten. The fix is still on screen, and running it again rebuilds it against the file as it now stands.

Undo will not take your later work with it, and unsaved changes are respected

Undo restores the file to what it held before a fix, which is only right while the file still holds that fix. Apply something, keep working, hit Undo inside its window, and everything written afterwards went too. It checks first now. Separately, nothing in the extension had ever looked at whether a file was open with unsaved edits: fixes were written straight to disk behind the editor, so your next save could silently revert one while the panel still said it had been applied. Fixes go through the editor the same way your own typing does, which also means Ctrl+Z undoes one.

Long analyses are no longer reported as timeouts

The extension gave up at ninety seconds, which is exactly how long the server allows the engine, and the extension’s clock starts first and includes the server’s own work. Anything near the limit showed "Analysis timed out" even though the answer had been produced, and it still cost you a debug. The extension now waits longer than the server does, so the timeout that fires is the one that knows what happened.

Agents on the built-in server can read your code again

DebugAI ships an MCP server two ways: as an npm package, and bundled into the extension where VS Code registers it automatically with no install and no configuration. Reading the files a stack trace names shipped in the npm one and never reached the bundled one, so on the easiest path into the product an agent that pasted a traceback into a workspace nobody had indexed still got "Insufficient context" at twenty percent. Both now read the source, inside your project folder only, source files only.

Analyze Terminal Error no longer offers you your own prompt

If your terminal held nothing but a prompt, a banner, or commands that worked, DebugAI handed over the last thousand characters anyway, because the function reading the terminal had no way to say there is no error here. So "PS C:\Users\you\project>" came back as Found in terminal, with an Analyze This button, and it cost one of your daily debugs. The answer then correctly told you to paste the real error, and retrying captured the same prompt again, so following the advice was impossible. Somebody who signed up on August 30 spent both of their first two debugs that way and left. The capture now returns nothing when it finds nothing, and says which happened: no error found in the terminal, only a prompt or command output. You get the paste box, which is the honest ask.

Analyzing a selection now recognises the errors it was silently ignoring

The same bug failing the opposite way, and it was the more common one. Selecting "bash: git: command not found", "npm ERR! code ERESOLVE", "error TS2345", "Segmentation fault (core dumped)" or a Python File line and running the analyzer did nothing with your selection and opened an empty box. The extension carried an older, shorter idea of what an error looks like than the engine did: of twenty-four error shapes the engine accepts, the extension refused twenty-one. It recognises all of them now.

Both halves read one list, and a test keeps it that way

The rules for what counts as an error were corrected three separate times over ten days, each time because a real person was refused a real error, and not one of those corrections reached the extension. Nothing checked, so nothing noticed. That decision now lives in a single tested module pinned line for line against the engine, and the pin is a test that fails the moment the two disagree.

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.