If you've ever watched an agent try to fix a bug, you've watched it guess. It reads the code, comes up with a theory, makes an edit, and hopes. Sometimes it's right. A lot of the time you get a fix that looks confident and quietly hides the real bug.
Debug Mode is what we built for that. Instead of sitting there reasoning about the code, the agent goes and gets evidence about what the code does when it runs.
Here's the loop
Agent comes up with multiple hypotheses, and starts to work on the most plausible firstThen, logging is added to test one hypothesis (without touching implementation)A little debug server collects the runtime output to .cursor/debug.log while your program runs.You reproduce the bug, and agent can now read the logs and understand what happened instead of having to guessCursor finds the root cause in the logs, makes the fix, and pulls out the logging it added.Here it is on a real bug, sped up to about a minute:
How the team uses it
Some interesting things that we've solved internally with debug mode:
A race condition that hit 1 in 20 runs. It was corrupting git metadata in our best-of-N runs. Debug Mode pinned it down in under an hourA memory leak, traced in one pass. It came down to a misuse of our frontend framework. The fix was a single line.A native crash deep in C++. An Electron crash people would normally route around. The logs made it findable.An SSR flicker that had been given up on. A rendering bug nobody wanted to touch, fixed once the agent could see what the page was doing at runtime.Try it with Shift+Tab (it's in the CLI too, via /debug).
I'm sure people are using it in ways I haven't thought of, so let me know!
