Start Xdebug only for the request you want
Set xdebug.start_with_request=trigger in php.ini. Xdebug then starts only for a request that carries XDEBUG_TRIGGER as a GET or POST parameter, a cookie, or an environment variable, and that one session goes to Buggregator's Xdebug proxy. Every other request runs without the debugger.
Steps
1. Turn the proxy on
The proxy is off by default. Add MCP_ENABLED=true too if you want an AI assistant to read the session; otherwise the first line is enough.
XDEBUG_PROXY_ENABLED=true
MCP_ENABLED=trueIf your IDE also listens on port 9003, move the IDE to 9004 (PhpStorm: Settings → PHP → Debug → Xdebug → Debug port). The proxy passes the session on to it.
2. Set the trigger in php.ini
A typical php.ini for Buggregator. The last line is the one that limits debugging to triggered requests.
xdebug.mode=debug
xdebug.client_host=127.0.0.1
xdebug.client_port=9003
xdebug.start_with_request=trigger3. In Docker, open the proxy to the network
By default the proxy listens on 127.0.0.1:9003 inside its container, so PHP in another container cannot reach it. When PHP and Buggregator both run in Compose, make the proxy listen on all interfaces and dial the IDE on your machine:
environment:
XDEBUG_PROXY_ENABLED: "true"
XDEBUG_PROXY_ADDR: 0.0.0.0:9003
XDEBUG_PROXY_IDE_ADDR: host.docker.internal:9003
extra_hosts:
- host.docker.internal:host-gateway # needed on LinuxThen set xdebug.client_host to the Buggregator service name, for example buggregator. Here the IDE can stay on port 9003. PHP on your machine needs a different layout; see the Docker section of the Xdebug docs.
4. Send the trigger
Add XDEBUG_TRIGGER to the one request you want to debug: as a GET or POST variable, or as a cookie. For a CLI script, set the XDEBUG_TRIGGER environment variable. Xdebug does not look at the value, unless you set xdebug.trigger_value; then only a matching value starts it.
5. Tell the script where to stop
Without an IDE, put this line where you want to stop, or set a breakpoint on the Xdebug page.
xdebug_break();In trigger mode, Xdebug's docs say xdebug_break() also starts a session on its own.
Why it works
The trigger rules are Xdebug's own: in trigger mode it checks for XDEBUG_TRIGGER in $_ENV, $_GET, $_POST and $_COOKIE when the request starts (https://xdebug.org/docs/all_settings#start_with_request). A triggered request connects to Buggregator on port 9003. Buggregator passes it to your IDE or, with no IDE, drives it from the Xdebug page.
Docs: docs.buggregator.dev/config/xdebug.html#_3-point-xdebug-at-buggregator
Requires Buggregator v2.6.0+
Related tips
- Xdebug
Claude Code sets a breakpoint and steps through PHP
Turn on Buggregator's Xdebug proxy and MCP. With no IDE attached, Claude Code sets a breakpoint, waits for the request, reads variables and steps.
- Xdebug
Record every call of one request and find the slow one
Record an Xdebug function trace, send the file to Buggregator, and see the slowest calls, the call tree and a search over every call.
- MCP
Claude Code reads your app's errors over MCP
Add Buggregator as an MCP server in Claude Code. It lists your Sentry errors, opens stack traces and reads dumps and profiles. No copy-paste.
Checked on with Buggregator v2.8.0