It depends on the product. In Edge, the force install policy overrides an enabled blocklist. In VS Code, the more specific selector takes precedence. In Firefox, an extension with its own entry ignores the wildcard entry. Read each vendor's rule before you layer policies, and test with a known conflict.
Why conflicts happen
Extension policy usually has a broad rule and narrow exceptions. Block everything, allow ten. Allow a publisher, block one of its extensions. Force one tool, block the store it comes from. Each pairing creates a question about order, and the answer is not the same across tools.
What each vendor documents
| Product | Rule documented |
|---|---|
| Edge | The force list overrides any enabled blocklist. Allow and force lists still work when a store is blocked by update URL |
| VS Code | The more specific selector takes precedence |
| Firefox | If an extension has its own entry, the wildcard entry is ignored for it |
| Chrome | Settings apply per extension ID or to all with the wildcard |
I did not find a written precedence rule for Chrome in the page I reviewed, so test your own case rather than relying on assumptions.
Worked examples
Edge. You block all extensions with a wildcard, and you force install one tool. Microsoft says the force list overrides the blocklist, so the tool installs. Another example from Microsoft: you block the Chrome Web Store by its update URL, and you can still use the allow and force lists for specific extensions.
VS Code. The AllowedExtensions policy treats a key without a period as a publisher ID and a key with a period as an extension ID. If you allow a publisher and block one of its extensions, the extension ID entry is more specific, so the block wins for that extension. VS Code says wildcards are not supported in IDs except a single asterisk to allow or block all.
Firefox. You block everything with the wildcard, then add an allowed entry for one ID. Mozilla's reference says the wildcard is ignored for an extension that has its own entry, so the one ID is allowed.
A testing method
- Write the conflict as a sentence: block all, force this one.
- Create a test profile or machine with no other policy.
- Apply only that rule pair.
- Try to install the forced item, the allowed item and a random blocked item.
- Record the outcome next to the vendor documentation link and the product version.
Repeat after major browser or editor updates, because behavior can change.
Keep your rules simple
Fewer layers means fewer surprises. Prefer one wildcard block, one short allowlist and a short force list. Avoid stacking exceptions on top of exceptions. If a rule needs a paragraph of explanation, write that paragraph in the change record, with the owner.
For VS Code details, see our allowlist guide and the post on allowing by publisher, extension or version.
Safeguard note
Safeguard offers an IDE extension for VS Code, JetBrains and Open VSX, plus browser extensions, and a free scan at gold.safeguard.sh/scan. Precedence rules belong to each product's own policy system.
Quick check
Does an Edge blocklist stop a force-installed extension?
No. Microsoft says the force install setting overrides any enabled blocklist policy.
In VS Code, does a publisher allow beat an extension block?
No. VS Code says the more specific selector takes precedence, and an extension ID is more specific than a publisher ID.
Sources
- Use group policies to manage Microsoft Edge extensions, Microsoft Learn
- Allowed extensions in VS Code, enterprise documentation
- ExtensionSettings policy, Firefox administrator reference
- Manage Chrome extensions, Chrome Enterprise help
Last reviewed: 19 October 2026.
