Security
The proxy-only sandbox closes direct JVM and server-process access, but the current alpha runtime does not yet apply operator-granted capabilities to every gameplay operation. A loaded Script can use the available Host Objects and legacy commands with their current authority.
Normal GraalJS and GraalPython Contexts deny Host/Polyglot access, Java-class lookup and loading, reflection, native access, processes, threads, environment access, sockets, and unrestricted IO. Scripts receive only QuestScript Host Objects, public facades, and approved immutable values.
A filesystem-backed Script can read Language Imports only from the canonical
config/questscript/scripts root; writes, traversal outside that root, and
symlink escapes are denied. Until Script Bundles exist, this root is shared by
all filesystem-backed Scripts and is not an isolation boundary between
packages. Inline Scripts, including /qs eval, receive no filesystem access.
Unrestricted Polyglot bindings are also unavailable; cross-Script calls are
published only through script.export.
The sandbox limits access to the host process, but it does not replace gameplay
authorization. Capability grants for commands and World Mutation are not yet
complete, the deprecated minecraft API remains available, and the complete
native-value reachability audit is still in progress. The current alpha runtime
must therefore not be treated as a boundary for hostile code.
Operational rules:
- never load files supplied by players, chat, HTTP input, or unreviewed packages;
- restrict write access to
config/questscript/scripts/; - grant operator permissions only to trusted administrators;
- review a Script and its dependencies before loading it;
- account for the gameplay Host Objects and legacy commands available to it.
QuestScript is in alpha, so public APIs and the execution model can change without backward compatibility.