Skip to Content

Forge

The forge integration lists, reviews and merges pull requests and merge requests without leaving the repository. It talks to the provider’s HTTP API directly; it does not shell out to gh or glab.

Supported providers

ProviderPull request model
GitHubPull requests
GitLabMerge requests
GiteaPull requests
Bitbucket CloudPull requests

The provider is inferred from the remote host name. If your instance runs on a custom domain — a self-hosted GitLab or Gitea, for example — set the provider explicitly per host in Settings → Git → Forge providers. Tokens are stored per host in the operating system keychain, never in settings.json or logs.

An unsupported host simply has no forge actions. Git sync still works.

Listing

  • Pull requests lists open PRs/MRs for the repository’s remote.
  • The list loads 30 per page and is capped at 100 entries; a capped list says so instead of pretending to be complete.
  • Each row shows number, title, author, source and target branch, draft state and update time.
  • No request is made until you open the panel.

Creating

New pull request creates a PR/MR from the current branch:

  • Base branch and head branch are selected explicitly.
  • Title and body are required.
  • Draft is offered on providers whose API supports it; where it is not supported, the option is absent rather than silently ignored.

Creating a PR does not push. If the branch has no upstream or the remote is behind, push first from Sync.

Reviewing

The detail view shows the description, commits, changed files count, CI checks and existing review comments.

Checks appear as a summary with pass, fail, pending and skipped counts, plus the check names. A failing check is not a merge blocker imposed by the application; the provider decides.

Review actions:

ActionNotes
CommentRequires body text
ApproveOffered where the provider allows it
Request changesOffered where the provider allows it; requires body text

Review bodies are capped at 8000 characters and refused rather than truncated when longer. A review on a closed PR is refused before any request is sent.

Approving your own PR, or switching from approve to request-changes, follows the provider’s rules; the application surfaces the provider’s error rather than inventing a local policy.

Merging

Merge offers the merge methods the provider supports for that repository: merge commit, squash, rebase. The branch-delete option is offered where the API has one.

Before merging, the provider’s mergeability is checked. A merge that the provider rejects — conflicts, failing required checks, missing approvals — returns the provider’s message. The application does not bypass branch protection.

What the forge integration does not do

  • It does not store or proxy credentials outside the OS keychain.
  • It does not request scopes; the token’s scopes are yours to choose. A read-only token lists and reads, and write actions fail with the provider’s error.
  • It does not create releases, issues or repository settings.
  • It does not fetch repository content over the API. Diffs and files come from your local clone.

Rotating a token

Replace the token for a host in Settings. The old value is overwritten in the keychain. If a host stops working with an authentication error, check the token’s expiry and scopes at the provider before changing anything in the application.

Next

  • Sync — push before you open a pull request.
  • History — inspect the commits a PR contains.
  • Privacy — what leaves the machine when a forge call runs.
Last updated