Obsidian doesn't use default browser on Ubuntu 22.04

Still same here… I’m so frustrated it’s insane. I have tried everything with xdg-mime, xdg-settings, .desktop files, update-alternatives and everything was set to Brave snap - still nothing. I uninstalled the Brave snap and installed the deb package, still nothing. I uninstalled every possible browser on my system and FINALLY I saw that a new browser windows opened up (not the new tab - which sucks equally as bad!). The cherry on the is present on the screenshot below. Somehow the browser window is considered to be an “Obsidian” process instead of running the actual app. Spaghetti must be strong with this one.


Fix in my case

  1. If xdg-open works fine from console but obsidian still opens wrong browser, and you are using Snap you can use following hack to fix it:
  • ensure that ~/bin is on your PATH (echo $PATH) - or use different location
  • create ~/bin/xdg-open with following content:

# fix for obsidian opening URLs in wrong browser
if [[ $SNAP_INSTANCE_NAME == "obsidian" && $1 =~ ^(https?://) ]]; then
        unset XDG_DATA_HOME
        unset XDG_CONFIG_HOME

exec /usr/bin/xdg-open "$@"
  • save the script
  • make it executable: chmod +x ~/bin/xdg-open

Now obsidian should run correct browser.

DISCLAIMER: There may be some unexpected downsides coming from this solution. It wasn’t tested very deeply. USE AT YOUR OWN RISK. Maybe there is better solution but this piece of “duct tape” solved my case :wink:

  1. If xdg-open run from the console opens wrong browser, use the solution suggested by others (to fix your system level configuration):
xdg-mime default google-chrome.desktop x-scheme-handler/http
xdg-mime default google-chrome.desktop x-scheme-handler/https

Why this (1) works?

From my quick investigation:

  • strace shows that obsidian searches for xdg-open on PATH and invokes the first one found
  • xdg-open executed from console normally opens the right browser
  • xdg-open executed by obsidian opens wrong browser

After comparing the env output I’ve spotted that Snap crates it’s own XDG “environment”, where especially the two variables cause trouble (although there may be more…):


The XDG_CONFIG_HOME messes with configuration (which browser should open) and the XDG_DATA_HOME messes with browser (at least chrome does respect this variable - Chromium Docs - User Data Directory - and due to this it starts new process with empty profile).

So removing those two from environment before invoking real xdg-open falls back to your default config.


@osomdev Thanks for sharing your findings!

How can I do that when starting obsidian from the launcher icon (I am using Ubuntu 23.10) ? Will it not use a the Ubuntu default PATH in that case? And that PATH will not include ~/bin I guess. I observed that I have xdg-open installed in both /bin and /usr/bin. I tried to replace the /bin/xdg-open with the script you provided, but when I click a link in obsidian it just hangs (nothing happens, it does not even open the link in the wrong browser). (After reinstalling the original version of the xdg-open in /bin/xdg-open obsidian opens the link in the wrong browser again)

Any changes for this bug to be fixed without any witchcraft?

Hi again,

A comment on the findings posted by @osomdev. Maybe it helps someone.

I went into my obsidian snap installation directory
~/snap/obsidian/x2/.config and I found that it indeed has a mimeapps.list file which has firefox a the default application.

Naively, I attempted to change this to chrome, and It semi-worked. I got obsidian to open links in chrome, however, it always opening a new window (Perhaps because I am using several different chrome profiles). I would of course want it to open a new tab in the currently opened (or latest used) chrome window as is usually the case.

I can only assume that I encountered the empty profile mentioned in:

the XDG_DATA_HOME messes with browser (at least chrome does respect this variable - Chromium Docs - User Data Directory - and due to this it starts new process with empty profile).

After trying out osomdevs xdg-open script my problem went away, and everything works great!

@hakonhagland You should probably not replace any existing binaries. I assume that osomdevs script (which is a wrapper) works by ~/bin being earlier in the PATH than wherever your usual xdg-open binary is located, thereby executing the wrapper first, which in turn does: exec /usr/bin/xdg-open "$@"

I placed mine in ~/.local/bin/xdg-open and that worked fine

I have the same problem. This workaround from @osomdev worked for me as well, thanks!

It would be great to see this fixed in Obsidian.