We have configured chrome to open tel: links with Skype. One computer it does not open straight Skype after clicking a tel-link, but asks if skype should be opened (in a popup).

I tried to reset Chrome and tried to change the handler to another software to test if the problem maybe is with Skype. But it seems Chrome is generally asking for confirmation before opening an external application.

How can we configure Chrome to not ask for confirmation over and over? This is on Windows 10.

| |
  • Doesn't the popup have a checkbox to always allow that specific link type? – user1686 Sep 12 '19 at 11:05
  • @grawity No it does not. Just "Open" or "Cancel". – sieppl Sep 12 '19 at 11:37
  • Chrome developers see you as the product they can sell to advertisers. – null Apr 15 at 10:12

11 Answers 11


This can now be done with Chrome 79+. Thanks to the Reddit link from @Kropotoff's earlier answer, you can restore the "Always open these types of links in the associated app" option by updating your system settings.

For Windows:

Apply the "External​Protocol​Dialog​Show​Always​Open​Checkbox" registry policy

Or edit the registry and add a REG_DWORD registry entry to:


For macOS:

defaults write com.google.Chrome ExternalProtocolDialogShowAlwaysOpenCheckbox -bool true

At least on Mac, it seems you need to quit and restart Chrome before the option becomes available.

Another Method

As an alternative to enabling the checkbox, then launching Chrome to select the checkbox, and ensuring it is persisted in the Chrome profile, it also appears to be possible to whitelist specific protocol handler URIs via the command line. This is helpful for Selenium and other automation, meaning that the URIs open without user intervention and you don't need to pre-configure the browser.

Assuming that your protocol handlers are myprotocol1://whatever and myprotocol2://whatever, you can do this on Mac. If you go this route, it doesn't look like you need to bother with the checkbox setting above.

defaults write com.google.Chrome URLWhitelist -array 'myprotocol1://*' 'myprotocol2://*' 'myprotocol3://*'

I have not tried this on Windows, but it looks like there is guidance on the enterprise policy page for URLWhitelist.

| |
  • regedit fix works – Leos Literak Feb 5 at 8:02
  • 3
    How about Linux? – Eric Apr 16 at 10:45
  • defaults write worked for me for macOS Chrome, but would love equivalent for Edge. "defaults read com.microsoft.Edge ExternalProtocolDialogShowAlwaysOpenCheckbox" says it's invalid. – SilverSideDown May 7 at 13:11
  • For Yandex Browser on MacOS: defaults write ru.yandex.desktop.yandex-browser ExternalProtocolDialogShowAlwaysOpenCheckbox -bool true – ckesc May 12 at 23:55
  • 1
    The option is not working on Chrome Version 84.0.4147.89. Any suggestions? – Mike Jul 15 at 21:57

Simple fix for Windows - make a .reg file with the following inside it and run it:

(For Chrome and chromium Edge)

Windows Registry Editor Version 5.00


| |

Solution for Linux

sudo mkdir -p /etc/opt/chrome/policies/{managed,recommended}
echo '{"ExternalProtocolDialogShowAlwaysOpenCheckbox": true}' | sudo tee /etc/opt/chrome/policies/managed/protocol_open.json > /dev/null

If you are using chromium instead of chrome then use /etc/chromium instead of /etc/opt/chrome.

No restart required.

From the chromium administrators documentation

| |
  • Thanks, this works indeed without restart. – user84207 Sep 5 at 17:25
  • Thanks a lot; however this only allows a permanent setting per site. See my answer for a more general per-protocol solution. – Adam Spiers Sep 24 at 11:19

Found this while trying to fix the same sort of issue. My new win10 install with current chrome would ask if chrome could open utorrent, similar to my work machine asking to open citrix launcher every time I start a virtual machine.

What worked for me:

Chrome settings - Site settings - Handlers - Do not allow any site to handle protocols - DISABLED

Then when I hit a magnet link, the same confirmation box opens but has a checkbox to always remember this choice. Subsequent magnet links now open directly into utorrent with no notification. I assume the tel: uri would behave the same when selecting the app of your choice. Let us know!

