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

[Harper_ Peter]

Hi

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

[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

[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]

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.

[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.

[Gabriela]

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!