nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

SourceTree git authentication against BitBucket only works some of the time.

Harper_ Peter

First off we all know about the removal of the app passwords method of authentication. I thought I had changed this some time ago and all worked fine. I assume that you have permanently removed this method of authentication from BitBucket.

So why, purely at random at different times of the day, do I sometimes still get this error message when trying to push/pull using SourceTree and then at other times it works.

My account is set up to use OAuth and when I check it in the authentication screen it connects fine.

This is just wasting hours of our time, thousands of pounds, all because of your lousy product and it's labyrinthine authentication methods. This is one Atlassian product attempting to talk to another and failing. Setting up authentication should just not be so complicated.

Error message:-

git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks push -v origin main:main
remote: CHANGE-3222 - Functionality has been deprecated
remote: App passwords are deprecated and must be replaced with API tokens.
remote: https://developer.atlassian.com/cloud/bitbucket/changelog#CHANGE-3222

SourceTree version:- 3.4.30

Accepted answers

All comments

Gabriela - LeanZero

That error only fires when an app password is actually being sent. So despite SourceTree showing OAuth connected, git is still reaching for a cached app password on the pushes that fail, which is why it's intermittent.

SourceTree's account auth and what git actually hands the remote on a push can be two different credentials. The old Bitbucket app password is still sitting in your OS credential store — Keychain on macOS, Windows Credential Manager, or whatever git credential helper you use — and it gets picked up on some operations. Clear the bitbucket.org entry there, then let SourceTree re-authenticate so only the token path is left.

Also check the remote itself with git remote -v. If it's an https URL with a username baked in, that pins it to the old credential regardless of what the account screen says.

Tomislav Tobijas

Hey @Harper_ Peter

Yeah... this isn't ideal for sure. There have been some discussions around this here https://community.atlassian.com/forums/Sourcetree-questions/app-password-warnings-after-updating-Bitbucket-account-in/qaq-p/3252148

People listed a couple of solutions but I am not sure which one will work. 👀

I am not near device with Sourcetree, but I could take a better look next week, although current things do not look that promising.

Cheers, Tobi

Harper_ Peter

Well that error message appeared early this morning - setting my work back half an hour before I went into two meetings. Two hours later - without even closing and reopening SourceTree I have attempted to push the commit - and it has worked. I have done absolutely nothing to change the SourceTree set up or the remote repo set up.

Viswanathan Ramachandran

hi @Harper_ Peter see relevant thread https://community.atlassian.com/forums/Sourcetree-questions/Setting-up-API-Token-with-SourceTree/qaq-p/3260075#M47478

Gabriela - LeanZero

That on/off pattern isn't random — it's the brownout schedule. Atlassian is retiring Bitbucket app passwords (CHANGE-3222) with scheduled windows at 00:00, 06:00, 12:00 and 18:00 UTC, and this week they're running about 3 hours each. Inside a window, anything still authenticating with an app password fails with that CHANGE-3222 error; once the window passes, the same setup works again with nothing changed on your end. That's your "appeared this morning, worked two hours later."

So the error is really telling you that something on your machine is still pushing the old app password, even though SourceTree shows your token connected — the brownout only makes it visible on a schedule instead of constantly. It stops being intermittent on July 28, when app passwords are removed for good.

Either way, clear that stale credential now: remove the bitbucket.org entry from your OS credential store (Keychain, Windows Credential Manager, or your git credential helper), and check git remote -v for an https URL with a username baked in. Once only the API token is in play, the brownouts won't touch you.

Harper_ Peter

Why the hell would you do that - to really annoy your customers - just turn it off!

Harper_ Peter

Even if I have no authentication details in SourceTree at all (no account, no stored passwords and I have cleared all entries in the Windows credential manager) when I attempt a pull I still get exactly the same error. I dont get a "set up authentication first" type message. So is it a fair assumption that under the covers SourceTree is using the git credential manager? There is a tick box in the SourceTree git set up screen that should stop it using that but appears to have no effect.

Gabriela - LeanZero

That's exactly it. Git over HTTPS asks a git credential helper for credentials, not SourceTree, and on Windows that helper is the Git Credential Manager. So even with SourceTree emptied and no Windows Credential Manager entry, git's own helper config still kicks in and hands over whatever it has cached, which is why a pull errors instead of prompting you to set up auth.

The SourceTree checkbox is unreliable because it only affects SourceTree's Embedded Git. If SourceTree is set to System Git (Tools > Options > Git), that toggle doesn't touch your system git's helper at all.

To see what's actually configured, run this in the repo:

git config --show-origin --get-all credential.helper

That prints every credential.helper line and which config file it lives in (system, global, or repo). You'll likely see helper = manager or manager-core. To stop git reaching for the cached credential, clear that helper:

git config --global --unset-all credential.helper

(or edit the file it named and delete the helper line). Then the next pull prompts fresh, and you enter x-bitbucket-api-token-auth as the username with your API token as the password.

To keep a helper but drop only the stale entry, GCM stores it under git:https://bitbucket.org, so erasing that one does it: printf "protocol=https\nhost=bitbucket.org\n\n" | git credential-manager erase.

Harper_ Peter

Re the tick box. I am using the embedded git but it has no effect.

Now the problem is that uninstalling sourcetree still leaves all sorts of git config files lying around and so when you reinstall it it just picks up where you left off.

I haven't installed another version of git anywhere.

This is just consuming so much time and that ridiculous brown out policy just increases the amount of time between testing.

Gabriela - LeanZero

That leftover-config thing is the actual root of it, and you don't have to hunt for the files by hand. Git will name them for you. Run this in a repo:

git config --show-origin --get-all credential.helper

Each line comes back prefixed with the exact file it's read from, something like file:C:/Users/you/.gitconfig or a path under the embedded git. That's your list of the config files lying around. Your global ~/.gitconfig (C:\Users\<you>.gitconfig) is the one that survives every SourceTree uninstall, so a stale helper = manager sitting there is why a reinstall carries on where it left off.

Once you see which file holds it, clear it:

git config --global --unset-all credential.helper

or open the file it named and delete the helper line. After that the next pull actually prompts instead of silently replaying the cached credential, and you put x-bitbucket-api-token-auth as the username with the API token as the password.

On the embedded-git checkbox doing nothing: even on Embedded Git it only stops SourceTree's own helper. It can't strip a helper line already written into your global config, so the config edit above is what actually settles it.

And yeah, the brownout makes this miserable to debug because your test either works or doesn't depending on the window. The one upside is it ends for good on 28 July, so this stops being a moving target soon.