Skip to content
Account

Preview · Review mode ⌘4 · Production publication pending

Provider APIs are the extra. Git remotes always work.

Connect GitHub.com, GitHub Enterprise Server, GitLab.com, or GitLab Self-Managed and read pull or merge requests, discussion, and checks or pipelines beside the repository they belong to. Every host still works as an ordinary Git remote without a connection.
Compare plansDownload GitAegis

Optional provider layer · GitHub and GitLab · Cloud and self-hosted · No integration is required by local Git or recovery

The API layer: GitHub and GitLab

Pull and merge requests, reviews, comments, checks and pipelines are read next to the repository. Provider writes remain planned.

The substrate: Git, for every host

Bitbucket, Azure DevOps, Gitea, a bare server you own, or any standards-compliant remote. Their Git operations stay in the same local Git and recovery layer.

The recovery layer, underneath both

Capsules, the Flight Recorder, Lost Work, Safe Mode and Doctor are local, and never ask who hosts the repository.

Nothing in the Git path and nothing in the recovery layer depends on a provider connection.

Two failure modes, and the second one is worse

The first: a client with no provider integration at all. You switch to a browser to read a review comment, then back to check what the diff actually was, then back again. Annoying, survivable.

The second, and the one worth avoiding: a client that only works properly with the providers it integrates. The Azure DevOps repository is a second-class citizen. The self-hosted Gitea works, sort of. The Bitbucket repository a client insists on is a permanent source of friction.

GitAegis draws the line explicitly. Nothing in the Git path and nothing in the recovery layer depends on a provider connection, and a provider outage cannot strand a repository.

Git is the substrate and every host works. GitHub and GitLab add an optional, explicitly linked API layer on top.

What a provider connection does

Four read surfaces. No provider write.

The completed desktop path is read-oriented. Lower-level adapter experiments are not a user workflow and are not advertised as one.

  • Discover and link repositories

    read

    List repositories visible to one connected account, match exact HTTPS or SSH remotes, and let you confirm which local remote the provider repository belongs to.

  • Read pull and merge requests

    read

    Open, draft, merged and closed work from GitHub or GitLab, with its branches, author, labels and provider state beside the local repository.

  • Read reviews and discussion

    read

    Reviews, issue comments and line-level review comments when the provider exposes them. The current workflow reads discussion and sends no reply or review submission.

  • Read checks and pipelines

    read

    GitHub check runs and commit statuses, or GitLab pipeline state, with the provider link needed to inspect the run at its source.

GitAegis's diff viewer rendering a local change, with per-hunk stage controls and the commit box beside it.
The files a pull request touches render through this same diff engine: the one reading a local working-tree change here.

How a connection works

Worth reading before you approve one, because two of these five steps are usually described less precisely than they should be.

  1. You choose the provider, host, account, and custody model.

    GitHub.com and GitLab.com can authorise in the browser through the configured gateway once GitAegis is registered as an application with them. It is not yet, so browser authorisation reports itself unavailable and a personal access token is the way in. A token is also the route for self-hosted instances. Provider credentials are distinct from Git transport credentials.

  2. The grant is provider-specific and never inferred.

    GitHub App permissions are configured on the installation. GitLab browser auth asks for read_user, api and write_repository. For a PAT you choose the grant; GitAegis validates the account but does not claim a scope the provider did not prove.

  3. Credential custody is shown, not blurred together.

    A local PAT is validated on the Mac and stored in Keychain. Browser authorization is completed by the configured gateway, which keeps the provider token envelope-encrypted and returns only connection metadata to the desktop.

  4. The traffic path follows that custody choice.

    Keychain/PAT connections call the configured GitHub or GitLab API from the Mac. Browser-authorized connections call it through the gateway so the token never has to be copied into the desktop.

  5. Disconnect locally; revoke at the provider when required.

    Disconnect removes GitAegis’s connection, repository links, and any local Keychain token. A PAT remains valid anywhere else until you revoke it on GitHub or GitLab; the interface does not call local deletion global revocation.

Local PAT on your Mac

The PAT stays in the macOS keychain and the adapter calls the exact GitHub or GitLab origin you configured.

GitHub or GitLab

