Should I upgrade to Bruno v3 Script now?
Teams already using Bruno collections with scripts need to know what breaks in v3 after the runtime moved from vm2 to NodeVM and whether they should upgrade immediately or pin older behavior.
Blockers
- Bruno documented v3 breaking script changes on 2026-01-07.
- In v3, Bruno moved Developer Mode from vm2 to NodeVM.
- Lock-in via package/vm2
- In v3, Safe Mode remains on QuickJS.
Who this is for
- small-team
- enterprise
- compliance
Candidates
Upgrade to Bruno v3 and refactor scripted collections
As of 2026-03-27, Bruno v3's breaking script changes have already occurred; Bruno documented them on 2026-01-07. In v3, collection, folder, and request scripts no longer run as one shared block and instead execute in isolated async IIFEs, so direct cross-level variable sharing and collection-level `return` short-circuit behavior break; Bruno says to use `bru.setVar()` and `bru.getVar()` for shared state. Bruno also moved Developer Mode from `vm2` to NodeVM while leaving Safe Mode on QuickJS, citing `vm2`'s July 2023 deprecation for critical security issues. For CLI users, v3 now defaults to Safe Mode, so scripts using `fs`, `child_process`, or native Node modules like `crypto` need `--sandbox=developer`, and stricter module resolution can require `additionalContextRoots` plus local dependency installs.
When to choose
Best for teams that can audit their Bruno scripts now and want the current supported runtime and safer CLI defaults. Choose this when your collections are trusted, you can update CI flags deliberately, and you would rather remove vm2-era assumptions than preserve them.
Tradeoffs
You align with Bruno's current v3 behavior and security posture, but you must touch multi-level scripts, re-test module loading, and review CI jobs that depended on the old CLI default.
Cautions
Audit for direct variable references across script levels, early `return` assumptions, relative `require()` paths, and any CLI scripts that silently relied on Developer Mode. If scripts load modules from non-standard locations, Bruno says to configure `additionalContextRoots` in `bruno.json`.
Pin validated Bruno v2 behavior temporarily while you inventory migration blockers
As of 2026-03-27, pinning Bruno v2 is a containment strategy, not a forward-looking default, because Bruno v3's runtime and sandbox changes are already in effect upstream. A temporary pin avoids immediate regressions from v3's isolated script scopes and the CLI switch to Safe Mode while you catalog collections that depend on shared variables, collection-level guard clauses, `require('fs')`, `child_process`, or native Node modules. Bruno's migration checklist for v3 says to ensure npm dependencies are installed in the collection directory, test relative `require()` paths, verify filesystem access if using `fs`, and add `additionalContextRoots` for non-standard module locations. Because Bruno moved off `vm2` due to its documented security deprecation, this option should be time-boxed and tracked as migration debt.
When to choose
Best for teams with many existing collections, regulated CI paths, or high change-management overhead where an unplanned scripting regression is worse than a short-term version pin. Choose this when you need a controlled audit window before adopting v3 semantics and the new CLI sandbox default.
Tradeoffs
This minimizes immediate disruption, but it delays adoption of Bruno's current runtime model and keeps you on pre-v3 scripting assumptions that Bruno has already replaced.
Cautions
Record the exact desktop and CLI versions you are pinning, because package manager or app auto-updates can move users onto v3. Treat the pin as temporary and migrate off vm2-era assumptions rather than expecting a long-term compatibility path.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Should I upgrade to Bruno v3 Script now?"