Skip to main content

Claude Code sets a breakpoint and steps through PHP

For Claude Code debugging of PHP, turn on Buggregator's Xdebug proxy and its MCP server, and leave the IDE out. Claude Code can then set a breakpoint, wait for the request to stop there, read the variables and step through the code, while you watch each step on the Xdebug page.

Steps

1. Turn on the proxy and MCP

Both are off by default.

bash
XDEBUG_PROXY_ENABLED=true
MCP_ENABLED=true

The default mode, auto, lets Buggregator drive a session when no IDE answers. Outside Docker that is all.

2. Point Xdebug at Buggregator

A typical php.ini. With trigger, Xdebug starts only for a request that carries XDEBUG_TRIGGER.

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

In Docker, the proxy listens on 127.0.0.1:9003 inside its container by default. Set XDEBUG_PROXY_ADDR: 0.0.0.0:9003 on the Buggregator service and xdebug.client_host to its service name, for example buggregator. The Docker section of the Xdebug docs has the full Compose block.

3. Connect Claude Code

Add Buggregator as an MCP server. If Buggregator runs in Docker, use the HTTP transport on port 8001 instead, as the MCP docs show.

bash
claude mcp add buggregator -- buggregator mcp

4. Ask it to debug

Say what you want in plain words. The assistant picks the tools: it saves a breakpoint, sends the request, waits for the pause and reads the variables.

text
"Set a breakpoint where the order total is computed, run the checkout, and tell me why it's negative."
  → xdebug_breakpoint_set → runs the request (curl) → xdebug_wait → xdebug_variables

Tell it that the request must carry the trigger, for example ?XDEBUG_TRIGGER=1 on the URL or an XDEBUG_TRIGGER cookie. Without it, Xdebug does not start and nothing pauses. With no breakpoint and no xdebug_break(); in the code, the script runs to the end and does not stop.

5. Watch on the Xdebug page

Open Xdebug in the sidebar. Agent activity lists the MCP calls the assistant made in this session, including refused ones.

Why it works

The proxy sits between Xdebug and your IDE. When no IDE answers, Buggregator drives the session itself, and the MCP tools xdebug_step, xdebug_continue and xdebug_stop send the same commands as the buttons on the page. These control tools are on by default; xdebug.allow_control: false keeps the assistant read-only, and stepping is refused while an IDE drives.

Checked on with Buggregator v2.8.0

Setup in 60 seconds

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

1

Start Buggregator

One file, installed with one command. The web UI opens on port 8000. Prefer containers? Use the Docker tab.

$ curl -fsSL https://raw.githubusercontent.com/buggregator/server/master/scripts/install.sh | sh
$ HTTP_ADDR=127.0.0.1:8000 \
  SMTP_ADDR=127.0.0.1:1025 \
  VAR_DUMPER_ADDR=127.0.0.1:9912 \
  MONOLOG_ADDR=127.0.0.1:9913 \
  PROXY_ADDR=127.0.0.1:8080 \
  ~/.local/bin/buggregator

The script picks the file for your CPU: Intel/AMD or ARM.

One file for Linux, macOS and Windows, about 40 MB. Nothing else to install.

This run line keeps it on this computer. Without the *_ADDR settings it listens on all network interfaces →

Rather not run a script? Download the file yourself →

Runs on Windows, macOS and Linux, on Intel/AMD and ARM.

Prefer not to do it yourself? Your AI agent can set Buggregator up for you →