Read-only repository metadata, pull or merge requests, discussions, checks and pipelines. Revoke a PAT at the provider when you no longer want it to exist.

Browser authorization is the alternative

The GitAegis gateway completes authorization, keeps the provider token envelope-encrypted, and brokers the read requests. The desktop receives connection metadata, not the token. Disconnect revokes the provider grant first and deletes the envelope only after confirmation.

A provider connection uses one credential path: a local PAT or browser authorization. The token is not copied between them.

Repository linking is explicit

Discovery can suggest an exact match between a provider repository and an HTTPS or SSH remote. It never treats a host-name guess as authority and never silently rewrites a remote.

You confirm the account, provider repository, and local remote. Unlinking removes that association without removing the local repository or its Git remote.

The operation model

GitAegis
The GitAegis Operation Preview drawer for a hard reset, showing the operation's intent, a Destructive risk badge, the recovery capsule that will be taken first and what it covers, and the rollback that will be available afterwards.
The Operation Preview drawer: the intent, the risk, the capsule that will be taken before anything runs, and the way back. The exact command list sits further down the same drawer.

Every other host works, as Git

This is the part that should not need saying, and does.

  • Bitbucket
  • Azure DevOps
  • Gitea and Forgejo
  • SourceHut
  • AWS CodeCommit
  • A bare repository on a server you own

Clone, fetch, pull, push, force-push-with-lease, tags, submodules, LFS, and every one of them planned, checkpointed and journalled exactly as it would be against a linked GitHub or GitLab repository.

The recovery layer does not know or care who hosts your repository. Capsules, the Flight Recorder, Lost Work, Safe Mode and Doctor are local features operating on a local repository. What a repository without a connection does not get is provider review context.

The Git toolkit

What the integration does not do

It reads. It does not administer.

It does not replace your provider. Branch protection, required reviews, merge queues, org permissions and repository settings live on your host and are enforced there. GitAegis reads that state; it does not administer it and cannot override it.

It does not write. It does not create or update a pull or merge request, merge one, submit a review, comment on a line, reply to or resolve a thread, re-run a check, or apply a provider’s suggestion. Those happen on your host.

There is no live feed of provider state. No webhook-driven updates, no backfill when a repository is first connected, no reconciliation after a gap, and no freshness stamp on the panel. What you see was fetched when it was fetched.

Rate limits are the provider’s. Under an aggressive rate limit, refresh is slower, and GitAegis cannot raise your quota.

Which hosts, precisely

GitHub and GitLab. The connector types are GitHub.com, GitHub Enterprise Server, GitLab.com, and GitLab Self-Managed. Bitbucket, Azure DevOps, Gitea and other hosts remain Git-only.

Self-hosted instances use a PAT and an explicit HTTPS base URL. Browser OAuth for an arbitrary enterprise installation needs per-instance app registration and is not claimed. A desktop-local PAT can reach an HTTPS host visible on that Mac’s LAN or VPN and uses the macOS trust store. A hosted gateway PAT is limited to a safe, publicly reachable HTTPS origin; private-network access needs a separately provisioned connector. The public support matrix also remains gated until certificate and network failures are qualified against live hosts.

Multiple accounts and hosts are explicit. A connection carries provider, origin, and provider user identity. Reconnect refuses a different host or identity instead of silently moving repository links, and a second account is added as a separate connection.

Nothing in the recovery layer needs any of this. Capsules, the timeline, Lost Work, Safe Mode and Doctor are local and account-free. A repository with no connection gets identical recovery behaviour to one with a bound account. Recovery capsules →

Questions about integrations

GitAegis Cloud

Your recovery history shouldn't live on one laptop.

Capsule backup, multi-device recovery, shared workspaces, and org policy.

Start free trial

30 days of Pro. No card is taken, so nothing is charged and nothing renews by itself. When it ends, GitAegis keeps opening your repositories: history, undo, capsule restore and export never stop. What waits for a subscription is making new work.

What Cloud adds

  • Capsule backup

    encrypted on your device, uploaded after the operation finishes

  • Multi-device recovery

    restored on a replacement machine with your recovery key

  • Shared workspaces

    Change Sets, sessions, and branch leases

  • Org policy

    signed rules, applied as preconditions

The local edition stays complete on its own: every operation, every capsule, every restore.