Question AdGuard MV3 and Sandboxie

[n8chavez]

I'm trying to write an exclusion for AdGuard MV3 in Sandboxie so I can have custom blocks remain between sessions, but for some reason the exclusion line is not working. I'm not sure why. The location and the ID are correct. Has anyone gotten this to work?

OpenFilePath=vivaldi.exe,C:\Users\<user>\AppData\Local\Vivaldi\User Data\Default\Extensions\apjcbfpjihpedihablmalmbbhjpklbdf*\*

 

[Bot]

I'm trying to write an exclusion for AdGuard MV3 in Sandboxie so I can have custom blocks remain between sessions, but for some reason the exclusion line is not working. I'm not sure why. The location and the ID are correct. Has anyone gotten this to work?

OpenFilePath=vivaldi.exe,C:\Users\<user>\AppData\Local\Vivaldi\User Data\Default\Extensions\apjcbfpjihpedihablmalmbbhjpklbdf*\*

Your line is very likely “not working” for two separate reasons:

1) The wildcard/path is wrong for the Extensions folder
In Chromium profiles the layout is typically:

C:\Users\...\User Data\Default\Extensions\<extension_id>\<version>\...

So you need a backslash before the version wildcard. Your current pattern:

...Extensions\apjcbfp...bdf*\*

would only match a folder name that literally starts with the ID and continues in the same path component, but the real path has a path separator after the ID.

Use this form instead:

• OpenFilePath=vivaldi.exe,C:\Users\YourUser\AppData\Local\Vivaldi\User Data\Default\Extensions\apjcbfpjihpedihablmalmbbhjpklbdf\*\*

Also make sure you replaced “<user>” with the real username. Sandboxie won’t expand “<user>”.

2) AdGuard MV3 custom blocks usually are NOT stored in the Extensions\<id>\... folder
That folder is basically the installed extension package (versioned). Custom rules / settings are typically stored in the profile data stores, for example:

• ...\Default\Local Extension Settings\<extension_id>\...
• ...\Default\IndexedDB\chrome-extension_<extension_id>_0.indexeddb.leveldb\...
• and sometimes the profile Preferences file

So even if you open the Extensions folder correctly, your custom blocks may still reset because the actual modified data is elsewhere.

A more practical set of exclusions to try (adjust profile name if you don’t use “Default”, e.g. “Profile 1”):

• OpenFilePath=vivaldi.exe,C:\Users\YourUser\AppData\Local\Vivaldi\User Data\Default\Local Extension Settings\apjcbfpjihpedihablmalmbbhjpklbdf\*
• OpenFilePath=vivaldi.exe,C:\Users\YourUser\AppData\Local\Vivaldi\User Data\Default\IndexedDB\chrome-extension_apjcbfpjihpedihablmalmbbhjpklbdf_0.indexeddb.leveldb\*
• OpenFilePath=vivaldi.exe,C:\Users\YourUser\AppData\Local\Vivaldi\User Data\Default\Preferences

Safer alternative (often better than OpenFilePath): use Recovery
If your goal is just persistence between sessions (not live access to the real profile while sandboxed), consider recovering only those folders/files on sandbox exit instead of opening direct access. That preserves isolation better.

If you post your Sandboxie section for that box (the relevant OpenFilePath/ReadFilePath lines and whether you have any template restrictions enabled), other members can spot conflicts like a conflicting “ClosedFilePath” or a “privacy” template overriding it.

 

[n8chavez]

This is why I prefer dealing with Firefox over Chromium, and it sucks that Chromium is the better browser. Firefox is not nearly as complicated with stuff like this.

Here is by Vivaldi section of sandboxie.ini

[Vivaldi]

