Note that "sandboxing" in this case is strictly runtime sandboxing - it's basically like having a separate process per event loop (as if you ran separate Node processes). It does not sandbox the machine context in which it runs (i.e. it's not VM-level containment).

▲

Brass_Hopper an hour ago | parent | next [-]

When you say runtime sandboxing, are you referring to JavaScript agents? I haven't worked all that much with JavaScript execution environments outside of the browser so I'm not sure about what sandboxing mechanics are available.

▲

otterley an hour ago | parent [-]

https://nodejs.org/api/vm.html

Bun claims this feature is for running untrusted code (https://bun.com/reference/node/vm), while Node says "The node:vm module is not a security mechanism. Do not use it to run untrusted code." I'm not sure whom to believe.

	▲	Brass_Hopper 12 minutes ago \| parent \| next [-]
		It's interesting to see the difference in how both treat the module. It feels similar to a realm which makes me lean by default to not trusting it for untrusted code execution. It looks like Bun also supports Shadow Realms which from my understanding was more intended for sandboxing (although I have no idea how resources are shared between a host environment and Shadow Realms, and how that might potentially differ from the node VM module).
	▲	Jarred 40 minutes ago \| parent \| prev [-]
		The reference docs are auto generated from node’s TypeScript types. node:vm is better than using the same global object to run untrusted code, but it’s not really a sandbox

▲

Muromec an hour ago | parent | prev [-]

Running it in a chroot or a scoped down namespace is all your need most of the time anyways.