Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Unable to Create Pull Request - Default Browser Empty

When I try to do a Pull Request I get "Unable to open your web browser to ", do you have a default web browser set? 


I do have a default. I've uninstalled, reinstalled, deleted settings, done everything and it isn't helping. I can't do my job without this ability what is going on?

6 answers

1 accepted

31 votes
Answer accepted

I was having the same issue with version 3.3.4 of Sourcetree, and this is what worked for me to fix it.

  • In Sourcetree, click on the "Settings" button, located on the top-right of the screen
  • On the window that opens, in the "Remotes" tab, select your remote and click "Edit"
  • If all the information is correct in that window (it was in my case), simply click "OK"
  • Click "OK" again to to close the "Repository Settings" window

That fixed it for me. It seems to me that re-setting the URL of the repository to the same address is what does the trick. I hope it works for you as well.

Why in God's name did that just work? THANK YOU 

Like # people like this

Sadly, and I just noticed this, if you restart Sourcetree then you have to do this again.

It doesn't hold between sessions. At least not in version 3.3.4.

Like # people like this

I just upgraded to 3.3.4.  I also encountered such a problem and also find that the fix provided by this odd workaround is only temporary and doesn't hold between sessions.

I can add that I tried changing the following:

When Editing

under Remote details

in Optional extended integration

the setting for Remote Account was "Generic Account" (with "Bitbucket" chosen for "Host Type" under "Legacy Account Settings").

Instead of relying on "Generic Account", I tried changing it to the more specific Remote Account setting of "Bitbucket".  Whether that mattered at all or not, after quitting and restarting Sourcetree the Remote Account setting was back to "Generic Account".

It doesn't seem to be doing very well at remembering changes to settings.

Like # people like this


There is an interesting old Sourcetree bug from back in 2015.


The interesting part was a comment from author Sarah Wu (excerpt below) in which she also found it helpful to Edit remote repository settings and click OK without changing anything.

That said, a subsequent comment from the author indicated their company was still seeing that issue.  So it may be that she also found that workaround was only a temporary respite, not a lasting fix.

(BTW, I found this old issue that is now closed because someone else had the experience of "Unable to open your web browser to" xxx, "do you have a default web browser set?".  That seemed to be related to the fact that they were using Chrome, not IE.  However, when I tried a switch from Brave (a spin off from Chrome, but without Google spyware) to the standard recommeded MS Edge browser, it had no effect for me on the current issue.)

Temporary(?) workaround excerpt from Sarah Wu's comment (my emphasis added):

To follow up, I resolved this by doing the following:

  1. Uninstalling/Re-installing a new version of Sourcetree (I did this a few times because I was writing documentation for my company. This did not seem to have much effect, but I am listing it just in case it happened to reset something in the backend)
  2. Resetting the info for my remote
    1. Open Repository > Repository Settings
    2. Click on the repository path in the "Remotes" tab
    3. Click Edit
    4. Click OK (No need to edit anything)

Magically- the errors stopped and all methods to get a pull request to open in Stash work.

Like Francisco Acevedo likes this

I suppose since there's such an easy work around it's not worth the cycles to try to Debug and fix haha. 

Another problem with this temporary workaround is that it has to be done separately for each repository you use (and again for each if you exit and later restart Sourcetree).

Like # people like this

Most likely the correct action is to use another tool. SourceTree doesn't seem to have any quality control and issues modified old code with the same issues. There are many other tools that can do the same job (more reliable?)

Tried the work-around and it did not work for me. I assume there is another issue.

Thank you for your answer!

Just tried this work-around (on version 3.3.9) and it did the job.  Thanks!

Unfortunately, as noted, it's not a fix...

Why has Atlassian left a bug like this for (what appears to be) over 5 years?

Like Per Arne Kjelsvik likes this

I've created a new issue in the Sourcetree for Windows' Jira site.

In the meantime, while we await a fixed version of Sourcetree, is there a way to reinstall the previous version of Sourcetree (and then avoid upgrading until this Sourcetree bug is fixed)?

p.s. In you mention that the bug doesn't happen in version 3.2.4 (the last version of 3.2.* ?).  However, when I look at

