Error memory
What DebugAI remembers about each error in a project, how a fix becomes remembered, and what makes it forget one.
DebugAI remembers the errors each of your projects has hit, and what happened to the fixes. When the same error comes back, the answer starts from that history instead of from nothing.
DebugAI recognises an error by its signature: the error with the values that change from run to run taken out. Memory belongs to your account. Nobody else sees it, teammates included.
What the badges mean
When memory has something on an error, the results panel shows one badge above the answer. Hover over it for the line in quotes.
| Badge | What it says |
|---|---|
| Fixed before · verified | "A live session watched this error stop after the fix was applied." |
| Fixed before | "A fix for this error was applied and accepted here before. Not observed to work." |
| A previous fix didn't hold | "A fix was applied for this error before and the error came back. The analysis below has been told not to repeat it." |
| Seen before | "This exact error has occurred in this project before." |
A live session is Debug in Browser watching your running app, which is how DebugAI can see an error stop, not only be told it did.
How a fix gets remembered
A fix is remembered for an error when there is evidence it helped.
From the extension:
- Pressing Apply on a fix, or Copy, tells DebugAI that fix helped.
- A thumbs up under the answer says the answer as a whole helped.
- A thumbs down records what went wrong. It does not erase anything from memory: an opinion about an answer is not proof about your program.
From an AI agent, report_outcome carries the verdict:
| Result | When to use it | What memory does |
|---|---|---|
worked | A DebugAI fix was applied and the error stopped | Remembers the fix named in fixRank |
worked_modified | A fix worked only after changes | Remembers the code sent in finalFix, not the original suggestion |
failed | A fix was applied and did not help | Shows that fix to the project's analyses and lookups for the next week as one not to repeat |
unused | No DebugAI fix was applied, and it was solved another way | Counts nothing for or against any fix. The real fix, sent in actualFix, is logged |
unused is not failed. A fix nobody ran is no evidence against it, and reporting it as failed would bury an answer that may have been right. A right diagnosis whose fix did not apply cleanly is unused too.
How memory stops trusting a fix
When an error comes back after its fix was remembered, memory counts it:
- Once: the fix becomes unproven. A single return can be a stale browser tab or a hot reload replaying the old code, so memory says less rather than more: the badge reads A previous fix didn't hold and the answer is told the fix is unproven.
- Twice or more: the fix is marked as one not to repeat. The next answer is told to avoid it.
Memory keeps the failed fix rather than deleting it. "This was tried and it did not hold" stops the next answer from suggesting it again.
Asking memory directly
An agent can call lookup_error with an error. It answers from memory alone: no model call, nothing counted against your daily limit. It says whether the project has seen the error, how often, and which fix was confirmed for it or reported as failed. With the Claude Code hook, that lookup runs on every failed shell command.
On your dashboard, Still coming back on the Overview tab lists the errors that keep recurring, with a Yes and No to tell DebugAI whether a fix held.
What counts as one project
Memory is kept per project, and each surface identifies a project in its own way:
| Surface | The project is |
|---|---|
| VS Code extension | The first folder open in the workspace |
| MCP server | The git repository it runs in, or its working folder when there is no repository. An agent can name another with projectRoot |
| ChatGPT and Codex plugin | The project name in the tool call. Calls that name none share one project, called chatgpt |
On macOS and Linux, the extension and the MCP server share one memory when the folder you open in the editor is the root of the git repository. On Windows they do not yet: they spell the same folder differently, so they keep two memories of one checkout. See MCP server problems.
Keeping and deleting it
Debug history and error memory are kept with your account, with no fixed expiry, so the fixes that worked stay available. To have them deleted, email privacy@debugai.io from the address on your account. More in What leaves your machine.