For connected repositories, the run has a read-only Git route through the forge gateway. It cannot push to that gateway. Instead, the runner commits its changes, creates a Git bundle and uploads the bundle to a dedicated intake endpoint.
Read through a disposable cache
The forge maintains a pull-through cache for repository bases. It fetches the requested ref with a credential held outside the run, then serves the run’s clone through Git’s upload-pack protocol. There is no receive-pack route for pushes.
The cache is disposable. Losing it costs a re-fetch; it is not the durable record of completed work. The pull-through cache serves cached Git objects when the upstream forge is unavailable. A new run can clone when the cache contains the requested base; uncached refs and objects still require the forge.
Accept a bundle
The runner’s bundle names its output branch and the prerequisite base. Intake verifies the run’s grant, limits upload size, checks the declared ref, and verifies that the bundle can apply against the base repository.
The usual path uses the cached base without contacting the forge. If the base cache is missing, intake must fetch it again before accepting the patch. An outage at that point can delay acceptance.
Once validation succeeds, the bundle is persisted on disk or in S3 before intake acknowledges it. Patch metadata in the control plane records the repository, branch, head and bundle key; the bundle store holds the artifact itself.
Decide when to deliver
Each repository has a submission policy: automatically submit eligible patches or hold them for approval. The patch’s state is separate from the run’s terminal state.
The control plane claims a submission lease and asks the forge to deliver the bundle. The forge materializes the change, pushes it with its own credential and opens a pull request, or a merge request on GitLab. A retry can adopt an already opened pull request rather than creating a duplicate.
For work requested on an existing pull request, delivery can target that pull request’s head branch. The forge checks again at delivery that it is open, belongs to the same repository and is not the default branch. A fork or changed target is refused.
Retry without losing the artifact
Retryable failures use exponential backoff. Defaults start at 30 seconds, cap individual delays at 30 minutes, and stop automatic retries after eight attempts. Terminal errors and exhausted retries wait for a human decision.
A crashed submitter can leave a lease behind. The sweep reclaims expired leases so delivery can be attempted again. With a shared S3 store, another forge replica can retrieve a bundle received by the first.
Runs that already cloned can continue work that does not require the forge. Accepted bundles can wait in the outbox. Clones that need uncached refs or objects, live permission checks and forge tool calls can still fail during the outage.
Several repositories, several patches
A workspace change produces one patch per changed repository. Each follows that repository’s policy and can succeed or fail independently. Pull request reports count related parts without exposing the names or links of potentially private sibling repositories.
“Patch-only” describes Git delivery through this gateway. It does not prohibit permitted MCP tools from posting messages or modifying issues, and it does not describe local-path or direct Git modes.
Follow the implementation
See Git routes, bundle intake, submission, and patch lifecycle.