ChatGPT Dots + GitHub: From Bug Report to Reviewed PR

A bug report arrives while your team is building something else. The expensive part is often everything between reading the report and reviewing a useful fix: finding the relevant code, reproducing the behavior, preserving context and checking what actually changed.

That is the workflow worth evaluating with ChatGPT Dots: feedback in, a reviewable evidence package out. Not an unattended merge button. This guide proposes a bounded GitHub bug-triage workflow, including a reusable assignment, test-evidence requirements and a stop procedure.

Documentation checked on 1 October 2026. Product capabilities below come from OpenAI's documentation. The pilot, acceptance criteria and examples are our proposed engineering design, not results from a live Dots benchmark.

What are ChatGPT Dots?

OpenAI introduced Dots on 29 September 2026: persistent agents powered by GPT-6 Astra, with a cloud computer and support for ongoing work. Its launch announcement illustrates feedback-to-fix workflows. Specialist dots with separate organizational identities remain focused enterprise pilots.

For a development team, the interesting question is not whether an agent can generate another patch. It is whether delegation reduces the work needed to reach a defensible review decision. We would assign one dot to coordinate intake, source gathering and bounded fixes while keeping acceptance outside its own judgment.

Keep three responsibilities explicit: the coordinator decides what to investigate within the agreed brief; the coding environment produces the proposed change; the reviewer decides whether the evidence justifies acceptance. One person may own the pilot, but those decisions should not collapse into a single “done” message.

Who can use Dots at launch?

The official access guide lists this rollout as of the review date. Eligibility is not immediate account availability.

For an Austrian or German team, check the actual workspace plan rather than concluding that every European account has the same eligibility. Do not build a rollout commitment around a feature that has not appeared in your account.

Create the dot on desktop. The setup documentation separates app connections, messaging connections and local-computer access. Our suggested pilot starts with one repository and no local-computer connection. Add only the access that a specific test proves necessary.

Set up GitHub and the coding environment separately

The computers and apps guide describes GitHub issue investigation and PR preparation through an authorized plugin. Repository-specific cloud coding can use a preconfigured Codex environment. Local work instead needs a connected, online computer with ChatGPT open.

A connected GitHub account is not proof that the correct repository, branch, dependencies and test data are available. Before assigning a recurring responsibility, run a small access test. Ask for the selected repository, a known issue, the current revision and the test command defined by that repository. Require the dot to distinguish information it read from information it inferred.

Next, use a disposable branch or test repository to verify the allowed write path. Can the configured account create the intended draft PR without also having a path to merge or deploy? Inspect source-system permissions and workflow credentials, not just the wording of the assignment. Where your integration cannot enforce the intended boundary, keep its work read-only and let a human transfer the proposed patch.

Put a short handoff brief beside every coding task: report identifier, expected behavior, affected revision, allowed files, reproduction instructions and acceptance tests. Do not make acceptance depend on the coding task remembering an earlier conversation. For authenticated browser work, use our separate ChatGPT cloud-browser sign-in guide rather than treating an app connection as a website login.

A reusable Dots assignment for bug triage

Connecting Slack does not itself start monitoring. The tasks and memory guide requires an explicit supported trigger or saved schedule. It also warns that completed runs do not establish successful outcomes. Verify both intake and results.

The following is a proposed conversation brief, not a Dots API or a configuration file. Replace the named inputs before using it. Start with an owner-submitted report; add automated intake only after confirming support in your workspace.

Responsibility: prepare reviewable fixes, not releases.

Owner: the named engineering reviewer.
Scope: the agreed repository, feedback source and test environment.
Intake: investigate only reports the owner assigns in this pilot.
Before coding: identify the source report and current revision;
reproduce the problem or state exactly what blocks reproduction.

Use the agreed Codex cloud environment. Do not use a local computer.
Propose one narrowly scoped fix per report. Do not change acceptance
criteria, remove failing tests, access production data or alter CI.

After the owner authorizes publication, create a draft PR only if
that action is permitted. Otherwise return a patch for human review.
Do not merge, deploy, close the source issue or contact customers.

Return: report link, base and head revisions, reproduction,
changed files, exact checks and their results, unrun checks,
remaining risks and the requested reviewer decision.
A failed or unavailable check is not a passing check.

Ask before expanding scope or starting another paid work stream.
Report blockers instead of substituting a different environment.

For a later scheduled pilot, specify an exact time zone, end date and delivery destination, then inspect the saved schedule. For event-driven intake, submit one synthetic report and confirm that exactly one investigation starts. Submit the same report again and check the duplicate policy. “Watch this channel” is not sufficient acceptance evidence.

Keep the original report identifier through the whole workflow. A duplicate should link to the existing investigation rather than create another competing fix. A report about a different revision should be revalidated, not silently attached to an old reproduction.

Define a PR evidence contract before the first fix