Enabled=y
ConfigLevel=10
AutoRecover=y
BlockNetworkFiles=y
RecoverFolder=N:\Downloads
Template=Vivaldi_Force
Template=Vivaldi_Phishing_DirectAccess
Template=FileCopy
Template=qWave
Template=BlockPorts
Template=LingerPrograms
Template=AutoRecoverIgnore
Template=Vivaldi_Bookmarks_DirectAccess
Template=Vivaldi_Sync_DirectAccess
CopyLimitKb=2094000
CopyLimitSilent=n
ForceProcess=vivaldi.exe
ClosedIpcPath=!<StartRunAccess>,*
ProcessGroup=<StartRunAccess>,vivaldi.exe
ProcessGroup=<InternetAccess>,vivaldi.exe
OpenFilePath=vivaldi.exe,C:\Users\n8chavez\AppData\Local\Vivaldi\User Data\Default\IndexedDB\chrome-extension_apjcbfpjihpedihablmalmbbhjpklbdf_0.indexeddb.leveldb
AutoDelete=y
ClosedFilePath=C:\Program Files\SiriusGPT
ClosedFilePath=!<InternetAccess>,InternetAccess
ClosedFilePath=C:\Scripts\
ClosedFilePath=CC:\Program Files\HBS
ClosedFilePath=!<InternetAccess>,InternetAccessDevices
DropAdminRights=y
FakeAdminRights=y
PromptForInternetAccess=y
BorderColor=#07f74f,ttl,6
UseSecurityMode=y

The yellow text is a functional exclusion for the Adguard MV3 custom files. However, as @Bot mentioned, it is not the safest. I'll be working on altering this from an exclusion to a auto-recovery rule next.

 

[Bot]

This is why I prefer dealing with Firefox over Chromium, and it sucks that Chromium is the better browser. Firefox is not nearly as complicated with stuff like this.

Here is by Vivaldi section of sandboxie.ini



The yellow text is a functional exclusion for the Adguard MV3 custom files. However, as @Bot mentioned, it is not the safest. I'll be working on altering this from an exclusion to a auto-recovery rule next.

What you’ve done (OpenFilePath to the real LevelDB folder) makes sense technically, and it’s also exactly why it “works” — you’ve given the sandboxed Vivaldi process direct write access to your real profile data store for that extension.

Why it’s less safe
OpenFilePath is not just “persistence”; it’s a live bridge from the sandbox to your real profile. If the browser (or an exploited renderer) can write there, it can potentially persist changes outside the sandbox (extension storage, state, etc.). So your instinct to move to Auto-Recover is the right direction.

How to switch from OpenFilePath to Auto-Recover (safer approach)
Goal: keep Vivaldi fully sandboxed during the session, then only copy out the AdGuard storage on exit.

1) Remove the OpenFilePath line:

• Remove: OpenFilePath=vivaldi.exe,C:\Users\n8chavez\AppData\Local\Vivaldi\User Data\Default\IndexedDB\chrome-extension_apjcbfpjihpedihablmalmbbhjpklbdf_0.indexeddb.leveldb

2) Add one (or more) RecoverFolder entries for the AdGuard storage locations. For MV3 extensions, IndexedDB is common, but “Local Extension Settings” is also commonly used, so I’d include both to avoid “it still resets” surprises:

• RecoverFolder=C:\Users\n8chavez\AppData\Local\Vivaldi\User Data\Default\IndexedDB\chrome-extension_apjcbfpjihpedihablmalmbbhjpklbdf_0.indexeddb.leveldb
• RecoverFolder=C:\Users\n8chavez\AppData\Local\Vivaldi\User Data\Default\Local Extension Settings\apjcbfpjihpedihablmalmbbhjpklbdf

3) Keep these as you already have them:

• AutoRecover=y
• AutoDelete=y (if you want the box wiped after recovery)

Important practical gotchas

• Recovery only happens when the sandbox contents exist to recover. If something (like a lingering Vivaldi process) prevents the sandbox from fully closing, AutoRecover/AutoDelete behavior can be confusing. Your Template=LingerPrograms can contribute to that depending on what it keeps alive.
• AutoRecoverIgnore template can override what gets recovered (depends on what that template contains). If it ignores parts of AppData\Local, it may silently block recovery of the exact folders you care about.

Small config hygiene note
You have a typo here:

• ClosedFilePath=CC:\Program Files\HBS

That extra “C” can cause unexpected behavior (not related to AdGuard persistence, but worth cleaning up).

Bottom line
Yes: OpenFilePath will “fix persistence,” but it weakens isolation. Converting this to RecoverFolder-based persistence is the safer design for a browser sandbox, and for AdGuard MV3 you’ll usually want to recover both the extension’s IndexedDB folder and its Local Extension Settings folder to make the settings truly stick.

 

[n8chavez]

So then the new line becomes:

RecoverFolder=C:\Users\n8chavez\AppData\Local\Vivaldi\User Data\Default\IndexedDB\chrome-extension_apjcbfpjihpedihablmalmbbhjpklbdf_0.indexeddb.leveldb

But won't that mean that I'll get prompted for every file in that location?