Description of the issue: Brave Browser inappropriately prevents Brave Browser from running Vimium on the site.
How can this issue be reproduced?
-
Install Vimium from the Chrome Extensions Store
-
Navigate to https://search.brave.com
-
Attempt to scroll
j/k&u/d, activate link followingf/F, split into new windoww, duplicate tabt.
Expected result: User can navigate page, follow links, and control tabs & window with Vimium keybindings & features.
Brave Version( check About Brave): 1.88.130 Chromium: 146.0.7680.76 (Official Build) (arm64)
Additional Information:
2
Complaints downstream of mistaken understanding of cause
I like Brave Browser. I like Brave Search. This is strong reason for me to stop using one of them.Brave built its reputation on user control. Blocking Vimium on Brave Search—without an explicit opt-out—feels like a reversal of that principle, a shift from user sovereignty to product paternalism.
Security defaults are good. Removing user agency is not. If you must, the right move here is a clear, frictionful override: warn me, make me click twice, but let me decide. I get the security argument. But Brave’s differentiator was never just “we lock things down better than Google.” It was “you are in control.” If that’s no longer true in practice, the value proposition erodes quickly.
“Libertarian when marketing the app, paternalistic when convenient for the web service” is not the direction I expected from Brave.
The extension settings says it’s enabled On all sites. That’s excluded the Chrome Extensions Store, defensibly, but a search engine results page, i.e. the starting point of most browser interactions—makes it an intrusive redesign.
3
Complaints downstream of mistaken understanding of cause
And on the discourse forum as well?!
It it just all of the special URLs, and not more carefully considered than that. Or protectively, proactively, prevented from any user modification of the browser’s (i.e. User Agent) behavior?
Current head commit on master
Silly I shouldn’t think of it as a user agent, it’s “the user and brave inc agent”, family.
mcint 4
Complaints downstream of mistaken understanding of cause
> https://brave.com/blog/keep-android-open/Why Brave is opposing Google’s Android developer registry
Published Mar 6, 2026
Google is overriding user choice
One can certainly articulate principles…
It works fine for me on Brave 1.88.127 Chromium: 146.0.7680.71 (Linux):
mcint 6
I see you’re running 1.88.127, while I’m running 1.88.130.
I’m not fully clear on if what’s happening here is Vimium (or other extensions) are allowed to render a “[I’m] not allowed to run on this page”, or if Brave is rendering it. I’m unclear how else I should pursue a fix or ask for help.
mcint 7
Reassuringly, it works in Nightly, 1.90.39 Chromium: 146.0.7680.80 (Official Build) nightly (arm64) currently, macOS
And Beta 1.89.116 Chromium: 146.0.7680.80 (Official Build) beta (arm64)
mcint 8
Thank you @fmarier.
After restarting my browser / computer overnight, Vimium is again available to use on https://search.brave.com and https://community.brave.app. I’m still confused how these domains were affected and not others, but it seems my issue is resolved.
At latest check I’m still running 1.88.130 Chromium: 146.0.7680.76 (Official Build) (arm64) on macOS. Based on other recent experiences, I’m partial to suspecting that memory constraints and swapping may have contributed to the issue.
Thinking further about debug steps for myself in the future:
- browser restart (often annoying to close dozens or hundreds of tabs, clean up forms or edits in progress).
- restart (kill, reload) the extension at issue, or processes running tabs for a domain / origin
- check Beta or Nightly sooner
fmarier 9
Ok, thanks for the update. Good to know it’s working for you too now. As far as I’m aware, the only site where we disable extensions (like Chrome) is the Chrome Web Store. Allowing extensions there could lead to problems like an extension automatically installing/disabling another one because the CWS needs to have special privileges in order to work.