Code and Git model

When an agent writes code for you, the question a team actually cares about is what lands in their Git history and who is on the commit. The answer is the one you would want: an agent's code work becomes an ordinary pull request, on an ordinary branch, under the human's own GitHub identity, and GitHub stays the system of record that holds the merge. Nothing about the way Disco Parrot ships code asks you to trust a new place with your code or to give up the review you already run.

This page is the mechanism. The everyday how-to of shipping is on ship code; connecting a repository is on connect a repository. It is the architecture view, not the security view: how a credential reaches a clone is covered on credential leases. Here the question is how the Git model is built.

A pull request under the human's identity

When an agent ships, the platform opens a normal pull request, and the commit and the PR are authored under the connected person's own GitHub identity, not a service account. The platform resolves that person's GitHub credential, the one they connected, and uses it to push the branch and open the request, so the PR shows up in GitHub exactly as if they had opened it themselves. When no personal identity is available for the repository, the platform falls back to a GitHub App token so the work can still ship, rather than failing the run; in that case the commit is authored by the GitHub App rather than a person, though the branch it pushes still carries the identity of the person who ran it. The identity rides the credential rather than a field the platform fills in: the commit's author is whoever the resolved token belongs to, with GitHub's own email, which is why a reviewer sees the person rather than a bot.

The branch follows a predictable shape, pr/ then the person and a timestamp, so an agent's branches are easy to recognize and never collide with the ones your team cuts by hand. Authoring under the human's identity is what gives you accountability that survives the agent: the PR, the commit, and the review all carry a real person's name, and your branch protections, required reviews, and CODEOWNERS rules apply to it the same as any other. Those rules are GitHub's own; the platform enforces none of them, it opens the request and steps back.

How a ship gets triggered

Shipping is not automatic, and that is the point: a person decides a change is ready, and the platform does the mechanical work from there. The everyday trigger is a built-in create-pull-request skill the agent runs on your say-so. You ask for the change to be shipped, the agent gathers its edits in the sandbox, and the skill pushes the branch and opens the request through GitHub, then records the new pull request, its number, its URL, and its branch, onto the plan it came from. That skill is one of the platform's locked operations rather than something a workspace writes, so the path from a finished change to a real pull request runs the same way every time. The deciding is yours; the assembly is the platform's. The everyday walkthrough of that moment is on ship code.

A branch with clean lineage

A pull request is only useful if its branch descends cleanly from the right place. The platform resolves the base branch in order, the workspace's own lineage first, then the repository's configured default branch, then the project's, and cuts the new branch from that base. The commit it pushes has a single parent, the tip of the base, so the branch's ancestry is exactly what GitHub expects: a clean line from your default branch, not a detached or rewritten history. A diff against base shows only the agent's change, because the branch is the agent's change on top of your base and nothing else.

The checkout the agent works in is a real clone of that repository, materialized into its sandbox at the start of the run and shallow to the clone depth you set on the repository, so a cold start stays fast while a deeper clone is there for work that needs more history. The agent edits files in that clone the way a developer would, and shipping turns those edits into the branch and the commit described above. Each pull request is scoped to one repository and cut against that repository's own resolved base, so a workspace that spans several repositories gets a clean branch in each rather than one branch trying to straddle them.

What the pull request carries

A pull request the platform opens reads like one a teammate wrote. It carries a title drawn from the change, the files it touched when you do not give it one, a body that lists what changed and notes who created it, and a link back to the plan it came from, so a reviewer in GitHub can see what the change is for and trace it home without leaving the request. The branch is the recognizable pr/ one, and the diff against base shows only the change itself. A reviewer gets the context they would expect from a careful colleague, in the place they already review.

GitHub holds the merge

The platform opens the pull request and then steps back. It does not write to your pull request: no AI comment, no AI approval, no AI merge. Human review comments are ingested one way, so a reviewer's note becomes follow-up work an agent can pick up, but nothing flows the other direction onto the PR. The merge is yours. Whoever holds merge rights in GitHub merges the request in GitHub, under your branch protections and your checks, exactly as they would for a pull request a teammate opened.

What this gets you: your code and its history stay in GitHub, GitHub decides what merges, and the platform is a participant in your process rather than an owner of it. A merged pull request flows a status back to the platform, covered below, but the act of merging is never the platform's to take.

Merge straight to main, when you choose it

There is a second, separate way to land code, and it differs from a pull request in every step that matters. Merge to main is a direct, governed path that commits selected files from a sandbox straight to your default branch, without a pull request in between. It is not a pull-request merge; it builds the commit through GitHub's Git Trees API, creating the tree and the commit and moving the branch reference in one atomic step, with the acting person as the author.

Because it bypasses review, it is held tightly: it is a destructive, Owner-and-Admin-only action behind its own permission, separate from the everyday ability to ship a pull request. The pull-request path is the default and the one almost every change should take; merge-to-main exists for the narrow cases a team decides warrant a direct commit, and it is gated so that decision sits with the people who should make it.

Review comments come back as work

A reviewer's comment on a pull request becomes a finding attached to the plan, which an agent picks up on its next run and addresses as a new change. When that follow-up runs, the agent pushes its fix to the same branch, so the pull request updates in place rather than spawning a second request for the same piece of work: one PR, one branch, one line of history, and the change answered where it was raised. That is the whole return path: the platform turns review comments into work, and the agent answers by shipping a fix rather than replying in your review thread. The conversation on the pull request stays a record of what people said, and the change shows up as new work rather than a bot in the margin. The deep version of that loop, how a comment becomes a finding and a fix, is on the PR review loop.

How the platform tracks the change

