Sourcetree Authentication Failures: A Diagnostic Guide to Credential, Token, and Git-Mode Problems

Fetch, pull, or push fails in Sourcetree with "authentication failed", a 403, or an endless credential prompt — yet the same account logs into GitHub or Bitbucket in a browser without trouble. That combination almost always means the problem is not your account but a stale or wrong-type credential cached by Sourcetree or your operating system. This guide walks through recognizing the condition, isolating the cause, applying the matching fix, and knowing when to stop troubleshooting the client.

Recognizing the condition

The typical symptoms cluster into three patterns:

• An operation that worked last week now returns authentication failed or HTTP 403 with no change on your side.
• Sourcetree prompts for credentials repeatedly, and entering them again does not stick.
• The browser login works, but Git operations fail — a strong hint that the host no longer accepts your account password for Git and expects a personal access token (PAT) or app password instead.

A PAT is a generated token that replaces your password for Git-over-HTTPS operations, scoped to specific permissions such as repository access. GitHub removed password authentication for Git operations in 2021, and Bitbucket requires app passwords in similar situations, so any stored password credential is a prime suspect.

Cause and diagnostic table

Ordered checks before changing anything

1. Confirm the remote URL protocol. In Sourcetree, open the repository settings and look at the remote URL. https://... uses PAT/OAuth credentials; git@... uses SSH keys. The credential you fix must match the protocol in use.
2. Reproduce in a terminal. Run git ls-remote <remote-url> from a terminal (no admin rights needed). If this works, the credential is fine and the problem is inside Sourcetree. If it fails identically, the credential itself is the issue and no Sourcetree setting will help.
3. Inspect the OS credential store. On Windows, open Credential Manager → Windows Credentials and look for entries like git:https://github.com. On macOS, open Keychain Access and search for the host name. Duplicate or old entries here are a frequent cause of prompt loops.
4. Check Sourcetree's account settings. On Windows: Tools → Options → Authentication. On macOS: Sourcetree → Preferences → Accounts. Menu names vary between versions and platforms, so verify against your installed release.
5. Compare Git versions. Run git --version in a terminal and compare it with the version shown under Tools → Options → Git in Sourcetree. A large gap can mean divergent credential-helper behavior between the GUI and CLI.

Fixes tied to findings

Stale OS credential entry

Delete the git:https://<host> entry from Credential Manager or Keychain Access, then retry a fetch in Sourcetree to trigger a fresh prompt. Warning: this affects every tool that authenticates to that host from your machine — command-line Git, other GUIs, CI scripts — so expect to re-enter credentials elsewhere too.

Password where a PAT is required

On the host's security settings page, generate a new PAT with repository scope (on GitHub, the repo scope for classic tokens). When Sourcetree prompts, enter your username and paste the token as the password. Confirm on the host's token page that the token exists, is unexpired, and has the scopes you granted.

Out-of-sync OAuth account

Remove the hosting account from Sourcetree's Accounts/Authentication settings and add it again, completing the OAuth sign-in flow in the browser. This refreshes the token Sourcetree holds independently of the OS credential store.

SSH problems

On Windows, Sourcetree can use Pageant (the PuTTY agent) or OpenSSH; check which is selected under Tools → Options → General → SSH Client Configuration. Load your key into the matching agent, then verify with ssh -T git@<host> in a terminal. If the remote URL is still HTTPS, convert it to SSH form (git remote set-url origin git@<host>:<owner>/<repo>.git) or fix the HTTPS credential instead — do not mix the two.

Embedded vs system Git

Under Tools → Options → Git, Sourcetree lets you choose its bundled (embedded) Git or the system-installed Git. Embedded Git is version-pinned and predictable across updates; system Git receives security patches faster and shares credential-helper configuration with your terminal. If CLI Git works but Sourcetree does not, switching Sourcetree to system Git often aligns the credential-helper behavior and resolves the discrepancy. After switching, retry a fetch and watch for a fresh credential prompt.

Verifying the fix

After each change, run a fetch in Sourcetree and confirm the operation completes without a prompt loop. Cross-check with git ls-remote <remote-url> in the terminal — both paths should now succeed with the same credential. If only one succeeds, revisit the embedded/system Git setting and the OS credential store.

When to escalate

Stop troubleshooting the client when a terminal test with a freshly generated, correctly scoped PAT also fails. At that point the cause is server-side: organization-enforced SSO that the token is not authorized for, IP allowlists blocking your network, or a token revoked by an administrator. Collect the exact error message, the host, and the timestamp, and hand it to your repository or identity administrator — further client-side changes will not help and may destroy working state.