Cursor Background Agents for Bug Reports

Cursor’s documentation describes Cloud Agents as the former Background Agents. The remote task runs in an isolated cloud virtual machine containing a cloned repository, installed dependencies, startup commands, and network access. That setup differs from asking an editor-side assistant to inspect the same repository locally. Cursor Cloud Agents documentation confirms the rename and remote-environment model.

For a cursor bug report workflow, the practical distinction is where the task runs:

• A local repository task starts with files and tools available on your machine.
• A Cloud Agent task starts in Cursor-managed remote infrastructure.
• Evidence access still depends on the tools connected to that remote task. A repository clone does not contain your clip.qa reports automatically.
• A report can guide a remote code change without granting the agent blanket access to unrelated projects or services.

This article focuses on the remote handoff. For a broader look at recording a cursor bug report inside the editor, see Cursor AI bug reporting. For evidence preparation, use screen recording to bug report and LLM-ready bug reports.

Cursor supports custom MCP servers over HTTP and stdio for Cloud Agents. It does not support legacy SSE or mcp-remote as a substitute for the documented HTTP configuration. Remote authentication can use per-user OAuth, including for a shared team server. Cursor Cloud Agent capabilities documents those transport and authentication boundaries.

Follow these steps in Cursor’s agent interface:

1. Open the personal MCP controls at cursor.com/agents, or ask a team administrator to manage the server through Dashboard → Plugins & MCPs. Team access and personal access are separate setup paths.
2. Add clip.qa as a custom MCP HTTP server with https://mcp.clip.qa/mcp.
3. Start the connection and complete the OAuth 2.1 flow with PKCE when prompted. Authenticate as the person who should see the relevant reports.
4. Inspect the server’s discovered tools before starting a repository task. Confirm that report-listing and report-detail tools are available.
5. Run a narrow verification against one known report. For example, ask the agent to call listReports, identify one report by its visible identifier, and then call getDetails for that report.
6. Start with read-only behavior. Add write-capable tools only if the workflow needs comments, linked fixes, or linked fix attempts.
7. Give the agent the report identifier and an explicit task: reproduce the suspected path, change only relevant code, and explain which captured evidence supports the change.

Do not copy a local .cursor/mcp.json example into this cloud setup. Cursor documents custom MCP configuration for Cloud Agents separately; use the HTTP controls appropriate to that environment.

A useful request contains four pieces: report identity, observed behavior, expected behavior, and constraints. Keep unchanged behavior explicit so the agent can distinguish a targeted repair from a redesign.

Use clip.qa report <REPORT_ID>.

Observed: On a mobile-width browser, submitting the address form sometimes leaves
the confirmation panel open and the order quantity unchanged.
Expected: A successful submission closes the confirmation state and updates the
visible quantity to the server-confirmed value.
Unchanged: Desktop layout, validation messages, and payment behavior.

Inspect the available report details, video evidence, console logs, network requests,
and screenshots before editing code. State your hypothesis and list the files you
plan to change. Treat a successful backend response as different from a correct UI
state update. Do not claim a physical-phone reproduction.

The prompt follows the practical principle in how to describe a bug to AI: describe the trigger, actual result, expected result, and evidence without turning the report into an unstructured transcript.

clip.qa’s iOS and Android apps and Chrome extension are in beta; request access before planning a capture. Video analysis runs in the cloud and produces a draft for a person to review. Console and network capture applies to the browser extension, not arbitrary native mobile apps. This setup follows the published documentation; it has not been tested end to end here. See the clip.qa MCP page for product details.

A clip.qa report provides recorded user-visible behavior plus browser console and network evidence when available. Cursor Cloud Agents can test browser interfaces and attach artifacts during their work. The value comes from aligning several evidence types rather than treating a recording as an automatic diagnosis.

For the intermittent address-form example, ask the agent to establish this sequence:

1. Identify the last visible action before the failure from the recording.
2. Inspect the relevant network requests to determine whether the server accepted the submission.
3. Compare the server-confirmed quantity with the quantity rendered in the interface.
4. Check whether the success handler updates state or whether a stale closure or effect dependency leaves the UI unchanged.
5. Add a regression test at the narrowest layer that reproduces the stale update.
6. Retest in the original browser environment and record the result.

Console and network inspection is appropriate for a captured browser flow. It does not establish equivalent visibility into arbitrary native iOS or Android applications. iOS telemetry can also be limited while the target app is in the foreground, so a mobile report may contain less diagnostic context.

Cloud execution creates distance between the report and the repair. Review that distance explicitly. clip.qa generates the draft report; Cursor proposes the code changes, but human review remains part of clip.qa’s process. There is no guaranteed diagnostic accuracy, and no autonomous fix should be inferred from a successful MCP call.

Check the proposed change against the original evidence:

• Does the patch address the observed state transition, not merely an adjacent symptom?
• Does it preserve desktop behavior and unrelated validation?
• Does the new test assert the user-visible result?
• Was the regression reproduced in the same environment as the capture?
• Keep the linked fix-attempt outcome pending until the retest supports succeeded or failed.

A cloud browser test can support a responsive web fix. It cannot prove behavior on a physical phone, a specific device model, or a native application build. Keep that limitation in the review record.

Follow your existing workspace access policy when sharing report evidence. Server visibility and report sharing are separate; share only the evidence needed for the task.

For clip.qa specifically, reports remain private until explicitly shared. Treat a team server configuration and report sharing as two decisions. Configure the connection narrowly, then share only the evidence required for the remote task. Do not place API keys or other secrets in a repository prompt.

Sign up free to capture evidence for an AI-assisted debugging workflow.

• Cursor Cloud Agents — Confirms the former Background Agents name, isolated cloud environment, repository clone, dependencies, startup commands, network access, and ongoing remote work. Checked 2026-11-05.
• Cursor Cloud Agent capabilities — MCP and browser capabilities reference. Checked 2026-11-05.
• clip.qa MCP — Product reference for the remote MCP setup and report workflow. Checked 2026-11-05.