The source of that prompt, is Brave Browser. Please check the Brave Browser settings, to make sure that both of the following switches are Disabled
I asked Alter.systems a question, that I followed up with reference to the prompt produced by Brave Browser:
Answer:
When you click “Always allow [site] to open this type of link in the associated app”, Brave should save that permission in its handlers settings, but . . .
Why the checkbox doesn’t “stick” in Brave
There are four common causes (and one obscure one) for this behavior:
1) Brave’s privacy shielding or site isolation resets the handler permission
Brave’s privacy model is more aggressive than Chrome’s.
When “Cross-site trackers blocked,” “strict fingerprinting,” or “ephemeral storage” is enabled for a domain, Brave doesn’t persist protocol handler permissions across sessions.
Fix:
Open the CRM site (e.g. https://account.lessannoyingcrm.com)
Click the Brave lion icon (Shields) in the address bar.
Temporarily lower protection for that site:
Turn off “Block cross-site cookies” just for that site.
Make sure “Clear cookies and site data when you close all windows” (global setting) is off under brave://settings/clearBrowsingData → On exit.
Re-try the mailto link and check “Always allow…” again.
2) Brave may not actually store mailto handler preferences
Brave historically (through versions up to ~v1.63) has a known bug:
It doesn’t persist mailto: handler permissions to the Protocol Handlers list, even though it claims to.
You can see this yourself:
Go to brave://settings/handlers
You’ll probably notice it stays empty after checking “Always allow.”
That’s Brave’s issue.
Workaround: Manually add or edit a handler:
Open brave://settings/handlers
Enable “Allow sites to ask to become default handlers”
Visit a site that registers itself as a mail handler again (the CRM or Gmail)
When the dialog appears, choose “Allow” (not just check). That often forces Brave to write the entry.
If that still doesn’t persist — this is a Brave bug (several threads on their GitHub confirm it).
3) MacOS permission confusion when multiple browsers or mail handlers are registered
If both Spark and Apple Mail are in your login items or registered as mailto handlers, Brave might fail to decide which protocol handler ID to store — leading it to discard the permission silently.
Fix:
Go to Apple Mail → Preferences → General → Default email reader → Set Spark Desktop explicitly.
Relaunch Brave, then click a mailto link again, check “Always allow.”
4) Clearing site data or using a private window
If you use Private windows by default, or auto-clear cookies upon Brave exit,
the permission cannot persist — Brave treats every session as stateless.
Fix:
Check under:
brave://settings/privacy → Site and Shields Settings → Handlers → ensure “Sites can ask” is enabled.
Also ensure “Clear cookies and site data when you close all windows” is disabled.
5) Brave bug (2024–2025 series)
The Chromium-base permissions database occasionally gets corrupted. Symptoms: handler boxes that never stick, even for Zoom/Slack URLs.
Fix (advanced):
Reset site permissions cache:
Quit Brave completely.
Navigate to:
~/Library/Application Support/BraveSoftware/Brave-Browser/Default/
Delete the files:
ProtocolHandlers
Preferences (you can back this up first)
Restart Brave and reattempt the “Always allow” action.
