Haunted DevTools: A Local AI Debugger for Errors That Refuse to Stay Dead

A developer built Haunted DevTools, a local-first Chrome DevTools extension that groups uncaught JavaScript errors, unhandled Promise rejections and failed HTTP requests into fingerprinted incident case files, then sends sanitized event summaries to locally installed open-weight models via Ollama for structured diagnoses. The Manifest V3 extension, written in TypeScript, React and Vite, validates model responses for severity, likely cause, evidence, confidence and suggested fix, and preserves out-of-shape output as an explicitly unstructured fallback. Incidents can be marked exorcised and are flagged as Resurrected if the same failure returns, with the prior diagnosis restored.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine https://dev.to/challenges/hacktoberfest-week4-2026-10-26 I built Haunted DevTools , a local-first Chrome DevTools extension that turns browser failures into case files instead of a noisy stream of console output. It watches the inspected page for uncaught JavaScript errors, unhandled Promise rejections, and failed HTTP requests. Related failures are grouped by a stable fingerprint, so one bug that happens ten times becomes one incident with a useful repeat count. A developer can inspect the incident, ask a local model for a diagnosis, and mark it as exorcised after attempting a fix. That is where the "Ghost in the Machine" theme becomes part of the product rather than just decoration: if an exorcised error comes back later, Haunted DevTools recognizes it as Resurrected , restores its previous diagnosis, and records another debugging cycle. Bugs do have a habit of returning when you least expect them. The repository includes two deterministic demo labs: a plain JavaScript cursed website and a React cursed app. They create runtime errors, rejected Promises, malformed URLs, failed requests, and repeated incidents on demand. The walkthrough shows the full loop: select a local model, trigger an error, inspect its diagnosis, mark the case exorcised, and see its history in the website archive. The project source is available here: CodersVader/Haunted-Devtools https://github.com/CodersVader/Haunted-Devtools . Chrome page errors / DevTools network failures ↓ grouped local incident case file ↓ Ollama + local open-weight model ↓ diagnosis, evidence, suggested fix, and archive Haunted DevTools is a Manifest V3 Chrome extension built with TypeScript, React, Vite, and Chrome DevTools APIs. The AI diagnosis workflow runs through Ollama https://ollama.com/ at 127.0.0.1:11434 . The extension supports locally installed open-weight models, including qwen2.5:7b-instruct for code-focused explanations and gemma4:e2b-it-qat for general debugging guidance. When a new incident group appears, the extension sends a sanitized event summary to the selected local model and asks for structured JSON: severity, likely cause, observed evidence, confidence, and a concrete suggested fix. The extension validates that response before showing it. If the model returns something outside the expected shape, Haunted DevTools preserves it as an explicitly unstructured fallback rather than pretending it is a verified diagnosis. The rest of the debugging workflow is deliberately local too: Debugging is one of the places where developers should be able to choose where their data goes. An error message can reveal internal URLs, stack locations, feature names, and details of an app that is not public yet. A hosted AI endpoint would make that a tradeoff between getting help and keeping the failure local. With Ollama and an open-weight model, Haunted DevTools keeps the diagnosis loop on the developer's own machine. After the model is installed, it can work without an API key, a hosted AI account, or an internet connection. Developers can also swap models, choose a smaller model for a laptop, or change the prompting and validation logic because those pieces are visible in the project. Open AI is not an optional chatbot bolted onto this project. It is what turns a grouped failure into a local, structured debugging conversation while preserving the developer's control over the data. I wanted the theme to be useful, not just spooky. Console errors are already a little ghost-like: they appear, disappear during a refresh, and sometimes return after everyone thought the bug was fixed. So Haunted DevTools gives those moments a practical lifecycle. A failure is active, then exorcised, then possibly resurrected. The theatrical language makes the workflow memorable; the local diagnosis, stable grouping, and persistent history make it useful when the same failure comes back from the dead.