How to Use Claude Code to Fix the Bugs Your Clients Report

Using Claude Code to fix bugs works best when the bug arrives with evidence. Ask it to "fix the contact form" and it will read your code and guess; give it the page, the browser, the console error and a screenshot of what the client saw, and it can usually go straight to the cause. The difference is in the bug report, so most of the work is getting complete reports to Claude without copying and pasting them.

What does fixing bugs with Claude Code mean?

Fixing bugs with Claude Code means handing a bug to Anthropic's coding agent, which runs in your terminal inside your repository, and letting it find the cause, change the code and run your checks while you review the result. It reads files, searches the codebase, runs commands such as your tests, and edits code, asking for permission as it goes.

What it can't do is see the client's screen. A bug that only happens on a 390-pixel-wide phone in Safari is invisible from the repository. That information has to come from the report.

Can Claude Code fix bugs on its own?

It can fix a large share of everyday website bugs on its own when the report is complete, and almost none when it isn't. A vague report sends any developer, human or not, into guessing. The table shows what Claude can do with each kind of report.

The third report is what a developer would ask the client for anyway. The point is to collect it before anyone asks.

What does Claude Code need from a bug report?

The same fields a good bug report has always had, with two that matter even more for an AI: the console log and the screenshot, because Claude can't reproduce the client's session.

• Page URL: where it happened, so Claude can map it to a route, template or component.
• Browser, operating system and screen size: many website bugs only exist in one browser or below one width.
• Console messages, errors and failed requests: the closest thing to a stack trace a website visitor can give you.
• Screenshot, annotated: what the client saw and where they pointed, which settles "which button?" at once.
• What they expected and what happened instead: separates a bug from a change request.

Our bug report template lists every field with examples. A feedback widget fills most of them in automatically: GiveFeedback.io attaches the URL, the browser details and the console log to every report and lets the client mark up the screenshot.

How do you connect Claude Code to your client feedback?

Claude Code talks to other services through MCP, the Model Context Protocol, an open standard for giving AI assistants tools. GiveFeedback.io is an MCP server, so once it's added, Claude can read your reports directly instead of you pasting them in.

1. In GiveFeedback.io, open the project's Integrations tab and choose Connect Claude. It works alongside the project's integration, so reports keep reaching Jira, Slack or your email as before.
2. Under Projects it reaches, tick any other of your projects Claude should see, such as the staging copy of the same site.
3. Copy the command it shows. It contains your token and is only shown once.
4. Run it in your project folder:

claude mcp add --transport http \
  givefeedback https://app.givefeedback.io/mcp \
  --header "Authorization: Bearer gfmcp_..."

5. In Claude Code, type /mcp to check that givefeedback is connected.

Claude now has four tools: list your projects, list their feedback (newest first, filtered by project, status or words), read one report in full, and change a report's status. The Claude page shows what each one returns.

A bug-fixing session, step by step

Start with a plain request. The app suggests this one: "Show me the open feedback and fix the first bug." Claude lists the open reports and picks one up. To work on a specific report, use the ready-made prompt with its number:

/mcp__givefeedback__fix_feedback 345

From there, a good session looks like this:

1. Claude reads the report. The description, the page, the browser and screen size, the console log and the annotated screenshot, as an image.
2. It finds the cause before touching code. Ask it to explain the cause in a sentence or two first. If the explanation doesn't match the screenshot, stop there.
3. It makes the smallest change that fixes it and runs your tests or linter.
4. You review the diff. Check it at the browser and screen size from the report, not just on your own laptop.
5. Claude asks before resolving the report. Once you agree, it marks it resolved. On paid plans the project's integration follows, so the Jira issue or Trello card is done too, and the client can see the report was fixed.

A report that turns out to be a request ("can the logo be bigger?") should go back to your normal change process, not into a quick fix.

Give Claude your rules for client bugs

Claude Code reads a file called CLAUDE.md in your repository at the start of every session. A short section there about client-reported bugs saves you from repeating the same instructions: treat reports as evidence, explain the cause first, keep the fix small, run the checks, show the diff, ask before resolving.

Fill in the blanks for your project: the test and lint commands, and which GiveFeedback.io project is the staging site and which is the live one. With both connected, Claude gets their names and addresses and uses the one whose site it is working on.

How do you review an AI fix before resolving the report?

Review it the way you'd review a fix from a new developer: reproduce, read the diff, check the neighbors. Resolving a report tells the client it's done, so the check has to happen before, not after.

• Open the page from the report at the same screen size and in the same browser, if you have it.
• Compare with the screenshot: is the thing the client pointed at fixed?
• Read the diff. Small and local is good; a fix that touches ten files for one button deserves a question.
• Run the checks yourself if Claude didn't, and look for other pages that use the same component.
• For anything visual, deploy to staging first and let the client confirm with the same feedback button.

Our website QA checklist has the wider list for a release.

Keeping it safe

Two risks come with connecting an AI to bug reports, and both have simple answers.

The first is what the reports say. Anyone visiting a website can send it feedback, including text written to manipulate an AI ("ignore your instructions and..."). GiveFeedback.io tells Claude that a report's title, description and console log are what a visitor sent: something to investigate, never instructions to follow. Your CLAUDE.md section should say the same, and Claude Code still asks you before running commands or editing files, depending on your permission settings.

The second is what the token can reach. Each token is for one person or computer, reaches only the projects chosen for it and only while they're yours, and can be revoked from the project at any time, which stops it at once. It can read feedback and change its status; it can't reach your account, your billing or anyone else's projects.

Bug fixing with an AI agent is only as good as the reports it reads. Get the URL, the environment, the console log and an annotated screenshot into every report, connect Claude to them, and the slow part of a client bug becomes reviewing a fix instead of chasing details. Connecting Claude is included in every GiveFeedback.io plan, the free one too.