it seems that the last version they have listed for Windows is 3.1.3.  Is there a way to get the last Windows 3.2.* version?

p.p.s. NOTE: No one should use any Windows Sourcetree versions earlier than 3.1.3 because of this remote code execution vulnerability.

Here is the official list of previous installers. Note that the last reported version is 3.1.3

You can access other versions not in the list if you copy one of the URLs and manually change the number. For example, manually change the last reported one

to 3.2.4

p.s. In you mention that the bug doesn't happen in version 3.2.4

You are correct. What I was trying to say is that 3.2.4 is not the version where I encountered the error. I upgraded from version 3.1.3 to version 3.3.4, but when you are creating the Jira issue you select the affected version from a drop-down list and the latest one that could be selected was 3.2.4. The version 3.3.4 was not still in the list.

Like Eric Anderson likes this

It has now been over 6 months since issue SRCTREEWIN-12482 was created, but it appears that no action has been taken to actually correct the introduction of that bug starting in 3.3.4.

MixJenkinsCI has added this comment:

"I'm on 3.3.8 and the problem is extremely irritating - can we raise the priority please - every time I restart SourceTree it has reverted back to GenericAccount and I have to set it to my user account - hordes of queries on the net about it"

Given that this is functionality that used to be working, how hard can it be to restore the past normal functionality?  This isn't a request for a new feature, or even a request for any improvement beyond the functionality that already existed prior to 3.3.4.

Like John Stanley likes this

I was using 3.3.6 just fine before, but whenever i Check For Updates from Tools->Options->Updates it always saying Sourcetree is up-to-date (can't find newer version) while i did found newer version (it was 3.3.9) at

So i decided to download and update it manually, doing Check For Updates from 3.3.9 also found a newer version ( so i updated it, and now i can no longer do pull request from Sourcetree, and there is also red exclamation mark on Remote button no matter how many times i edited remote settings :( remote settings did get saved whenever i reopen sourcetree but remote button still showing red exclamation mark and can't do pull request to github.

Agreed, I just installed 3.4.2 and now pull requests are completely broken. The workaround doesn't work any more in 3.4.2. It now remembers the settings, but the settings don't work. So now it is even worse!

I have created a Jira ticket for this
I didn't set the Priority to Low, that is set automatically by the system.

Even though there is an "accepted" answer, that was a workaround that doesn't last.  So a real fix is still needed.

(As an aside, I wonder if this issue would get more attention if it didn't have any accepted answer.)

In the meantime, this old comment about an earlier problem with pull requests and remotes admitted the following possible alternate work around (my emphasis added).

Overall, more people in my company seem to have the issue than not, so we have mostly switched to creating the Pull Request through the JIRA interface.

17th December and the problem still exist.

Is there any chance to have a fix to put under the Christmas tree ?

A formal issue SRCTREEWIN-12482 was created on Nov. 7, but has not been updated since that day.  Sadly, it is marked "Low" priority.

I would encourage anyone affected by this to add themselves to both the "Affected customers:" and "Watchers:" for that issue.

In the meantime, since the problem exists in 3.3.4 and any Windows version earlier than 3.1.3 has a software security vulnerability that should be avoided, my best recommendation is to download, install, and use version 3.2.6 (or else version 3.1.3 which also works), and then avoid automatic updates until the problem is truly fixed.

Like mcanulty likes this

This issue has finally been fixed in Sourcetree 3.4.3. It can be downloaded here:

I installed the latest version and the bug is still there...

@grrinchcan you not create pull requests in Sourcetree 3.4.3?

If you cannot, first try the workaround that was suggested here in the accepted answer, then try creating a pull request. From then on, it should keep working correctly even after restarting Sourcetree.

done that - these were the first things I did. Well, I'll wait for 3.4.4 then

Some good news, the Jira ticket related to this item has now been moved to "In Progress", with a comment saying:

We are working on fixing this and releasing a new version as soon as possible.
Thanks for the patience. Meanwhile, you can join the beta program for frequent releases

v3.3.8 still has this bug

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events