Git credentials

Provider integration tokens and git transport credentials are two different things: the former talk to REST/GraphQL APIs, the latter let git fetch and git push through. This page covers the transport side — the Git credentials section of Settings that shows your credential helper, stores HTTPS tokens per host, and points at your SSH key.

Two kinds of credentials

	Integration tokens	Git transport credentials
What they authenticate	Provider APIs: PR sync, the Inbox, issue status	git fetch, git pull, git push
Where they’re configured	The provider cards in Settings → Integrations — see Integrations	The Git credentials section below those cards
Examples	A GitHub PAT pasted into the GitHub card	A credential helper, an HTTPS token for a host, an SSH key path

Connecting a provider account does not by itself make git push work, and a working git push does not connect an account. If PRs sync but pushes fail (or vice versa), you’re looking at the other kind of credential.

Where it lives

Open Settings (⌘, / Ctrl+,) → Integrations. Below the provider cards, a divider introduces the Git credentials section with three parts: helper status, HTTPS tokens per remote, and the SSH key.

Credential-helper status

Birch reads your global credential.helper git config and reports one of:

• Credential helper active: <helper>
• No credential helper configured — Git will prompt for HTTPS credentials.

“No helper” matters more in Birch than in a terminal: Birch runs git fetch in the background roughly every five minutes, and a background process cannot answer an interactive username/password prompt — those fetches simply fail. Configure a helper in the Git Config pane (credential.helper, e.g. osxkeychain on macOS or manager on Windows) so HTTPS operations authenticate silently.

HTTPS tokens per remote

Birch scans the remotes of every registered repository and lists one row per HTTPS host it finds (e.g. github.com, a self-hosted GitLab). For each host you can:

• Paste a personal access token and click Save — the token is stored in your system keychain, never in Birch’s database. A saved host shows ✓ token stored.
• Click Forget to delete the stored token from the keychain.

With no HTTPS remotes anywhere, the section shows No HTTPS remotes found across your repositories.

SSH key

For SSH remotes, the SSH key block shows either Git is using SSH key: <path> or No SSH key configured (core.sshCommand is unset).

• Choose key… opens a file picker; selecting a private key writes the global git config core.sshCommand = ssh -i "<path>", so every repository’s SSH operations use that key.
• Clear unsets core.sshCommand, returning git to its default SSH behavior (~/.ssh keys, your SSH agent, and ~/.ssh/config).

Because this is global git config, it also affects git run from your terminal, not just from Birch.

Fetch, push, and auth errors

Birch’s background fetch and every push/pull you trigger go through ordinary git transport, so authentication failures are ordinary git failures:

Symptom	Likely fix
HTTPS: Authentication failed on fetch/push	Configure a credential helper (above); for hosts that require tokens, use a personal access token as the password. Note GitHub and most hosts no longer accept account passwords for git over HTTPS.
HTTPS: pushes work in the terminal but background fetch fails	Your terminal answers prompts; background git can’t. Set credential.helper so credentials are cached.
SSH: Permission denied (publickey)	Set the key with Choose key…, or clear it if your ~/.ssh/config / SSH agent already selects the right key and the override points at the wrong one.
A single host keeps failing	Check that host’s row under HTTPS tokens per remote — a stale stored token can be replaced with Save or removed with Forget.