How to Fix Bugs with ChatGPT Dots and clip.qa

“The checkout button is broken” tells an agent the outcome, but not what screen the user saw, which action triggered the problem, or whether a request failed. A screenshot adds one moment of visual context. It may still omit the sequence that caused the bug, an error in the console, a failed network call, or the phone and browser involved.

That missing context creates a loop: the agent asks follow-up questions, the reporter tries to remember details, and the developer may still need to reproduce the bug. A recording paired with structured technical context gives the agent a clearer starting point. The AI bug-report workflow explains how clip.qa turns a recording into a report an agent can read.

ChatGPT Dots are designed to continue work through connected tools and Codex, and OpenAI’s examples include building and testing fixes from customer feedback. For a concise overview of the product, see what ChatGPT Dots are and how they work.

• A clip.qa account and a report of the bug you want fixed.
• A ChatGPT account where Dots are enabled, plus a plan and workspace eligible for custom remote MCP. Dots access and MCP read/write permissions are separate; rollout, region, plan, and administrator settings can affect each.
• Permission to add the clip.qa MCP endpoint, https://mcp.clip.qa/mcp, to ChatGPT.
• A repository and test workflow available to the dot’s Codex or connected development tools.
• A human reviewer who can inspect the proposed changes and run the relevant checks.

ChatGPT’s custom MCP connection flow is currently configured from ChatGPT on the web. Workspace policies and plan eligibility apply. OpenAI currently limits Pro custom MCP connections to read/fetch, while full MCP write actions are available to eligible Business and Enterprise/Edu workspaces. Dots must also be enabled on the account; MCP eligibility alone does not grant Dots access. clip.qa’s iOS and Android apps and Chrome extension are built, but public and beta distribution are not verified. Jira, Linear, Slack, GitHub Issues, and Notion integrations are coming soon. This workflow does not depend on those integrations.

1. Record the bug where it happens

If you have confirmed access to a clip.qa recording client, use the iOS or Android app for a mobile issue, or the Chrome extension for a browser issue. Distribution is not verified, so do not assume a client is available. Capture the shortest recording that shows the problem clearly:

1. Start from a relevant screen or state.
2. Perform the steps that trigger the defect.
3. Pause long enough to show the unexpected result.
4. Stop the recording and save the report.

Avoid unrelated navigation. If the bug needs a particular account state, permission, or network condition, say so in the report description.

2. Review the structured report

Open the clip.qa report and check that the title, expected behavior, actual behavior, and reproduction steps describe the issue accurately. For browser recordings made with the Chrome extension, the report can include captured console logs and network requests. A mobile report can include device telemetry; do not assume it contains browser console or network-request capture.

Correct anything that could mislead the agent. Do not assume the recording proves a cause; it provides evidence to investigate. For more on the handoff, see recording a screen video as a bug report.

3. Connect clip.qa to ChatGPT

ChatGPT documents custom MCP server connections through its Plugins experience. On ChatGPT web, open Plugins, choose Add custom MCP server, enter a name, and set the public HTTPS endpoint to https://mcp.clip.qa/mcp. Complete the authentication flow if prompted, review the available tools and permissions, and create the plugin. Install the created plugin, then create or open a dot and connect the plugin to that dot before assigning the report. ChatGPT may ask you to confirm write actions. To record fix attempts, the workspace must allow the MCP write tools; a Pro read/fetch connection can inspect reports but cannot complete that write step. The general MCP-to-Dots path is documented, but clip.qa is not listed as a verified integration. Authenticate and test retrieval of an actual report before relying on it. If that check fails, give the report in Markdown to Codex or another coding agent.

This is the remote MCP method. The local @clip-qa/mcp-server package is for MCP clients that can start a local server, but ChatGPT’s documented custom connection expects a remote endpoint or Secure MCP Tunnel. Do not point ChatGPT at a local stdio server directly.

4. Ask the dot to inspect the report

Give the dot the report identifier or a direct report link that it can access. Ask it to read the report with clip.qa’s MCP tools, summarize the observed-versus-expected behavior, and identify the relevant evidence before proposing a cause.

