Which Environment Variables Does a Sandbox Have?

Short answer: Every sandbox gets SANDBOXER_ID, SANDBOXER_SUBDOMAIN, SANDBOXER_API_URL and SANDBOXER_TOKEN, a key limited to that one sandbox. Add your own with sbx new -e KEY=value. Variables live in /etc/sandboxer/env, reach login shells and sbx exec, and reach systemd services that load that file.

The variables Sandboxer sets#

Commands started with sbx exec also get HOME=/home/user, USER and LOGNAME (user), SHELL=/bin/bash, LANG=en_US.UTF-8, LC_ALL and a PATH that includes ~/.local/bin, ~/.bun/bin, ~/.cargo/bin, ~/go/bin and /usr/local/go/bin.

You can't set these names yourself: SANDBOXER_ID, SANDBOXER_TOKEN, SANDBOXER_API_URL, SANDBOXER_SUBDOMAIN, SANDBOXER_CLI_TOKEN, AGENT_ID, ENVIRONMENT_ID, PRODUCT_MODE and SERVICE_PREVIEW_TOKEN. Sandboxer sets the first four for you. The other five are reserved and were not set in either sandbox we tested.

What env shows in a real sandbox#

We created a normal sandbox with two variables of our own, then listed every variable. The script prints every name, but values only for names on an allowlist, so it can't leak a secret:

Then a sandbox for someone else, with none of the account's secrets:

The same listing showed the same four SANDBOXER_* names, GREETING=hello, and nothing from the account's environment. The token was still there, with a narrower scope (see below). Our test account's base environment held no secrets, so the normal sandbox showed none either. On your account, a normal sandbox also lists your environment's variables, and a --no-env one never does.

Never print the token itself. To check it is present without leaking it:

Where the variables live#

The guest agent writes three files. They are rewritten whenever the configuration changes, so don't edit them:

In sandboxes created from 16:07 UTC on October 27, 2026, the two files that hold the token are mode 0640, owned by root:user: the sandbox user and root can read them, other users in the VM get "Permission denied". sandbox.json holds no token and stays readable. Sandboxes created before that have both files at 0644, so any user in the VM can read the token there.

Which processes see them#

We checked each case in the normal sandbox:

A clean, non-login shell and plain sudo don't see the variables. A login shell does, because it sources /etc/profile.d/sandboxer.sh.

A systemd service sees them only if it loads the file:

The second line came from an identical unit without the EnvironmentFile= line.

Per-command variables#

To set a variable for one command, put it in front of the command:

The REST API takes an env object on POST /sandboxes/{id}/commands. A per-command value wins over the sandbox's own value for the same name, whether you send the command as a string (which runs in a login shell) or as an argv array:

Until a fix on October 27, 2026, a string command re-read the profile file, so the sandbox's value won and the first call printed tenant=acme. A sandbox created before the fix keeps that behavior until it boots from disk (for example after a resize); a resume that restores memory keeps the old behavior.

Names you pass at create are checked before anything starts:

Names match [A-Za-z_][A-Za-z0-9_]{0,127}, with at most 100 variables and 64 KB in total. On a name clash, a per-sandbox -e value beats the environment's value. Account-wide variables are set with sbx env set-var (Environments). That changes every new sandbox, so it's out of scope here.