Policy Schema Reference
Complete field reference for the sandbox policy YAML. Each field is documented with its type, whether it is required, and whether it is static (locked at sandbox creation) or dynamic (hot-reloadable on a running sandbox).
Top-Level Structure
A policy YAML file contains the following top-level fields:
Static fields are set at sandbox creation time. Changing them requires destroying and recreating the sandbox. Dynamic fields can be updated on a running sandbox with openshell policy set and take effect without restarting.
Version
The version field identifies which schema the policy uses:
Filesystem Policy
Category: Static
Controls filesystem access inside the sandbox. Paths not listed in either read_only or read_write are inaccessible.
Validation constraints:
- Every path must be absolute (start with
/). - Paths must not contain
..traversal components. The server normalizes paths before storage, but rejects policies where traversal would escape the intended scope. - Read-write paths must not be overly broad (for example,
/alone is rejected). - Each individual path must not exceed 4096 characters.
- The combined total of
read_onlyandread_writepaths must not exceed 256.
Policies that violate these constraints are rejected with INVALID_ARGUMENT at creation or update time. Disk-loaded YAML policies that fail validation fall back to a restrictive default.
Example:
Landlock
Category: Static
Configures Landlock LSM enforcement at the kernel level. Landlock provides mandatory filesystem access control below what UNIX permissions allow.
Compatibility modes:
best_effort (the default) is appropriate for most deployments. It handles missing paths gracefully — for example, /app may not exist in every container image but is included in the baseline path set for containers that do have it. Individual missing paths are skipped while the remaining filesystem rules are still enforced.
hard_requirement is for environments where any gap in filesystem isolation is unacceptable. If a listed path cannot be opened for any reason (missing, permission denied, symlink loop), sandbox startup fails immediately rather than running with reduced protection.
When a path is skipped under best_effort, the sandbox logs a warning that includes the path, the specific error, and a human-readable reason (for example, “path does not exist” or “permission denied”).
Example:
Process
Category: Static
Sets the OS-level identity for the agent process inside the sandbox.
Validation constraint: Neither run_as_user nor run_as_group may be set to root or 0. Policies that request root process identity are rejected at creation or update time.
Example:
Network Policies
Category: Dynamic
A map of named network policy entries. Each entry declares a set of endpoints and a set of binaries. Only the listed binaries are permitted to connect to the listed endpoints. The map key is a logical identifier. The name field inside the entry is the display name used in logs.
Network Policy Entry
Each entry in the network_policies map has the following fields:
Endpoint Object
Each endpoint defines a reachable destination and optional inspection rules.
Access Levels
The access field accepts one of the following values:
Rule Object
Used when access is not set. Each rule explicitly allows a method and path combination.
Example with rules:
Binary Object
Identifies an executable that is permitted to use the associated endpoints.
Full Example
The following policy grants read-only GitHub API access and npm registry access: