Having different permissions for development or environment specific manifests has long been requested for Forge.
The general guidance/workarounds suggested is to manipulate the manifest.yml file as part of the release process, to adjust the permissions when moving from dev to staging/prod.
I created that first linked post way back in 2021 when we had our first attempt at adopting Forge, when webpack was our bundler of choice.
Fast forward to 2026, vite is now arguably the most popular bundler in use today, yet a similar issue still exists.
Vite (as with many other bundlers) supports importing CSS resources, which means you can do something like this in a JS/TS module:
// index.js
import “./index.css”;
// rest of the JS code here…
This is an alternative to manually adding <link rel=“stylesheet” href=“./index.css”> to your index.html file, and has associated tree shaking/code splitting benefits.
When you run vite build, the imported CSS resource is bundled into the output with a content hash based file name etc.
When you run vite in development, the same CSS is inlined into the HTML as a dynamically injected <style> tag.
This means that if you run vite’s dev server while tunnelling in development, your manifest needs to include permissions.content.styles = unsafe-inline, otherwise you’ll get CSP errors.
It seems like environment specific permissions or manifests are unlikely at this point (it’s been 5 years), so I’d like to suggest a different solution:
Instead of making this a manifest concern, could the forge tunnel automatically (or optionally, with a CLI flag) add the unsafe-inline permission, given that running a dev server like vite while tunnelling is surely very common?
As a developer you would still define the exact set of permissions your app needs for production in the manifest, but when tunnelling you also get dev server-friendly permissions as well.
The argument that this might create a situation where something works in development but breaks in staging/production is valid, but tunnelling is already different enough to the final production build anyway that I would argue that we’re not introducing any new risks here.
Having this only apply when tunnelling may be an easier solution than supporting environment specific manifests.
Thoughts?