Deno Permission Flags Reference for CI
Deno denies all access by default; permission flags grant exactly the network, file, and env access a program needs.
The permission model is the same across run, test, bench, and compile. Scoping grants in CI keeps the sandbox useful instead of waving it away with -A.
What it does
Each --allow flag opens one capability and can be scoped: --allow-net=host limits network to a host, --allow-read=path limits reads to a path. Deno 2 added matching --deny flags that override allows, so you can grant broadly but block a specific target.
Common usage
deno run --allow-net=api.example.com --allow-read=./data main.ts
deno run --allow-env=HOME,PATH main.ts
# grant broadly but deny one path (Deno 2)
deno run --allow-read --deny-read=/etc main.tsOptions
| Flag | What it does |
|---|---|
| --allow-net[=hosts] | Network access, optionally scoped to hosts/ports |
| --allow-read[=paths] | Filesystem read, optionally scoped |
| --allow-write[=paths] | Filesystem write, optionally scoped |
| --allow-env[=vars] | Environment variable access, optionally scoped |
| --allow-run[=cmds] | Subprocess execution, optionally scoped |
| --deny-net / --deny-read (Deno 2) | Block a capability even when allowed |
| -A / --allow-all | Grant everything (use sparingly) |
In CI
Prefer scoped grants over -A so a compromised or buggy dependency cannot reach the whole runner. Set the same flags in deno.json or the deno task command so local and CI runs use identical permissions, and use --deny to carve out sensitive paths.
Common errors in CI
The runtime prints "Requires net access to \"host\", run again with the --allow-net flag" (and the same pattern for read, write, env, run). A scoped grant that is too narrow, like --allow-net=example.com when the code also calls a CDN, fails on the second host; widen the scope. A --deny rule silently overrides an --allow, which can look like a missing permission.