Create GitHub Pull Requests With an AI Agent and Human Approval

To let an AI agent create a GitHub pull request with human approval, keep a repository-scoped GitHub token in a server-side connection, route the creation request through an approval gateway, and require an owner to review its repository, branches, title, description, and draft setting before dispatch. In ActionDock, the GitHub pull requests preset provides a starting point: one repository path, POST only, and manual owner approval.

This workflow assumes the change already exists on a pushed branch. Creating the PR is a separate API write from committing code, pushing a branch, reviewing the diff, or merging. ActionDock controls the routed API request; it does not perform those Git operations or certify the code.

Prepare one repository and a narrow credential

Use a repository you own or are authorized to operate. For a first trial, choose a disposable repository with harmless changes and inspect its workflow triggers before creating a PR.

Create a fine-grained personal access token limited to that repository. GitHub’s token guidance explains repository selection, organization approval requirements, and limitations such as outside-collaborator scenarios. A token cannot exceed its owner’s access. Choose an expiration and arrange replacement before it expires.

The create-pull-request endpoint requires Pull requests: write for a fine-grained token. Do not grant Contents: write just to open a PR from an existing branch. If a different workflow needs to push code, treat that as a separate credential and execution path with its own controls.

Store the GitHub token in ActionDock’s connection form. The agent should receive only its ActionDock workspace key, kept in its host’s secret store. The credential isolation guide explains why the provider token and the agent’s gateway key have different jobs.

Configure the GitHub pull-request preset

In Connections, choose Add GitHub pull requests. Replace both path placeholders with your exact repository. For a fictional repository named acme/docs, the setup is:

The preset rejects unresolved OWNER/REPO placeholders, a broad /repos/ scope, and additional methods. Its purpose is to make a single-repository setup easier; it does not grant GitHub permissions or bypass repository policy.

A path prefix is an endpoint family, not an exact create-only permission. This prefix also matches nested paths beneath /repos/acme/docs/pulls/. Some nested PR operations use POST too. Keep the provider token narrow and inspect the full method, path, and body of every proposal. Do not interpret the preset’s name as a guarantee that every permitted request merely opens a draft PR.

The preset uses a manually supplied bearer credential. It does not install a GitHub App, run an OAuth consent flow, or renew GitHub tokens. The current connection and approval documentation describes the supported gateway contract.

Submit the PR creation as one bounded job

Suppose automation/api-docs is already pushed to acme/docs, with main as the intended base. Replace the connection UUID below with the one returned by ActionDock discovery or your dashboard. This is an illustrative request contract, not a live-provider test.

Send POST https://actiondock.app/v1/actions/integration.execute with these headers:

Authorization: Bearer <ActionDock workspace key from the host secret store>
Idempotency-Key: docs-api-pr-create-v1
Content-Type: application/json

Use this request body:

{
  "workflowId": "docs-api-pr",
  "workflowName": "Propose API documentation update",
  "input": {
    "connectionId": "11111111-1111-4111-8111-111111111111",
    "method": "POST",
    "path": "/repos/acme/docs/pulls",
    "body": {
      "title": "Document API response handling",
      "head": "automation/api-docs",
      "base": "main",
      "body": "Clarifies response handling. The proposed diff is ready for maintainer review.",
      "draft": true
    }
  }
}

GitHub uses head for the source branch and base for the destination branch. This example stays within one repository; cross-repository PRs have additional requirements in GitHub’s API contract.

ActionDock returns a durable job that waits for owner approval. Retain that job ID and the same idempotency key for the same logical submission. Neither the agent’s workspace key nor an instruction in the prompt can release the write; a signed-in workspace owner must decide in the dashboard.

Review the request and the branch separately

Before releasing the job, the owner should check:

1. The destination is the intended api.github.com connection and repository.
2. The request is exactly POST /repos/acme/docs/pulls, with the expected source and base branches.
3. The title and description accurately describe the proposed change and contain no secrets or unrelated instructions.
4. draft is true if the agreed handoff is a draft PR.
5. The actual branch diff and current head commit are the ones the team intended to propose.

ActionDock binds approval to the connection version and exact request snapshot. Changing those request details requires fresh approval. The human approval guide covers that binding.

However, a branch name in JSON is a mutable reference. An unchanged head: "automation/api-docs" can point to a different commit after another push. ActionDock’s preview does not freeze that branch, inspect its Git objects, or bind approval to its code diff. Record the expected commit, control who can update the branch during review, and compare the created PR’s actual head and diff with that expectation. Writing a commit SHA in the description documents intent; it does not enforce it.

Confirm creation before continuing

A successful GitHub creation response is 201 Created. Inspect the saved provider response and open the resulting PR in GitHub to confirm its repository, source commit, base, description, and draft state. A succeeded gateway job records the response ActionDock observed; it does not mean the PR was reviewed, merged, or deployed.

The preset is POST only, so it cannot also run integration.fetch for verification. Use the GitHub UI or a separately configured, narrowly scoped read connection. Adding GET to the preset is not a supported shortcut.

If the job becomes execution_unknown, stop and inspect GitHub for an existing PR from the intended branch before proposing another creation. A lost response can conceal a successful write. Reusing the ActionDock idempotency key retrieves the existing job; a fresh key is a fresh proposal, not proof that GitHub needs another request. Follow the retry and reconciliation guide.

Keep repository review and CI protections in place

GitHub’s draft PR documentation says drafts cannot be merged until their stage changes. Draft status is a collaboration state, not a sandbox. PR events can still trigger configured workflows. Inspect what those workflows execute and which credentials they receive.

This matters in current security news: GitHub’s November 2 announcement schedules default blocking of pull_request_target for public repositories from December 2, 2026, unless an applicable event policy allows it. As of this guide’s November 5 publication, that enforcement is still upcoming; private and internal repositories are outside that change. Audit your current settings rather than assuming the future default already protects them.

GitHub also warns against running untrusted PR code with pull_request_target, because privileged workflow context can expose write access or secrets. ActionDock’s approval of PR creation does not change that CI context, supply code review, or enforce merge requirements.

The practical boundary is one routed write. Keep direct GitHub tokens, authenticated browsers, shell tools, and alternate MCP integrations out of the agent’s reach when they would make this gateway optional. Start with one authorized repository, inspect one draft-creation request, verify the resulting PR, and leave code acceptance to the repository’s review process.