Filesystem Sandbox — Elide Docs

Execution profiles

--sandbox=trusted explicitly selects trusted execution. It preserves the default runtime behavior and can be combined with capability flags:

elide --sandbox=trusted --allow-read=./data --no-native run app.js

--allow-native explicitly permits guest native access in trusted execution; it conflicts with --no-native. Native access is permitted by default. --no-native denies Graal native access and cannot be overridden by later context configurators. It is not an OS confinement boundary or a complete native-extension policy.

The stronger --sandbox=sandboxed and --sandbox=isolated profiles are recognized but not yet available. Selecting either exits with usage error 2 before running guest code. Elide never substitutes trusted execution for an unavailable profile.

Bare --sandbox retains the filesystem-only behavior below during this rollout. It does not enable a Graal sandbox policy, restrict network or subprocess access by itself, or contain native crashes and OOM.

Filesystem capabilities

Guest code can access the host filesystem until a sandbox flag is supplied. Start with no access, then grant the capabilities the program needs.

elide --sandbox -s 'console.log("sandboxed")'
elide --allow-read=. --allow-write=out.txt run app.js

--allow-read and --allow-write imply --sandbox, so the second command does not need an additional --sandbox flag.

Grants

Flag	Effect
`--allow-read[=PATHS]`	Allow reads everywhere, or only at attached paths.
`--allow-write[=PATHS]`	Allow writes everywhere, or only at attached paths.
`--fs-audit`	Log filesystem decisions to stderr.
`--allow-run[=CMDS]`	Allow all subprocesses, or only attached commands.
`--deny-run CMDS`	Deny commands even when otherwise allowed.
`--allow-net[=HOSTS]`	Allow all network access, or only attached hosts and ports.
`--deny-net HOSTS`	Deny hosts even when otherwise allowed.

Path, command, and host lists may be comma-separated. The allow flags are also repeatable. Deny rules take precedence over matching allow rules.

elide --allow-read=. --allow-write=out.txt --fs-audit run app.js

Filesystem, subprocess, and network grants are independent. See File System Access for a node:fs example.

Filesystem, network, and subprocess grants belong to the runtime workload. Starting another runtime does not replace them; worker contexts inherit their parent’s grants. These restrictions still share a process and do not contain native crashes or OOM. The sandboxed and isolated profiles remain unavailable.

For JavaScript and TypeScript guest scripts, set workload limits with repeatable --limit flags:

elide --limit=workers=4 --limit=fds=128 --timeout=30s app.js

Workers, including nested workers, share the worker limit. The descriptor limit covers live node:fs file and directory handles; it excludes standard streams and internal runtime IO. Use 0 to prohibit allocation or unlimited for no ceiling. Omitted limits remain unlimited. Worker exhaustion reports ERR_WORKER_LIMIT; descriptor exhaustion reports EMFILE. Closing a handle, exiting a worker, or shutting down the runtime returns its capacity. These limits do not grant filesystem or other permissions.

--timeout retains exit code 124 and now requests workload cancellation, including guest contexts, workers, and managed descriptors. Blocking native calls can delay cleanup; this is not native crash or OOM containment. Per-context/request deadlines and other resource limits remain pending.