Supported forges

The app works with any local git repository for workspaces, terminals, chat, and diff review. Some features also depend on the forge behind your git remote. When a supported forge hosts a repository, the app shows pull request or merge request metadata, checks, review state, and branch actions.

Set up forge access before you rely on these remote-aware workflows. The app runs the provider CLI locally and uses the credentials you have already configured.

Forge support

The app includes built-in forge support for:

• GitHub.
• GitHub Enterprise hosts.
• GitLab.
• Self-managed GitLab hosts when the remote hostname looks like GitLab, resolves through SSH config, or is known to the GitLab CLI.
• Bitbucket Cloud, for repositories hosted on bitbucket.org.

The forge integration model uses provider adapters and stays provider-agnostic, but each provider implements its own adapter. If another forge exposes the needed repository, pull request, branch, and check data through a local CLI, file a feature request in Discord.

Repositories without a supported remote still work for local workspaces, terminals, chat, and diffs, but lack forge-aware PR or MR metadata.

Getting started requirements

For GitHub workflows, install and authenticate the GitHub CLI:

Copy

gh auth status

For GitLab workflows, install and authenticate the GitLab CLI:

Copy

glab auth status

For Bitbucket Cloud workflows, install the bkt CLI, log in with an Atlassian API token scoped to Bitbucket, and create an active Cloud context:

Third-party Bitbucket CLI

super.engineering uses the official gh and glab CLIs for GitHub and GitLab. Its Bitbucket Cloud integration uses bkt, a third-party CLI maintained independently of Atlassian.

Atlassian’s TWG CLI also supports Bitbucket. super.engineering currently requires bkt for Bitbucket pull requests and checks.

Copy

brew install avivsinai/tap/bitbucket-cli
bkt auth login https://bitbucket.org --kind cloud --web-token
bkt context create cloud --host api.bitbucket.org --workspace <workspace> --set-active
bkt auth status

bkt needs a context for every pull request command. The app uses your active Cloud context, or selects the only Cloud context when no Cloud context is active. When you have several Cloud contexts and no Cloud context is active, the app asks you to pick one with bkt context use <name> rather than guessing between accounts.

The app runs forge commands locally and stores no separate GitHub, GitLab, or Bitbucket credentials.

Remote detection

The app inspects git remotes, preferring origin, to detect the provider and repository identity.

Supported remote styles include common HTTPS and SSH forms. For GitHub Enterprise and GitLab self-managed hosts, the app preserves the host from the remote URL and passes it to the provider CLI when needed. Bitbucket detection is limited to bitbucket.org; Bitbucket Data Center hosts are not detected.

If forge features do not appear:

1. Run git remote -v.
2. Confirm the repository has a supported GitHub, GitLab, or Bitbucket remote. The app prefers origin, but detects other named remotes.
3. Confirm the remote URL uses a supported HTTPS or SSH form.
4. Confirm gh, glab, or bkt is installed and authenticated.
5. Confirm your CLI has access to that host and repository.

Pull request and merge request state

When a PR or MR is associated with a worktree branch, the app shows:

• Review request metadata.
• Target branch.
• Checks or pipeline status.
• Mergeability and conflict state.
• Draft, open, merged, or closed state.
• GitHub unresolved review-thread counts, GitLab blocked or discussion-related merge status, and Bitbucket open task counts when available.

The active worktree polls the provider directly. Inactive worktrees rely on cached or batch-refreshed PR/MR context to reduce background traffic.

This context drives the adaptive Git action button, including failed checks, review feedback, behind-target updates, allowed merge strategies, and post-merge worktree cleanup.

Bitbucket Cloud limits

The first Bitbucket release covers pull request metadata, commit status checks, create, publish draft, merge with merge commit or squash, and new worktrees from a pull request. It does not yet cover:

• Review thread replies and resolution.
• Pull requests from forks.
• Updating a branch from the forge. Merge the target branch locally and push instead.
• Fast-forward merges. When a repository allows only fast-forward, the merge action is unavailable in the app.
• Conflict detection before merge. Bitbucket Cloud exposes no mergeability field, so the app shows an open pull request as ready and reports a conflict when the merge is attempted. GitHub and GitLab report conflicts ahead of time.
• Merge tracking across an app restart. A merge that Bitbucket is still processing when the app quits is not remembered. A second merge attempt is rejected by Bitbucket, so the pull request cannot merge twice.
• Bitbucket Data Center.

Target branch and forge branch

The app tracks its own target branch separately from the forge target branch. When the two diverge, local review summaries and remote PR metadata describe different merge targets.

Check the local target branch with:

Copy

sc worktree status --json

Then compare it to the PR or MR target branch in the forge.

Unsupported providers

For remotes other than GitHub, GitLab, or Bitbucket Cloud, the app still supports local git workflows. Use standard git commands or your provider’s CLI for PR actions, and use the app for isolated workspaces, terminals, sessions, and local review.