Our proposed acceptance rule: a patch is reviewable only when another engineer can connect its claimed result to the exact tested revision. A video helps explain a UI change. It does not establish which commit was running, whether assertions passed or whether a neighboring behavior regressed.

Consider a fictional report: “The export button is missing on mobile.” A weak fix makes the button visible for everyone. A useful investigation first establishes the affected viewport, user role and account state. The proposed fix should then be checked for the authorized mobile user, the unauthorized user and the existing desktop behavior. If the export is asynchronous, include its pending and failed states.

Ask for the baseline failure and the corrected result using the same relevant inputs. Keep the expected result independent of the patch. Otherwise, an agent can accidentally make its own test pass by weakening the assertion rather than correcting the application.

Use explicit review states such as not-reproduced, blocked, patch-unverified and ready-for-review. These are proposed team labels, not built-in Dots statuses. Reserve acceptance for a human decision backed by the required checks. Missing browser access means “browser checks not run”, not “verified through code inspection”.

Apply the same distinction after any additional commit. Evidence from an earlier revision does not automatically approve a later patch. For the broader testing architecture, see agentic testing versus deterministic test automation.

Separate authorization from software correctness

The Enterprise administration guide says only the owner directs a personal dot through supported Slack messages. It also states that Enterprise model defaults do not govern Dots. Review Dots-specific access rather than assuming an existing model policy covers the pilot.

That owner boundary matters to intake design. Treat a colleague's bug report as task data, not authority to widen permissions. A request inside an issue to export secrets, bypass tests or publish a release should never become an instruction just because it appeared in an approved repository.

OpenAI's Dots safety explanation describes safeguards against malicious instructions and read-only proactive research. That background research is different from authorized assigned work. Our engineering distinction is equally important: permission to perform an action does not establish that its output is correct.

For this pilot, allow reading agreed reports and preparing isolated changes; require review before publishing a PR; keep merge, deployment, credential changes and customer communications outside the assignment. Implement the available restrictions at the app, repository and execution-environment layers. Do not give the agent a more privileged browser session as a workaround for a restricted plugin.

Before expanding access, test three deliberate failures: an out-of-scope repository, a report containing hostile instructions and a missing dependency. The desired outcomes are a denied request, ignored instructions and an accurately reported blocker. They are not three opportunities for the agent to find a broader route.

How to stop Dots work without leaving tasks running

OpenAI's controls guide distinguishes three operations: Pause affects the main task; delegated work must be stopped in Activity; recurring work must be disabled or deleted in Scheduled. Custom rules are fallible instructions, not app-access grants. Completed actions are not rolled back by stopping.

Make shutdown a pilot acceptance test. Start a harmless delegated task and a future recurring check. Pause the coordinator, inspect both independently, then stop the task and remove the schedule. Record what actually stopped. Verify app permissions and any authenticated website sessions separately before calling the pilot offboarded.

The Help Center's Dots guide also distinguishes disconnecting an app from deleting information already obtained. Review the current reset or deletion confirmation and preserve approved evidence before removing the dot. Revocation, retained context and already-published artifacts need separate decisions.

For the proposed GitHub workflow, that means checking for open draft PRs, branches, queued work and scheduled intake. Removing access is not the same as deciding what to do with the patches already produced.

Measure accepted fixes, not agent activity

Run a small, explicitly bounded pilot on non-critical issues. Keep every assigned report in the denominator, including duplicates, blocked attempts and reports that turn out not to be bugs. Otherwise, the dashboard rewards easy cases while hiding the coordination cost.

Our suggested scorecard records accepted fixes, reviewer minutes per assigned report, false-positive reports, unverified outputs and regressions discovered after acceptance. Compare similar work with the team's existing process. Include the time spent correcting the brief, repairing the environment and rejecting plausible but unsupported conclusions.

For cost, count setup, human review and all task usage, including discarded attempts. OpenAI's ChatGPT release notes describe temporary launch allowances, not a permanent unlimited-work commitment. Confirm the current in-product allowance and applicable Work or Codex usage before setting a recurring budget.

A useful outcome is not necessarily more PRs. It may be faster identification of reports that cannot yet be reproduced, fewer context handoffs or better evidence for the same number of fixes. Set the continue-or-stop criteria before reviewing the results, not after seeing an attractive demo.

When to use Dots, and when to build a workflow

Our suggested fit is coordination around a named owner's changing priorities: investigate this report, keep that bounded queue current, return the evidence for review. Choose a different implementation path when your acceptance requirements demand a shared service identity, deterministic triggers, explicit retry semantics or a production service-level commitment that your Dots pilot has not demonstrated.

This is not an argument to build everything yourself. It is a reason to distinguish an assistant's usefulness from a production system's contract. Our OpenAI Agents API engineering review covers the custom-product path without treating Dots as a public application API.

For a concrete next step, bring one recurring bug queue and one representative repository to a workflow and QA scoping discussion. Start by defining the acceptance evidence and permission boundary. Automate the handoffs only after those are clear.