| |

I'm having the same issue different OS. Did Google release a chrome update that removed the "don't ask again" checkbox?

EDIT: my research is not encouraging: https://www.reddit.com/r/chrome/comments/d3v4yr/dont_ask_again_checkbox_on_popups_not_available/

Seem like there was indeed an update that removed this feature.


| |
  • that is annoying finding, thanks – Leos Literak Feb 5 at 7:58

If you don't know how to get it done. I've created a simple application to make it work seamlessly for both mac and pc. https://www.sendwhatsappmsg.com/open-whatsapp-desktop

| |

I see this is old, & I have no way to test, but nobody mentioined settting the tel: protocol via Settings>Apps>Default apps>(tiny link)Choose default apps by protocol: enter image description here

| |

I was never able to get the Checkbox to show. However, I was able to get the dialog suppressed by adding the ExternalProtocolDialogShowAlwaysOpenCheckbox setting and Edge URLAllowlist and Chrome URLWhitelist. Having both of these configured allows the link to run without nagging. I made the following changes to the registry. One for Chrome and one for Edge.

I put Skype in the URL List shown below; however I used another protocol that was specific to my organization.

For Edge: (This appears to only work for new Edge built on Chromium)



For Chrome:


| |

In my case, I would like to DISABLE the association of the WhatsApp Windows Application with the URL:whatsapp protocol in Chrome (however it works for any browser) so that the popup does not appear again. I've tested on Windows 10.

Solution: I accessed regedit and deleted the HKEY_CLASSES_ROOT\whatsapp\ node.

| |

Updated answer for Linux, Sept 2020

I know the original question was for Windows, but the answers and comments clearly show appetite for an answer for Linux too. This is an update to @tacoscool's answer which is very helpful, but only covers the ExternalProtocolDialogShowAlwaysOpenCheckbox policy for ensuring the "Always open..." checkbox is visible.

If instead you want to skip the dialog for a certain protocol (e.g. tel:..., or org-protocol:... for capturing within Emacs's Org mode) across all sites without any prompting, as requested by the original question, you need to use the URLWhitelist policy for Chrome 85 and earlier, and URLAllowlist for Chrome 86 and later. If you are on 85 or earlier but want a future-proof solution, you can combine them both into a single file, e.g.

sudo bash
mkdir -p /etc/opt/chrome/policies/{managed,recommended}
cat <<EOF >/etc/opt/chrome/policies/managed/allow_tel_protocol.json
  "URLWhitelist": [
  "URLAllowlist": [

Presumably this file could be placed in /etc/opt/chrome/policies/recommended instead of /etc/opt/chrome/policies/managed but I haven't tested that.

You can verify that these files are having the correct effect by visiting chrome://policy.

Note that this is a policy which will take effect for all users. If you want to set it per user then I think you have to find the equivalent key in the user profile's preferences JSON file, which is typically ~/.config/google-chrome/Default/Preferences or similar on Linux. According to other posts, it should be enough to ensure that you have something like


in this Preferences file (I wonder why it's false not true, but OK whatever...). However when I shut down Chrome, edited the file, and restarted Chrome, it automatically removed that setting every time. Maybe I was doing something wrong, or maybe this no longer works - I'm on Chrome 85.

Finally, if you want to achieve the same in Chromium or Brave, replace all mentions above of /etc/opt/chrome with /etc/chromium

| |

the correct reg entry for me is:

[HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome] "ExternalProtocolDialogShowAlwaysOpenCheckbox"=dword:00000001

| |
  • Your solution had already been suggested twice. – Ramhound Mar 22 at 22:16
  • 2
    @Ramhound: No, actually, there were two previous similar answers. Greg here is saying that both of the other answers got the registry key wrong. – Scott Mar 23 at 6:11
  • Yup, this was the only one that worked for me, perhaps because my computer is not domain-joined? – Craig Silver May 30 at 5:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.