For example: “Inspect report [ID]. Summarize the reproduction steps and the relevant console or network evidence. Then trace the likely code path in the connected repository. Do not change files until you explain the cause and proposed fix.”

Dots use connected tools and Codex to take on tasks. The dot’s ability to access the repository depends on the connected Codex or computer setup and the permissions you grant; connecting clip.qa does not itself grant repository access.

5. Let the agent prepare and test a focused change

Once you agree with the diagnosis, ask the dot to make a minimal change in the relevant repository, add or update a regression test, and run the project’s existing checks. Ask it to report the files changed, the tests run, and any check that could not run. OpenAI describes Dots preparing and testing fixes for review; treat that as a workflow capability, not a guarantee that every generated change is correct.

6. Log the fix attempt in clip.qa

After the agent reports its result, use the clip.qa MCP tools to link the fix attempt to the report. Include whether the attempt succeeded or failed and attach the associated commit or pull request when available. This keeps the report’s investigation history tied to the code change. Do not mark an attempt successful only because the agent says it changed code; use the test and review result.

7. Review the change and recheck the bug

Inspect the diff, run the tests yourself or verify the agent’s test output, and repeat the original reproduction steps in the affected environment. If the issue remains, record a failed attempt with the new evidence and ask the dot to investigate that evidence. If it is fixed, record the successful outcome and merge through your normal review process.

Suppose a tester taps Pay, sees a spinner, and never reaches the confirmation screen. A screenshot shows the spinner but not whether the app sent a request or received an error.

For a browser checkout, the tester records the click and stuck state with the Chrome extension, if access to that client is confirmed. The report can include captured browser network evidence; any additional device or server evidence must be supplied separately. The developer asks the dot to inspect the report and trace the checkout submit handler and response handling in the repository.

The dot identifies that an error response exits before clearing the loading state, proposes a focused fix, and adds a regression test for the error path. After reviewing the diff and test result, the developer repeats the recording steps on the affected device. The developer then links the commit and outcome as a fix attempt in clip.qa.

This example illustrates the handoff pattern; the actual cause depends on the report and the code. A similar symptom can come from a server response, a disabled control, or a navigation issue, so the agent should use the captured evidence rather than assume this cause.

• Capture the shortest useful reproduction. Show the starting state, action, and failure.
• Keep expected and actual behavior separate. That makes it easier to see what the agent must explain.
• Ask for evidence before a diagnosis. Have the dot cite the report detail or code path that supports its hypothesis.
• Limit the first change. One suspected cause and one regression test make review simpler.
• Keep permissions narrow. Connect only the apps and repository access needed for the task. Review write actions before approving them.
• Track attempts honestly. Record a failed attempt when tests fail or the original bug remains.
• Use a human review. Approve the change only after reviewing its diff and confirming the bug behavior.

For another report-first approach to coding-agent debugging, read how to fix bugs in AI-generated code. To start with clip.qa, Sign up free.

The MCP connection gives ChatGPT tools for reading and updating clip.qa report data. It does not guarantee that the dot can access your local repository, that the bug is reproducible, or that a generated patch is correct. Repository access comes from Codex or another connected development environment and its permissions.

The mobile apps and Chrome extension are built, but public and beta distribution are not verified. Video analysis runs in the cloud. Jira, Linear, Slack, GitHub Issues, and Notion integrations are coming soon, so the steps above use the clip.qa report and MCP connection rather than those destinations.

• Introducing dots — OpenAI — Dots, connected apps, Codex work, testing fixes, availability, safeguards. Date checked: 2026-11-05.
• Dots — ChatGPT — connected tools, Codex, ongoing work, permissions, human review. Date checked: 2026-11-05.
• Create your dot in the ChatGPT mobile app — ChatGPT Learn — Codex thread handoff and setup context. Date checked: 2026-11-05.
• Connecting custom MCP servers in ChatGPT — OpenAI Help Center — endpoint setup, account requirements, remote-only behavior, and write confirmations. Date checked: 2026-11-05.
• Dots access — ChatGPT Learn — account eligibility and Dots availability. Date checked: 2026-11-05.
• Create a dot — ChatGPT Learn — creating or opening a dot and connecting tools. Date checked: 2026-11-05.