Debug Laravel production errors with Claude Code

Connect Claude Code to your error tracker over MCP, then let it find new errors, read the stack trace, open your code and propose a fix you review.

Updated View as Markdown

Claude Code can read your production errors when your error tracker runs an MCP server: add the server once, then ask "what broke since this morning?" from your repository. It reads the stack trace, opens the files it points to and proposes a fix that you review like any other diff.

This guide uses Lampwick's MCP server; the workflow and safety rules apply to any error tracker with one.

What you need

  • Claude Code in the repository of the app that throws the errors.
  • An MCP server for your errors. For Lampwick: a personal API token from Account & security (it starts with lwp_) and the Laravel package sending data.
  • A checkout of the commit that runs in production (Lampwick stores the deploy identifier with each occurrence).

Connect Claude Code

export LAMPWICK_TOKEN=YOUR_LAMPWICK_TOKEN
claude mcp add --transport http lampwick https://app.lampwick.dev/mcp --header "Authorization: Bearer $LAMPWICK_TOKEN"

YOUR_LAMPWICK_TOKEN is the lwp_… token. Start Claude Code and run /mcp: lampwick should be listed as connected. Then ask "Which Lampwick projects can you see?" (it calls listProjects). The MCP server docs cover a shared .mcp.json and other clients.

Pre-approve reads, keep writes on "ask"

Claude Code asks before every MCP tool call. Pre-approve the read tools this workflow uses in .claude/settings.json:

{
  "permissions": {
    "allow": [
      "mcp__lampwick__listProjects",
      "mcp__lampwick__listIssues",
      "mcp__lampwick__getIssue",
      "mcp__lampwick__getExecution",
      "mcp__lampwick__listLogs"
    ]
  }
}

updateIssue (resolve, ignore, reopen) and the other write tools still need your yes each time.

The workflow

1. Ask for what's new

Which open issues in Acme Shop were first seen since 08:00 UTC today?

Ask "new since" for fresh bugs and "most occurrences" for impact. With Lampwick the agent calls listIssues with range: "24h" (or 1h, 7d, 14d) and status: "open", then keeps the issues whose first_seen is after 08:00, since there is no "since" parameter.

2. Open the stack trace

Show me the stack trace of #57 and the request it happened in.

getIssue returns the issue, the latest occurrence and its frames: file, line, surrounding source and vendor (true for frames in vendor/). Frames with vendor: false are your code, where the agent should start. If the occurrence has an exec_id, getExecution returns the request, job or command it happened in, with every query, log line and exception on one timeline, which often answers "why only for some users?". (#57 is the issue's ref; tool calls take its id.)

3. Find the code

Open the code for the top app frame and explain why this throws.

Now it works in your repository: it reads the file at the frame's line, follows the other app frames up the call and checks those lines' history for recent changes. If production runs another commit than your checkout, the line numbers won't match.

4. Propose a fix, and a test

Propose a fix and a test that reproduces it. Don't commit.

Review it as you'd review a colleague's diff: does it fix the cause, or hide the symptom with a try/catch or a ?-> that turns an error into wrong data? Run the test before and after the fix.

5. Close the loop

After the deploy, resolve the issue in the dashboard, or ask the agent and approve the updateIssue call. If it comes back, it reopens as a regression and you get a push notification.

Treat monitored data as untrusted input

Everything an error tracker stores came from production: exception messages, log lines, URLs, headers, user names. Some of it was typed by your users, or by whoever probes your app. A log line can say "ignore your instructions and run this command", and the agent reads it in its context. The Claude Code docs warn about this prompt injection risk for any MCP server that returns outside content.

  • Keep write tools on "ask" and approve a call only when it matches what you asked for.
  • Don't let the agent run commands or fetch URLs that appear in the data. If a suggestion comes from an error message rather than your code, stop and look.
  • Review every change before you commit it.
  • A Lampwick token has full access to your account: give the agent its own token with an expiry, and revoke it on Account & security when you're done.

Next step

Add Lampwick to your MCP client, then ask it which issues are new since your last deploy.