Learn/Shape Generator/Safety & runtime
Sandboxed execution
At a glance
- Shapes run in a hardened sandbox—no filesystem access, no network calls, and no Node require()
- If something is wrong, generate() can call api.error() with a clear message for the user
A .jshape file is a program, and JetCad3 treats it like one: every shape — bundled, written by
you, or imported from someone else — runs inside a hardened sandbox that exposes only the shape API
and nothing else. That's what makes trading .jshape files with other fabricators reasonable.
What a shape can and can't touch
Inside the sandbox a shape sees module/exports, console, Math, and the BoxesRuntime
helper — that's the entire global surface. There is no require(), no filesystem, no network, and
no process access; compiling new code from strings (eval, new Function) and WebAssembly are
disabled outright, and script evaluation is time-limited so runaway top-level code can't hang the
app. Every drawing operation goes through the api helpers, and the only output is DXF geometry.
Shapes also only run from your user shapes folder — importing a file copies it there first.
Errors surface instead of crashing
A shape that detects bad input calls api.error('message'), which stops generation and puts that
exact message in front of the user — no broken geometry, no silent failure. A file that throws
during load isn't hidden either: it appears in the browser under an Invalid category with its
error text, so you can open it, fix it, and hit Refresh. If generate() fails or produces no
geometry, the preview shows the error in place of the drawing.
What this means for shared files
The sandbox bounds the damage a hostile or buggy shape can do to wasted seconds and an error
message. A .jshape is also plain JavaScript — select it and hit Edit to read exactly what it
does before generating. See Create & Share for the API
a shape is allowed to use.