Where can a Copilot coding agent use bug evidence?
clip.qa records screen bugs on iOS, Android, and Chrome. Capture clients are beta and require request access. Analysis runs in clip.qa’s cloud and creates a draft report that a human reviews; a Copilot task does not turn that draft into a guaranteed diagnosis or autonomous fix.
The GitHub Copilot surfaces can run repository tasks, edit code, and run tests. They may use a cloud sandbox or a GitHub Actions session depending on the configured surface (Copilot surfaces). A newer cloud experience is available from October 28, 2026, so avoid stale claims about one universal execution duration or environment for every surface.
Start by separating evidence from assignment:
- Evidence: the exact reproduction, expected behavior, observed behavior, environment, screenshots, transcript, and available diagnostics.
- Assignment: the code question, scope, acceptance checks, and required validation record.
- Unknowns: data that the capture did not collect.
For example, suppose an export command fails when a filename contains an accented character. The report establishes the visible failure and command context. It does not by itself establish whether the fault is in shell quoting, Unicode normalization, path encoding, a library boundary, or the target application’s parser.
A useful task says: “The export fails for the fixture rapport-été.pdf; determine the failing encoding boundary and add a regression test using that exact non-ASCII filename.” It does not say: “Fix Unicode handling,” because that would convert a hypothesis into a requirement before code inspection.
The LLM-ready bug reports guide explains how to format this evidence. The screen recording to bug report workflow helps connect a visible failure to a reproducible sequence.
Keep platform limits in the task. A browser extension can capture Chrome console and network data. It does not expose arbitrary native mobile app console or traffic, and iOS telemetry can be limited while the target app is foregrounded. Mobile recordings may still provide valuable visual and contextual evidence without those diagnostics.
This is a documentation-based explainer, not a promise of fully copy-paste tested setup. Verify the current documentation, your Copilot surface, and the installed package behavior before relying on a connection.
Which MCP configuration route fits the surface?
Choose the route based on where you configure MCP and whether the surface can use remote OAuth. Repository Settings > Copilot > MCP servers and custom agent profiles have a remote OAuth limitation: repository-configured servers cannot use remote OAuth. clip.qa’s remote endpoint uses OAuth 2.1 with PKCE, so pasting https://mcp.clip.qa/mcp into that repository configuration is not a turnkey solution.
The supported alternative for those repository-configured workflows is clip.qa’s local stdio package, @clip-qa/mcp-server, running with API-key authentication inside the cloud environment. Do not assume that a personal Copilot MCP surface has the same limitation; check that surface’s current guidance separately.
Use this comparison to select a path:
| Surface or workflow | Evidence access | Authentication and execution notes |
|---|---|---|
| Repository-configured Copilot MCP | Local stdio server such as @clip-qa/mcp-server | Cloud environment runs the process; configure API key and allowed tools |
| Custom agent profile MCP | Local stdio server with API-key auth, or reviewed text handoff | Remote OAuth is unsupported here too; personal MCP configurations are a separate surface. |
| Other personal MCP surface | May expose local or remote MCP | Verify current surface documentation and permission behavior |
| Manual handoff | Reviewer uses authenticated clip.qa CLI and transfers scrubbed evidence | Works without an agent-to-clip.qa MCP connection |
The clip.qa MCP documentation distinguishes the remote service from the local package. The remote tools use names such as listReports, getDetails, getScreenshots, getVideoTranscript, getNetworkRequests, getConsoleLogs, getReportDiff, createComment, linkFix, and linkFixAttempt. The local stdio server uses different names, including get_report, get_report_for_llm, list_reports, search_reports, get_report_diff, create_comment, link_fix, and link_fix_attempt.
Do not mix those names in a configuration or prompt. A remote-oriented instruction that calls get_report is invalid for the remote endpoint, while getDetails is invalid for the local stdio server.
For the remote endpoint, use its documented Streamable HTTP configuration only where the selected surface supports remote OAuth. For repository MCP servers, plan for the local package route or manual handoff instead.
How should a local MCP server be configured carefully?
For a repository-configured Copilot MCP server, use the local @clip-qa/mcp-server package with a command that launches it and an allowlist limited to needed tools.
Use the documented npx -y @clip-qa/mcp-server local stdio launch and allowlist only the read tools required for the first task. Verify the current package documentation for the authentication environment-variable name before mapping it to an Agents secret.
The package’s documented credential environment-variable name must be confirmed before setup. @clip-qa/mcp-server uses API-key authentication, but the package’s documented environment-variable name must be verified from its current documentation. Map that installed package’s documented authentication environment variable to an Agents secret whose name starts with COPILOT_MCP_.
Do not create a fictional JSON field such as an API-key property, and do not assume there is a clip.qa login command. The public CLI package is @clip-qa/cli; its known commands include list-reports, get-report, and search-reports. Its authentication flags and environment names must come from the current CLI documentation rather than guesswork.
Use a secret store appropriate for the environment. Never commit the API key, print it into agent logs, place it in source, or include it in a bug report. Give the local server only the tools the first workflow needs. get_report and list_reports are enough to retrieve evidence; comment and fix-linking operations should be configured separately.
After configuring, validate in stages:
- Confirm the MCP server process starts in the cloud environment with the expected package version.
- Confirm the documented API-key environment variable is present without displaying its value.
- Confirm the tool allowlist contains only
get_reportandlist_reports. - Run
list_reports, then select one known report. - Retrieve one known report using
get_report. - Inspect the returned result for expected report identity and scrubbed content.
If the package cannot authenticate, verify its documentation and secret mapping before changing permissions. Do not “fix” the failure by moving the key into the repository or task prompt.
The clip.qa MCP page is the product reference for remote and local server options.
What is the manual handoff alternative?
A manual handoff can be cleaner when repository MCP settings cannot use remote OAuth. A reviewer runs the authenticated clip.qa CLI, retrieves one report with get-report, scrubs the output, and pastes it into a GitHub issue or Copilot repository task.
Use the CLI only through its documented configuration and authentication. The available list-reports, get-report, and search-reports commands are known; exact flags and environment variable names are not supplied here, so consult the current package documentation. Do not invent a login flow.
The handoff should contain:
- Report ID and concise title.
- App or repository affected.
- Exact reproduction steps.
- Expected and observed results.
- Relevant screenshots or transcript excerpts.
- Environment details.
- Available diagnostics and explicit missing diagnostics.
- A root-cause hypothesis labeled as unconfirmed.
Remove secrets, access tokens, personal information, unrelated customer data, and sensitive filenames. Replace an exact sensitive path with a stable fixture description when the path itself is not needed to reproduce the issue.
This route preserves a useful separation of responsibility. clip.qa supplies private evidence until explicitly shared, and the reviewer controls what enters the repository. It also avoids pretending a remote OAuth URL works in a repository configuration that cannot use remote OAuth.
clip.qa’s native GitHub Issues integration is coming soon. Until then, do not describe this manual transfer as automatic issue creation. The reviewer can create or update the existing GitHub issue and include the scrubbed evidence, subject to the team’s workflow.
How do I create and validate the bug task?
A bug task needs enough detail for the agent to test a mechanism, but not so much that it prescribes the answer. Use the report to define behavior and scope; use the repository to determine cause.
For the non-ASCII export example, create a task like this:
Investigate the export failure for a filename containing a non-ASCII character.
Observed evidence: The attached clip.qa report shows the export failing for `rapport-été.pdf`.
Expected behavior: Export completes and produces a readable file with the intended name.
Inspect the command construction, argument boundaries, and file-writing path. Treat shell quoting,
Unicode normalization, path encoding, and parser behavior as hypotheses. Verify which boundary
fails before changing code. Add a regression test using the exact fixture name and an ASCII control
case. Run focused repository tests and report changed files, commands, results, remaining risk,
and a commit or PR. Do not claim the original bug is fixed until the original environment is retested.
This follows the how to describe a bug to AI guidance: exact behavior, exact fixture, bounded investigation, and observable checks.
Define an acceptance matrix before implementation:
| Case | Expected check |
|---|---|
rapport-été.pdf | Export succeeds and preserves the intended filename semantics |
report.txt | Existing ASCII behavior remains unchanged |
| Space in filename | Argument remains one filename, not two arguments |
| Path with directory | Output lands in the requested directory |
| Unsupported character | Failure is explicit and does not produce a partial file |
Use a fixture whose encoding matches the original report. A test that substitutes only an ASCII filename can pass while the real failure remains. Record exact repository and version details where relevant.
Tests run in the Copilot coding agent’s repository environment, not in clip.qa. A passing test proves only what that test exercises. Before marking the issue resolved, reproduce the export with the original fixture in the original environment and confirm the output.
If a fix-attempt log is required, include the commit or PR and set the outcome to pending, succeeded, or failed. Do not mark it succeeded based on a green test alone. The original-environment retest is the final evidence needed for that transition.
Use write-capable clip.qa tools only after read retrieval is stable. The local tool names are create_comment, link_fix, and link_fix_attempt; do not send the remote names to the local server. Keep comments factual, link the actual commit or PR, and preserve pending until validation completes.
Sign up free to capture evidence for a grounded debugging task.
Sources
- Copilot surfaces — Confirms repository coding-agent tasks, code edits and test execution, cloud sandbox versus GitHub Actions sessions, and the newer cloud experience dated October 28, 2026. Checked 2026-11-05.
- Configure MCP servers — Confirms repository configuration path, required tool allowlists, local stdio servers,
npxcommands, and the remote OAuth limitation for repository-configured servers. Checked 2026-11-05.