Once a pull request exists, the platform follows it rather than re-reading your files. It tracks the change by commit: a diff is computed between the base commit and the head commit, by SHA, and the in-app diff reads GitHub's own per-file patches for that range. The platform records the commit it pushed, so the change has a stable identifier that ties the work back to an exact point in history.

The pull request's status comes back by webhook. When the PR is opened, merged, or closed, GitHub notifies the platform, and the platform updates the linked plan's pull-request status accordingly: open when it opens, merged when it merges, closed when it is closed without merging.

The plan and its pull request

A plan is the unit of work, and the pull request it produces lives on it as fields: the number, the URL, the branch, and the current status, kept on the plan record rather than in Git. A plan tracks one pull request at a time, a single linked request rather than a list, so the relationship between the work and the code that delivers it stays unambiguous. The two statuses stay separate on purpose. The pull-request status tracks where the code is in GitHub; the plan's own status tracks whether the team considers the work done. A merge moves the first and leaves the second to a person, so a merged pull request never quietly closes the work it belonged to.

The same model on GitHub Enterprise

The model does not change when your code lives on GitHub Enterprise. Whether your organization is on github.com or an Enterprise tenant, the pull request lands under the person's own identity, the branch follows the same shape, and GitHub holds the merge the same way. The platform resolves the provider you connected and opens the request there, and the App-token fallback behaves the same on either. Which GitHub you run is a connection detail set when you register the provider, not a change to the Git story this page describes.

What lives in GitHub, and what does not

The model is easiest to reason about when you know where each thing lives.

• Your code and its history live in GitHub. Branches, commits, pull requests, merges: GitHub is the system of record, and the platform never becomes a second home for them.
• Your work model lives in the platform's database. Initiatives, plans, and bugs are records, and a plan carries the pull request it produced as fields on that record, the number, the URL, the branch, the status, not as anything stored in Git.
• Your documents and wiki live in the platform's document store, not in your repository. Repository documentation is kept and versioned by the platform rather than committed to your default branch, so generating or editing it never touches your code history.
• Uploaded files live in object storage. Attachments on plans and bugs are their own library, separate again from both Git and the work model.

Where a workspace uses Azure DevOps, it is a work-item integration rather than a code backend: it does not host your branches or hold your merges, and it does not change anything on this page. The Git story is GitHub's.

One thing follows directly: an edit an agent makes in its sandbox is not a commit. The sandbox is a working copy, and nothing reaches your repository until the change is shipped as a pull request or, by an admin, merged straight to main. There is no quiet write to your default branch.

How code gets in and out of the sandbox

The credential that clones and pushes is leased for the operation, not kept. When a run clones your repository or pushes a branch, the platform supplies a short-lived token through Git's own credential helper for that one command, and the token is gone after. There is no standing GitHub token sitting in the sandbox for an agent to find, which is the same no-standing-credentials rule the rest of the platform runs on. The person's connected identity, or the App-token fallback, is what authors the result. The deeper account of how that lease is minted and bounded is on credential leases.

The platform reads your code in place rather than copying it: it reaches into the repository by path rather than keeping a shadow copy of your files, so there is never a second, drifting version of your code to reconcile. The same path serves a local backend in development and a GitHub backend in production, and the merge-to-main commit is one caller of it.

An agent ships a change, end to end

When an agent on Maya's team finishes a fix, the change does not appear in main. The platform cuts a branch from the repository's default branch, commits the agent's edits with a single parent on that base, and pushes it using Maya's connected GitHub identity, so the commit carries her name. It opens a pull request, and GitHub records it the way it records any other. The platform hears the open event by webhook and marks the plan's pull-request status as open, with the number and the link on the plan. Maya's team reviews the request in GitHub, leaves comments that come back into the platform as follow-up work, and when it is ready, a reviewer merges it in GitHub. The merge event flows back, the plan's pull-request status turns to merged, and the plan's own status stays exactly where Maya left it until she decides the work is done. Every step happened in the tools the team already uses, under a real person's name.

Why the Git model works this way

The temptation when software writes code is to give the writing software its own identity, its own merge button, and its own place to keep history. That is the design that makes a security team nervous and a developer's blame view useless. Disco Parrot does the opposite. An agent's code lands as a pull request under a real person's identity, on a clean branch, in your repository, and GitHub keeps the history and holds the merge. The platform tracks the change by commit and follows the pull request's status, but it never writes to the request and never owns the merge. The result is that adopting an agent does not change your Git story at all: the same branches, the same reviews, the same merge authority, the same names on the commits, with an agent as one more contributor working inside the process you already trust.

For a developer, the model is plain: an agent's work is a branch named pr/ under your GitHub identity, cut single-parent from the resolved base, opened as a normal pull request. The platform diffs by base and head SHA, follows the PR by webhook, and never comments, approves, or merges. Merge-to-main is a separate, admin-only direct commit through the Git Trees API, not a PR merge.

For a platform engineer, the operational facts are that credentials for clone and push are leased per operation through Git's credential helper with no standing token, the base branch resolves workspace then repository then project, a plan tracks a single pull request as fields on its record, and code content is reached through one abstraction with a local and a GitHub backend rather than copied into the platform.

For an enterprise reviewer, the boundary to check is that GitHub remains the system of record and the merge authority: the platform opens pull requests under a real person's identity and ingests review comments one way, with no path that writes to the pull request or merges it on its own. The one direct-to-main path is destructive, behind an Owner-and-Admin permission, and separate from everyday shipping.

For a prospect, the assurance is that bringing in an agent does not ask you to change how you ship. The agent's code shows up as a pull request in your GitHub, on a branch you can recognize, under the name of the person who ran it, and your team reviews and merges it the way you always have. Nothing about your code leaves the place it already lives.