Does Cursor's Bugbot Catch Customer-Reported Issues?
No. Bugbot reviews the pull request diff, and nothing else. It checks the change against your repository's own conventions, flags correctness and security issues a reviewer might skim past, and posts a status check back to the PR. It has no mechanism for opening the Linear ticket, the Zendesk thread, or whatever support conversation the bug started in, and no way to compare the diff against the customer's actual words.
That's not a shortcoming buried in the fine print. It's the documented shape of the product: Bugbot "analyzes PR diffs and leaves comments with explanations and fix suggestions," triggered automatically on every push or manually by commenting cursor review or bugbot run. Everything it reads lives inside the repository and the pull request itself, the changed files, your team's .cursor/BUGBOT.md rules, and prior PR comments so it doesn't repeat a suggestion. A customer's report of what actually broke, and under what conditions, isn't in scope, because Bugbot was never given a way to fetch it.
Where the detail that decided the fix stops traveling
Trace one customer-reported bug through the review loop. The report lands in support email and describes the failure precisely, including the condition that produced it: two events arriving close enough together that both handlers read the same state before either one committed. Triage files it in Linear under a one-line title naming the symptom, which is a fair paraphrase of what support heard.
You pick the ticket up, find the job that handles the event, and add a database lock so two attempts can't race. You open the PR. Bugbot runs automatically on the push, checks the diff against your repo's .cursor/BUGBOT.md rules and its usual correctness patterns, and posts a clean status check with no findings. A teammate skims the green check and merges it.
The fix holds for the single-event case. It doesn't touch the actual condition, because the lock is scoped to one event rather than to the shared resource both events contend for, and the report's timing detail never traveled past the ticket title. The same symptom comes back later, from a different account.
Nothing malfunctioned in that cycle. The ticket was a fair summary of what support heard, the diff followed your conventions and added a real lock where there hadn't been one, and Bugbot checked exactly what it's built to check. The detail that decided whether the fix worked lived only in the original email.
The specific job Bugbot signs up for
Bugbot's scope is narrower than "is this bug fixed," and the review it actually performs is worth stating precisely. By default it only reviews what changed since its last pass on a given PR, an incremental diff, not the whole thing; a team can turn off Incremental Review in Bugbot Automations if it wants every push checked against the full pull request diff instead. Either way, what it's checking for is the same: the kinds of problems a tired human reviewer misses on a Friday, null derefs, unhandled error paths, obvious security holes, a change that contradicts a pattern used everywhere else in the file. Repo-level .cursor/BUGBOT.md files let a team point it at known trouble spots, and it's supported on GitHub, GitLab, Bitbucket, and Azure DevOps, so most teams can turn it on without changing where code review already happens.
None of that requires Bugbot to know why the PR exists. A diff that renames a variable, tightens a null check, and adds a test can look identical whether it fixes the exact bug a customer hit or fixes a different bug nearby that happens to touch the same function. Bugbot's status check comes back clean either way, because "clean" means the code is well-formed, not that it resolves a specific complaint filed somewhere it can't see.
Why that habit breaks down once volume climbs
The direct fix costs nothing: before merging on a clean Bugbot check, pull up the original support thread and read the diff against it, not just against the ticket title. That's the right habit at low volume, and any team can start it today.
It breaks down on two axes at once. First, it depends on whoever's reviewing remembering to go find the original thread, every time, on top of reading the diff itself, and that's a step that quietly stops happening the moment a sprint gets busy. Second, once bug reports arrive through support email, Slack Connect, and the occasional call note, "find the original thread" is itself a search, not a click, and the searches that get skipped are indistinguishable from the ones where skipping didn't matter until the same bug resurfaces with a different customer's name on it.
Attaching the report to the check
Keeping the original report in front of the reviewer is what Modem is built for, and since Modem is what we sell, weigh the next two sentences with that in mind. Modem reads support inboxes, Slack, and sales calls as they happen and keeps each customer's original message, not a rewritten summary of it, attached to the same topic as the Linear or Jira issue it produces. When that topic is handed to Cursor, the task brief Cursor's background agent works from carries the original wording along with it, so scoping starts from what the customer actually said instead of the ticket's one-line version. Modem also reports the finished PR's link back into the same conversation, so a reviewer looking at a clean Bugbot check can open that thread and read the customer's exact words next to the diff before merging, rather than reconstructing which support email started the work.
It doesn't replace Bugbot, and it wouldn't have scoped the lock correctly on its own either; someone still has to notice that the timing described in the report is the condition that matters. What it removes is the search for where that detail is written down. Below the point where that search takes real time, doing it by hand is genuinely fine. For the fuller comparison of what a human reviewer should check before trusting a green light on a background agent's PR, see how to review what Cursor's background agent changed before it opens a PR, and for the end-to-end version of this same handoff across tools, from user report to merged fix.
Before you trust the next clean check
Open the original message, not the ticket's paraphrase of it, and read it once against the diff before merging. Ask whether the diff's condition actually matches the customer's condition, the way a single event and two simultaneous events can both plausibly describe the same symptom without being the same bug. A clean Bugbot check is real information about the code. It was never going to be information about the report.
