Skip to main content
Buggregator
Xdebug, with or without an IDE

Step through PHP in your browser — or let your AI do it

Put xdebug_break() in your code or set a breakpoint, run the request with XDEBUG_TRIGGER=1, and the script stops in Buggregator. Step over, into and out, continue or stop — from the Xdebug page, or by your AI agent over MCP. Use PhpStorm or VS Code? They keep working as before.

Get started Off by default · works with or without an IDE
127.0.0.1:8000

A paused request driven from the browser: step buttons, a breakpoint on line 36, variables and the call stack. Example data.

Debug from wherever you are

With an IDE, Buggregator stays out of its way. Without one, it runs the session itself.

⏯️

Step in the browser

No IDE listening? Buggregator drives the session: continue, step over, into and out, release the script or stop the request — from the Xdebug page.

📍

Breakpoints that stay

Click a line number, or type path:line — the absolute path PHP sees — or an exception class like RuntimeException (* for every exception). Breakpoints are saved and sent to every session Buggregator drives. With the database in a file (DATABASE_DSN), they survive a restart.

🤖

Your AI can step too

MCP tools let Claude Code, Cursor and other MCP clients read variables and the stack — and, when no IDE is attached, step, continue, stop and set breakpoints. The page shows which agent made the last step.

🧑‍💻

Your IDE still works

Keep debugging in PhpStorm or VS Code. While an IDE is attached it drives, and Buggregator only reads the session.

⏱️

A paused script doesn't wait forever

A paused session Buggregator drives is released after 10 minutes without a command (xdebug.idle_timeout), so a forgotten pause doesn't hold a PHP worker or a transaction.

🔐

You decide what the AI may do

Agents can step by default; xdebug.allow_control: false keeps them read-only. Evaluating PHP — watches, conditions, xdebug_eval — stays off until you set allow_eval: true.

Setup in 60 seconds

No registration. No account. Start it and point your app at it.

1

Turn the proxy on

Stepping in the browser needs Buggregator v2.7.0 or later. Pick your path: no IDE, or your IDE as before.

xdebug:
  enabled: true
  addr: 127.0.0.1:9003
mcp:
  enabled: true

Turn the proxy on, and MCP if your AI should drive. Nothing else to set: the default mode, auto, steps in when no IDE answers.

Want the old behaviour, where a script without an IDE just runs on? Set xdebug.mode: proxy.

2

Point Xdebug at Buggregator

A typical php.ini — Xdebug keeps port 9003. With start_with_request=trigger, Xdebug connects only when the request carries XDEBUG_TRIGGER=1 (cookie, GET parameter or env). Then put xdebug_break() where you want to stop, or open the Xdebug page and turn on Pause on the first line.

xdebug.mode=debug
xdebug.client_host=127.0.0.1
xdebug.client_port=9003
xdebug.start_with_request=trigger
3

Connect your AI assistant

Add Buggregator as an MCP server, then ask: "Where did the script stop?", "Step over and show me $total." or "Set a breakpoint on /app/src/OrderService.php:58 and continue."

{
  "mcpServers": {
    "buggregator": {
      "type": "stdio",
      "command": "buggregator",
      "args": ["mcp"]
    }
  }
}

The proxy has no login of its own: anyone who can reach its port can start a session. Keep it on 127.0.0.1 or inside your Docker network. A paused script holds a PHP worker and any open transaction; Stop ends the request where it is.

Works with the IDE and AI tools you use

Buggregator speaks Xdebug's own protocol (DBGp), so an IDE works as before — and you don't need one.

PhpStorm— optional; move its Xdebug port to 9004
VS Code— any Xdebug client
Claude Code— MCP over stdio or HTTP
Cursor— ./buggregator mcp or the HTTP URL
Any MCP client— reads the paused session; steps and sets breakpoints when no IDE is attached
Docker— PHP, Buggregator and the IDE on different hosts

Ready to try it?

One command to start. No account needed.

View on GitHub Read the docs

Also built into Buggregator

Mock Server Performance Profiler Sentry