- - - -How OpenShell Works# -OpenShell runs as a K3s Kubernetes cluster inside a Docker container. Each sandbox is an isolated Kubernetes pod managed through the gateway. Four components work together to keep agents secure. - - - - - -Components# -The following table describes each component and its role in the system: - - -Component -Role - - - -Gateway -Control-plane API that coordinates sandbox lifecycle and state, acts as the auth boundary, and brokers requests across the platform. - -Sandbox -Isolated runtime that includes container supervision and policy-enforced egress routing. - -Policy Engine -Policy definition and enforcement layer for filesystem, network, and process constraints. Defense in depth enforces policies from the application layer down to infrastructure and kernel layers. - -Privacy Router -Privacy-aware LLM routing layer that keeps sensitive context on sandbox compute and routes based on cost and privacy policy. - - - - - - -How a Request Flows# -Every outbound connection from agent code passes through the same decision path: - -The agent process opens an outbound connection (API call, package install, git clone, and so on). -The proxy inside the sandbox intercepts the connection and identifies which binary opened it. -The proxy queries the policy engine with the destination, port, and calling binary. -The policy engine returns one of three decisions: - -Allow — the destination and binary match a policy block. Traffic flows directly to the external service. -Route for inference — no policy block matched, but inference routing is configured. The privacy router intercepts the request, strips the original credentials, injects the configured backend credentials, and forwards to the managed model endpoint. -Deny — no match and no inference route. The connection is blocked and logged. - - - -For REST endpoints with TLS termination enabled, the proxy also decrypts TLS and checks each HTTP request against per-method, per-path rules before allowing it through. - - -Deployment Modes# -OpenShell can run locally or on a remote host. The architecture is identical in both cases — only the Docker container location changes. - -Local: the k3s cluster runs inside Docker on your workstation. The CLI provisions it automatically on first use. -Remote: the cluster runs on a remote host. Deploy with openshell gateway start --remote user@host. For example, connect to your DGX Spark. -$ openshell gateway start --remote <username>@<spark-ssid>.local -$ openshell status - - - - - - -Next Steps# -Continue with one of the following: - -To create your first sandbox, refer to the Quickstart. -To learn how OpenShell enforces isolation across all protection layers, refer to Sandboxes. - - - - - -
- - - -Overview of NVIDIA OpenShell# -NVIDIA OpenShell is an open-source runtime for executing autonomous AI agents in sandboxed environments with kernel-level isolation. It combines sandbox runtime controls and a declarative YAML policy so teams can run agents without giving them unrestricted access to local files, credentials, and external networks. - -Why OpenShell Exists# -AI agents are most useful when they can read files, install packages, call APIs, and use credentials. That same access can create material risk. OpenShell is designed for this tradeoff: preserve agent capability while enforcing explicit controls over what the agent can access. - - -Common Risks and Controls# -The table below summarizes common failure modes and how OpenShell mitigates them. - - -Threat -Without controls -With OpenShell - - - -Data exfiltration -Agent uploads source code or internal files to unauthorized endpoints. -Network policies allow only approved destinations; other outbound traffic is denied. - -Credential theft -Agent reads local secrets such as SSH keys or cloud credentials. -Filesystem restrictions (Landlock) confine access to declared paths only. - -Unauthorized API usage -Agent sends prompts or data to unapproved model providers. -Privacy routing and network policies control where inference traffic can go. - -Privilege escalation -Agent attempts sudo, setuid paths, or dangerous syscall behavior. -Unprivileged process identity and seccomp restrictions block escalation paths. - - - - - - -Protection Layers at a Glance# -OpenShell applies defense in depth across the following policy domains. - - -Layer -What it protects -When it applies - - - -Filesystem -Prevents reads/writes outside allowed paths. -Locked at sandbox creation. - -Network -Blocks unauthorized outbound connections. -Hot-reloadable at runtime. - -Process -Blocks privilege escalation and dangerous syscalls. -Locked at sandbox creation. - -Inference -Reroutes model API calls to controlled backends. -Hot-reloadable at runtime. - - - - -For details, refer to Built-in Default Policy and Customize Sandbox Policies. - - -Common Use Cases# -OpenShell supports a range of agent deployment patterns. - - -Use Case -Description - - - -Secure coding agents -Run Claude Code, OpenCode, or OpenClaw with constrained file and network access. - -Private enterprise development -Route inference to self-hosted or private backends while keeping sensitive context under your control. - -Compliance and audit -Treat policy YAML as version-controlled security controls that can be reviewed and audited. - -Reusable environments -Use community sandbox images or bring your own containerized runtime. - - - - - - - -Next Steps# -Explore these topics to go deeper: - -To understand the components that make up the OpenShell runtime, refer to the Architecture Overview. -To install the CLI and create your first sandbox, refer to the Quickstart. -To learn how OpenShell enforces isolation across all protection layers, refer to Sandboxes. - - - - - -
- - - -NVIDIA OpenShell Release Notes# -Track the latest changes and improvements to NVIDIA OpenShell. -This page covers the highlights of the release. -For more details, refer to the OpenShell GitHub Releases. - -0.1.0# -This is the first release of NVIDIA OpenShell. It introduces sandboxed AI agent execution with kernel-level isolation, policy enforcement, and credential management. - -Highlights# - -Introduces sandboxed AI agent execution with kernel-level isolation, policy enforcement, and credential management. -Introduces the openshell CLI for creating, managing, and customizing sandboxes. -Introduces the openshell-gateway service for managing the gateway and sandboxes. -Introduces the openshell-sandbox service for running the sandboxed agent. - - - - - - -
- - - -Quickstart# -This page gets you from zero to a running, policy-enforced sandbox in two commands. - -Prerequisites# -Before you begin, make sure you have: - -Python 3.12 or later -uv installed -Docker Desktop running on your machine - - - -Install the OpenShell CLI# -Install the openshell package into a virtual environment. -Activate your virtual environment: -uv venv && source .venv/bin/activate - - -Install the CLI: -uv pip install openshell - - - - -Connect to a Remote Gateway (Optional)# -If you’re running locally, skip this step. The OpenShell CLI creates a gateway automatically when you create your first sandbox. - - - -Brev - -Note -Deploy an OpenShell gateway on Brev by hitting Deploy on the OpenShell Launchable. - -After the instance is running, find the gateway URL in the Brev console under Using Secure Links. Copy the shareable URL for port 8080 — this is the gateway endpoint. -$ openshell gateway add https://<your-port-8080-url>.brevlab.com -$ openshell status - - - - - -DGX Spark - -Note -Set up your Spark with NVIDIA Sync first, or make sure SSH access is configured (such as SSH keys added to the host). - -Deploy to a DGX Spark machine over SSH: -$ openshell gateway start --remote <username>@<spark-ssid>.local -$ openshell status - - -After openshell status shows the gateway as healthy, all subsequent commands route through the SSH tunnel. - - - - -Create Your First OpenShell Sandbox# -Choose the tab that matches your agent: - - - -Claude Code -Run the following command to create a sandbox with Claude Code: -$ openshell sandbox create -- claude - - -The CLI prompts you to create a provider from local credentials — type yes to continue. If ANTHROPIC_API_KEY is set in your environment, it is picked up automatically. If not, you can configure it from inside the sandbox after it launches. - - - -OpenCode -Run the following command to create a sandbox with OpenCode: -$ openshell sandbox create -- opencode - - -The CLI prompts you to create a provider from local credentials. Type yes to continue. If OPENAI_API_KEY or OPENROUTER_API_KEY is set in your environment, it is picked up automatically. If not, you can configure it from inside the sandbox after it launches. - - - -Codex -Run the following command to create a sandbox with Codex: -$ openshell sandbox create -- codex - - -The CLI prompts you to create a provider from local credentials. Type yes to continue. If OPENAI_API_KEY is set in your environment, it is picked up automatically. If not, you can configure it from inside the sandbox after it launches. - - - -OpenClaw -Run the following command to create a sandbox with OpenClaw: -$ openshell sandbox create --from openclaw - - -The --from flag pulls a pre-built sandbox definition from the OpenShell Community catalog. Each definition bundles a container image, a tailored policy, and optional skills into a single package. - - - -Community Sandbox -You can use the --from flag to pull other OpenShell sandbox images from the NVIDIA Container Registry. For example, to pull the base image, run the following command: -$ openshell sandbox create --from base - - - - - - - - -
- - - -NVIDIA OpenShell# - - - -NVIDIA OpenShell is the safe, private runtime for autonomous AI agents. It provides sandboxed execution environments -that protect your data, credentials, and infrastructure. Agents run with exactly the permissions they need and -nothing more, governed by declarative policies that prevent unauthorized file access, data exfiltration, and -uncontrolled network activity. - -Get Started# -Install the CLI and create your first sandbox in two commands. - - - - - - - - - $ uv pip install openshell - $ openshell sandbox create -- claude--from openclaw-- opencode-- codex - -Refer to the Quickstart for more details. - - - -Explore# - - - - - - -About OpenShell -Learn about OpenShell and its capabilities. - - -Overview of NVIDIA OpenShell - - - - - -Quickstart -Install the CLI and create your first sandbox in two commands. - - -Quickstart - - - - - -Set Up a Sandbox with GitHub Repo Access -End-to-end guides: GitHub repo access, custom policies, and more. - - -Set Up a Sandbox of Claude Code with a Custom GitHub Policy - - - - - -Sandboxes -Create, manage, and customize sandboxes. Configure policies, providers, and community images. - - -About Sandboxes - - - - - -Inference Routing -Keep inference traffic private by routing API calls to local or self-hosted backends. - - -About Inference Routing - - - - - -Reference -Policy schema, environment variables, and system architecture. - - -Default Policy Reference - - - - - - - - - - - - - - - - - - - - - -
- - - -Configure Inference Routing# -This page covers the managed local inference endpoint (https://inference.local). External inference endpoints go through sandbox network_policies — refer to Network Access Rules for details. -The configuration consists of two values: - - -Value -Description - - - -Provider record -The credential backend OpenShell uses to authenticate with the upstream model host. - -Model ID -The model to use for generation requests. - - - - - -Step 1: Create a Provider# -Create a provider that holds the backend credentials you want OpenShell to use. - - - -NVIDIA API Catalog -$ openshell provider create --name nvidia-prod --type nvidia --from-existing - - -This reads NVIDIA_API_KEY from your environment. - - - -Local / self-hosted endpoint -$ openshell provider create \ - --name my-local-model \ - --type openai \ - --credential OPENAI_API_KEY=empty-if-not-required \ - --config OPENAI_BASE_URL=http://192.168.10.15/v1 - - -Use --config OPENAI_BASE_URL to point to any OpenAI-compatible server running on your network. Set OPENAI_API_KEY to a dummy value if the server does not require authentication. - - - -Anthropic -$ openshell provider create --name anthropic-prod --type anthropic --from-existing - - -This reads ANTHROPIC_API_KEY from your environment. - - - - -Step 2: Set Inference Routing# -Point inference.local at that provider and choose the model to use: -$ openshell inference set \ - --provider nvidia-prod \ - --model nvidia/nemotron-3-nano-30b-a3b - - - - -Step 3: Verify the Active Config# -Confirm that the provider and model are set correctly: -$ openshell inference get -Gateway inference: - - Provider: nvidia-prod - Model: nvidia/nemotron-3-nano-30b-a3b - Version: 1 - - - - -Step 4: Update Part of the Config# -Use update when you want to change only one field: -$ openshell inference update --model nvidia/nemotron-3-nano-30b-a3b - - -Or switch providers without repeating the current model: -$ openshell inference update --provider openai-prod - - - - -Use It from a Sandbox# -After inference is configured, code inside any sandbox can call https://inference.local directly: -from openai import OpenAI - -client = OpenAI(base_url="https://inference.local/v1", api_key="dummy") - -response = client.chat.completions.create( - model="anything", - messages=[{"role": "user", "content": "Hello"}], -) - - -The client-supplied model is ignored for generation requests. OpenShell rewrites it to the configured model before forwarding upstream. -Use this endpoint when inference should stay local to the host for privacy and security reasons. External providers that should be reached directly belong in network_policies instead. - -Verify the Endpoint from a Sandbox# -openshell inference get confirms the configuration was saved, but does not verify the upstream endpoint is reachable. To confirm end-to-end connectivity, connect to a sandbox and run: -curl https://inference.local/v1/responses \ - -H "Content-Type: application/json" \ - -d '{ - "instructions": "You are a helpful assistant.", - "input": "Hello!" - }' - - -A successful response confirms the privacy router can reach the configured backend and the model is serving requests. - -Note - -Gateway-scoped — every sandbox on the active gateway sees the same inference.local backend. -HTTPS only — inference.local is intercepted only for HTTPS traffic. - - - - - -Next Steps# -Explore related topics: - -To understand the inference routing flow and supported API patterns, refer to About Inference Routing. -To control external endpoints, refer to Network Access Rules. -To manage provider records, refer to Providers. - - - - - -
- - - -About Inference Routing# -OpenShell handles inference in two ways: - - -Path -How It Works - - - -External endpoints -Traffic to hosts like api.openai.com or api.anthropic.com is treated like any other outbound request — allowed or denied by network_policies. Refer to Network Access Rules. - -inference.local -A special endpoint exposed inside every sandbox for inference that should stay local to the host for privacy and security. The privacy router strips the original credentials, injects the configured backend credentials, and forwards to the managed model endpoint. - - - - - -How inference.local Works# -When code inside a sandbox calls https://inference.local, the privacy router routes the request to the configured backend for that gateway. The configured model is applied to generation requests, and provider credentials are supplied by OpenShell rather than by code inside the sandbox. -If code calls an external inference host directly, that traffic is evaluated only by network_policies. - - -Property -Detail - - - -Credentials -No sandbox API keys needed — credentials come from the configured provider record. - -Configuration -One provider and one model define sandbox inference. - -Provider support -OpenAI, Anthropic, and NVIDIA providers all work through the same endpoint. - -Hot-refresh -Provider credential changes and inference updates are picked up without recreating sandboxes. - - - - - - -Supported API Patterns# -Supported request patterns depend on the provider configured for inference.local. - - - -OpenAI-compatible - - -Pattern -Method -Path - - - -Chat Completions -POST -/v1/chat/completions - -Completions -POST -/v1/completions - -Responses -POST -/v1/responses - -Model Discovery -GET -/v1/models - -Model Discovery -GET -/v1/models/* - - - - - - - -Anthropic-compatible - - -Pattern -Method -Path - - - -Messages -POST -/v1/messages - - - - - - -Requests to inference.local that do not match the configured provider’s supported patterns are denied. - - -Next Steps# -Continue with one of the following: - -To set up the backend behind inference.local, refer to Configure Inference Routing. -To control external endpoints, refer to Network Access Rules. - - - - - -
- - -Default Policy Reference# -The default policy is the policy applied when you create an OpenShell sandbox without --policy. It is baked into the community base image (ghcr.io/nvidia/openshell-community/sandboxes/base) and defined in the community repo’s dev-sandbox-policy.yaml. - -Agent Compatibility# -The following table shows the coverage of the default policy for common agents. - - -Agent -Coverage -Action Required - - - -Claude Code -Full -None. Works out of the box. - -OpenCode -Partial -Add opencode.ai endpoint and OpenCode binary paths. - -Codex -None -Provide a complete custom policy with OpenAI endpoints and Codex binary paths. - - - - - -Important -If you run a non-Claude agent without a custom policy, the agent’s API calls are denied by the proxy. You must provide a policy that declares the agent’s endpoints and binaries. - - - -Default Policy Blocks# -The default policy blocks are defined in the community base image. See the openshell-community repository for the full dev-sandbox-policy.yaml source. - - - - -
- - - -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: -version: 1 -filesystem_policy: { ... } -landlock: { ... } -process: { ... } -network_policies: { ... } - - - - -Field -Type -Required -Category -Description - - - -version -integer -Yes -– -Policy schema version. Must be 1. - -filesystem_policy -object -No -Static -Controls which directories the agent can read and write. - -landlock -object -No -Static -Configures Landlock LSM enforcement behavior. - -process -object -No -Static -Sets the user and group the agent process runs as. - -network_policies -map -No -Dynamic -Declares which binaries can reach which network endpoints. - - - - -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: - - -Field -Type -Required -Description - - - -version -integer -Yes -Schema version number. Currently must be 1. - - - - - - -Filesystem Policy# -Category: Static -Controls filesystem access inside the sandbox. Paths not listed in either read_only or read_write are inaccessible. - - -Field -Type -Required -Description - - - -include_workdir -bool -No -When true, automatically adds the agent’s working directory to read_write. - -read_only -list of strings -No -Paths the agent can read but not modify. Typically system directories like /usr, /lib, /etc. - -read_write -list of strings -No -Paths the agent can read and write. Typically /sandbox (working directory) and /tmp. - - - - -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_only and read_write paths 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: -filesystem_policy: - include_workdir: true - read_only: - - /usr - - /lib - - /proc - - /dev/urandom - - /etc - read_write: - - /sandbox - - /tmp - - /dev/null - - - - -Landlock# -Category: Static -Configures Landlock LSM enforcement at the kernel level. Landlock provides mandatory filesystem access control below what UNIX permissions allow. - - -Field -Type -Required -Values -Description - - - -compatibility -string -No -best_effort, hard_requirement -How OpenShell handles kernel ABI differences. best_effort uses the highest Landlock ABI the host kernel supports. hard_requirement fails if the required ABI is unavailable. - - - - -Example: -landlock: - compatibility: best_effort - - - - -Process# -Category: Static -Sets the OS-level identity for the agent process inside the sandbox. - - -Field -Type -Required -Description - - - -run_as_user -string -No -The user name or UID the agent process runs as. Default: sandbox. - -run_as_group -string -No -The group name or GID the agent process runs as. Default: 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: -process: - run_as_user: sandbox - run_as_group: sandbox - - - - -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: - - -Field -Type -Required -Description - - - -name -string -No -Display name for the policy entry. Used in log output. Defaults to the map key. - -endpoints -list of endpoint objects -Yes -Hosts and ports this entry permits. - -binaries -list of binary objects -Yes -Executables allowed to connect to these endpoints. - - - - - - -Endpoint Object# -Each endpoint defines a reachable destination and optional inspection rules. - - -Field -Type -Required -Description - - - -host -string -Yes -Hostname or IP address. Supports wildcards: *.example.com matches any subdomain. - -port -integer -Yes -TCP port number. - -protocol -string -No -Set to rest to enable HTTP request inspection. Omit for TCP passthrough. - -tls -string -No -TLS handling mode. terminate decrypts TLS at the proxy for inspection. passthrough forwards encrypted traffic without inspection. Only relevant when protocol is rest. - -enforcement -string -No -enforce actively blocks disallowed requests. audit logs violations but allows traffic through. - -access -string -No -HTTP access level. One of read-only, read-write, or full. Mutually exclusive with rules. - -rules -list of rule objects -No -Fine-grained per-method, per-path allow rules. Mutually exclusive with access. - - - - - -Access Levels# -The access field accepts one of the following values: - - -Value -Allowed HTTP Methods - - - -full -All methods and paths. - -read-only -GET, HEAD, OPTIONS. - -read-write -GET, HEAD, OPTIONS, POST, PUT, PATCH. - - - - - - -Rule Object# -Used when access is not set. Each rule explicitly allows a method and path combination. - - -Field -Type -Required -Description - - - -allow.method -string -Yes -HTTP method to allow (for example, GET, POST). - -allow.path -string -Yes -URL path pattern. Supports * and ** glob syntax. - - - - -Example with rules: -rules: - - allow: - method: GET - path: /**/info/refs* - - allow: - method: POST - path: /**/git-upload-pack - - - - - -Binary Object# -Identifies an executable that is permitted to use the associated endpoints. - - -Field -Type -Required -Description - - - -path -string -Yes -Filesystem path to the executable. Supports glob patterns with * and **. For example, /sandbox/.vscode-server/** matches any executable under that directory tree. - - - - - - -Full Example# -The following policy grants read-only GitHub API access and npm registry access: -network_policies: - github_rest_api: - name: github-rest-api - endpoints: - - host: api.github.com - port: 443 - protocol: rest - tls: terminate - enforcement: enforce - access: read-only - binaries: - - path: /usr/local/bin/claude - - path: /usr/bin/node - - path: /usr/bin/gh - npm_registry: - name: npm-registry - endpoints: - - host: registry.npmjs.org - port: 443 - binaries: - - path: /usr/bin/npm - - path: /usr/bin/node - - - - - - - -
- - - -Support Matrix# -This page lists the platform, software, runtime, and kernel requirements for running OpenShell. - -Supported Platforms# -OpenShell publishes multi-architecture container images for linux/amd64 and linux/arm64. The CLI is supported on the following host platforms: - - -Platform -Architecture -Status - - - -Linux (Debian/Ubuntu) -x86_64 (amd64) -Supported - -Linux (Debian/Ubuntu) -aarch64 (arm64) -Supported - -macOS (Docker Desktop) -Apple Silicon (arm64) -Supported - -Windows (WSL 2 + Docker Desktop) -x86_64 -Untested - - - - - - -Software Prerequisites# -The following software must be installed on the host before using the OpenShell CLI: - - -Component -Minimum Version -Notes - - - -Docker Desktop or Docker Engine -28.04 -Must be running before any openshell command. - - - - - - -Sandbox Runtime Versions# -Sandbox container images are maintained in the openshell-community repository. Refer to that repository for the current list of installed components and their versions. - - -Container Images# -OpenShell publishes two container images. Both are published for linux/amd64 and linux/arm64. - - -Image -Reference -Pulled When - - - -Cluster -ghcr.io/nvidia/openshell/cluster:latest -openshell gateway start - -Gateway -ghcr.io/nvidia/openshell/gateway:latest -Cluster startup (via Helm chart) - - - - -The cluster image bundles the Helm charts, Kubernetes manifests, and the openshell-sandbox supervisor binary required to bootstrap the control plane. The supervisor binary is side-loaded into sandbox pods at runtime via a read-only host volume mount. The gateway image is pulled at cluster startup and runs the API server. -Sandbox images are maintained separately in the openshell-community repository. -To override the default image references, set the following environment variables: - - -Variable -Purpose - - - -OPENSHELL_CLUSTER_IMAGE -Override the cluster image reference. - -OPENSHELL_COMMUNITY_REGISTRY -Override the registry for community sandbox images. - - - - - - -Kernel Requirements# -OpenShell enforces sandbox isolation through two Linux kernel security modules: - - -Module -Requirement -Details - - - -Landlock LSM -Recommended -Enforces filesystem access restrictions at the kernel level. The best_effort compatibility mode uses the highest Landlock ABI the host kernel supports. The hard_requirement mode fails sandbox creation if the required ABI is unavailable. - -seccomp -Required -Filters dangerous system calls. Available on all modern Linux kernels (3.17+). - - - - -On macOS, these kernel modules run inside the Docker Desktop Linux VM, not on the host kernel. - - -Agent Compatibility# -For the full list of supported agents and their default policy coverage, refer to the Supported Agents table. - - - - -
- - - -Community Sandboxes# -Use pre-built sandboxes from the OpenShell Community catalog, or contribute your -own. - -What Are Community Sandboxes# -Community sandboxes are ready-to-use environments published in the -OpenShell Community repository. -Each sandbox bundles a Dockerfile, policy, optional skills, and startup scripts -into a single package that you can launch with one command. - - -Current Catalog# -The following community sandboxes are available in the catalog. - - -Sandbox -Description - - - -base -Foundational image with system tools and dev environment - -openclaw -Open agent manipulation and control - -sdg -Synthetic data generation workflows - -simulation -General-purpose simulation sandboxes - - - - - - -Use a Community Sandbox# -Launch a community sandbox by name with the --from flag: -$ openshell sandbox create --from openclaw - - -When you pass --from with a community sandbox name, the CLI: - -Resolves the name against the -OpenShell Community repository. -Pulls the Dockerfile, policy, skills, and any startup scripts. -Builds the container image locally. -Creates the sandbox with the bundled configuration applied. - -You end up with a running sandbox whose image, policy, and tooling are all -preconfigured by the community package. - -Other Sources# -The --from flag also accepts: - -Local directory paths: Point to a directory on disk that contains a -Dockerfile and optional policy/skills: -$ openshell sandbox create --from ./my-sandbox-dir - - - -Container image references: Use an existing container image directly: -$ openshell sandbox create --from my-registry.example.com/my-image:latest - - - - - - - -Contribute a Community Sandbox# -Each community sandbox is a directory under sandboxes/ in the -OpenShell Community repository. -At minimum, a sandbox directory must contain: - -Dockerfile: Defines the container image -README.md: Describes the sandbox and how to use it - -Optional files: - -policy.yaml: Default policy applied when the sandbox launches -skills/: Agent skill definitions bundled with the sandbox -Startup scripts: Any scripts the Dockerfile or entrypoint invokes - -To contribute, fork the repository, add your sandbox directory, and open a pull -request. Refer to the repository’s -CONTRIBUTING.md -for submission guidelines. - -Note -The community catalog is designed to grow. If you have built a sandbox that -supports a particular workflow (data processing, simulation, code review, -or anything else), consider contributing it back so others can use it. - - - -Next Steps# -Explore related topics: - -Need to supply API keys or tokens? Set up Providers for credential management. -Want to customize the sandbox policy? Write custom rules in Customize Sandbox Policies. - - - - - -
- - - -Create and Manage Sandboxes# -This page walks you through the full sandbox lifecycle: creating, inspecting, connecting to, monitoring, and deleting sandboxes. For background on what sandboxes are and how the runtime works, refer to About Sandboxes. - -Warning -Docker must be running before you create a sandbox. If it is not, the CLI -returns a connection-refused error (os error 61) without explaining -the cause. Start Docker and try again. - - -Create a Sandbox# -Run a single command to create a sandbox and launch your agent: -$ openshell sandbox create -- claude - - -If you have an existing gateway, the sandbox is created in it. Otherwise, a gateway is created automatically. -A fully specified creation command might look like: -$ openshell sandbox create \ - --name dev \ - --provider my-claude \ - --policy policy.yaml \ - --upload \ - -- claude - - - -Tip -Sandboxes created with openshell sandbox create stay running by default after -the initial command or shell exits. Use --no-keep when you want the sandbox -deleted automatically instead. - - - -Create from a Community Sandbox or Custom Image# -Use --from to create a sandbox from a pre-built community package, a local directory, or a container image: -$ openshell sandbox create --from openclaw - - -The CLI resolves the name against the OpenShell Community catalog, pulls the bundled Dockerfile and policy, builds the image locally, and creates the sandbox. For the full catalog and how to contribute your own, refer to Community Sandboxes. -You can also point --from at a local directory or a container image reference: -$ openshell sandbox create --from ./my-sandbox-dir -$ openshell sandbox create --from my-registry.example.com/my-image:latest - - - - -List and Inspect Sandboxes# -Check the status of your sandboxes and retrieve detailed information about individual ones. -List all sandboxes: -$ openshell sandbox list - - -Get detailed information about a specific sandbox: -$ openshell sandbox get my-sandbox - - - - -Connect to a Sandbox# -Access a running sandbox through an interactive SSH session or VS Code Remote-SSH. - -Interactive SSH# -Open an SSH session into a running sandbox: -$ openshell sandbox connect my-sandbox - - - - -Open in a remote editor# -Launch VS Code or Cursor directly into the sandbox workspace: -$ openshell sandbox create --editor vscode --name my-sandbox -$ openshell sandbox connect my-sandbox --editor cursor - - -When --editor is used, OpenShell keeps the sandbox alive and installs an -OpenShell-managed SSH include file instead of cluttering your main -~/.ssh/config with generated host blocks. - - - -View Logs# -Stream and filter sandbox logs to monitor agent activity and diagnose policy decisions. -Stream sandbox logs: -$ openshell logs my-sandbox - - -Use flags to filter and follow output: - - -Flag -Purpose -Example - - - ---tail -Stream logs in real time -openshell logs my-sandbox --tail - ---source -Filter by log source ---source sandbox - ---level -Filter by severity ---level warn - ---since -Show logs from a time window ---since 5m - - - - - - -Monitor Your Sandbox# -OpenShell Terminal is a real-time dashboard that combines sandbox status and live logs in a single view. -$ openshell term - - -The dashboard shows the following information. - -Sandbox status: Name, phase, image, attached providers, age, and active port forwards. -Live log stream: Omutbound connections, policy decisions, and inference interceptions as they happen. Logs are labeled by source: sandbox (proxy and policy events) or gateway (lifecycle events). - -Use the terminal to spot blocked connections (action=deny entries) and inference interceptions (action=inspect_for_inference entries). If a connection is blocked unexpectedly, add the host to your network policy — refer to Customize Sandbox Policies for the workflow. - - -Transfer Files# -Transfer files between your host machine and a running sandbox. -Upload files from your host into the sandbox: -$ openshell sandbox upload my-sandbox ./src /sandbox/src - - -Download files from the sandbox to your host: -$ openshell sandbox download my-sandbox /sandbox/output ./local - - - -Note -You can also upload files at creation time with the --upload flag on -openshell sandbox create. - - - -Delete Sandboxes# -Remove sandboxes when they are no longer needed. Deleting a sandbox stops all processes, releases cluster resources, and purges injected credentials. -Delete a sandbox by name: -$ openshell sandbox delete my-sandbox - - -Delete all sandboxes in the active gateway: -$ openshell sandbox delete --all - - - - -Next Steps# -Explore related topics: - -To follow a complete end-to-end example, refer to the Set Up a Sandbox of Claude Code with a Custom GitHub Policy tutorial. -To supply API keys or tokens, refer to Providers. -To control what the agent can access, refer to Customize Sandbox Policies. -To use a pre-built environment, refer to the Community Sandboxes catalog. - - - - - -
- - - -About Sandboxes# -An OpenShell sandbox is a safe, private execution environment for an AI agent. Each sandbox runs with multiple layers of protection that prevent unauthorized data access, credential exposure, and network exfiltration. Protection layers include filesystem restrictions (Landlock), system call filtering (seccomp), network namespace isolation, and a privacy-enforcing HTTP CONNECT proxy. - -Sandbox Lifecycle# -Every sandbox moves through a defined set of phases: - - -Phase -Description - - - -Provisioning -The runtime is setting up the sandbox environment, injecting credentials, and applying your policy. - -Ready -The sandbox is running. The agent process is active and all isolation layers are enforced. You can connect, sync files, and view logs. - -Error -Something went wrong during provisioning or execution. Check logs with openshell logs for details. - -Deleting -The sandbox is being torn down. The system releases resources and purges credentials. - - - - - - -Supported Agents# -The following table summarizes the agents that run in OpenShell sandboxes. All agent sandbox images are maintained in the OpenShell Community repository. Agents in the base image are auto-configured when passed as the trailing command to openshell sandbox create. More community agent sandboxes are available in the Community Sandboxes catalog. - - -Agent -Source -Default Policy -Notes - - - -Claude Code -base -Full coverage -Works out of the box. Requires ANTHROPIC_API_KEY. - -OpenCode -base -Partial coverage -Pre-installed. Add opencode.ai endpoint and OpenCode binary paths to the policy for full functionality. - -Codex -base -No coverage -Pre-installed. Requires a custom policy with OpenAI endpoints and Codex binary paths. Requires OPENAI_API_KEY. - -OpenClaw -openclaw -Bundled -Agent orchestration layer. Launch with openshell sandbox create --from openclaw. - - - - - - - -Built-in Default Policy# -OpenShell ships a built-in policy that covers common agent workflows out of the box. -When you create a sandbox without --policy, the default policy is applied. It controls three things: - - -Layer -What It Controls -How It Works - - - -Filesystem -What the agent can access on disk -Paths are split into read-only and read-write sets. Landlock LSM enforces these restrictions at the kernel level. - -Network -What the agent can reach on the network -Each policy block pairs allowed destinations (host and port) with allowed binaries (executable paths). The proxy matches every outbound connection to the binary that opened it. Both must match or the connection is denied. - -Process -What privileges the agent has -The agent runs as an unprivileged user with seccomp filters that block dangerous system calls. No sudo, no setuid, no path to elevated privileges. - - - - -For the full breakdown of each default policy block and agent compatibility details, refer to Default Policy Reference. - - -Policy Structure# -A policy has static sections (filesystem_policy, landlock, process) that are locked at sandbox creation, and dynamic sections (network_policies, inference) that are hot-reloadable on a running sandbox. -version: 1 - -# Static: locked at sandbox creation. Paths the agent can read vs read/write. -filesystem_policy: - read_only: [/usr, /lib, /etc] - read_write: [/sandbox, /tmp] - -# Static: Landlock LSM kernel enforcement. best_effort uses highest ABI the host supports. -landlock: - compatibility: best_effort - -# Static: Unprivileged user/group the agent process runs as. -process: - run_as_user: sandbox - run_as_group: sandbox - -# Dynamic: hot-reloadable. Named blocks of endpoints + binaries allowed to reach them. -network_policies: - my_api: - name: my-api - endpoints: - - host: api.example.com - port: 443 - protocol: rest - tls: terminate - enforcement: enforce - access: full - binaries: - - path: /usr/bin/curl - -# Dynamic: hot-reloadable. Routing hints this sandbox can use for inference (e.g. local, nvidia). -inference: - allowed_routes: [local] - - -For the complete structure and every field, refer to the Policy Schema Reference. - - -Network Access Rules# -Network access is controlled by policy blocks under network_policies. Each block has a name, a list of endpoints (host, port, protocol, and optional rules), and a list of binaries that are allowed to use those endpoints. -Every outbound connection from the sandbox goes through the proxy: - -The proxy queries the policy engine with the destination (host and port) and the calling binary. A connection is allowed only when both match an entry in the same policy block. -For endpoints with protocol: rest and tls: terminate, each HTTP request is checked against that endpoint’s rules (method and path). -If no endpoint matches and inference routes are configured, the request may be rerouted for inference. -Otherwise the connection is denied. Endpoints without protocol or tls allow the TCP stream through without inspecting payloads. - - - -Next Steps# -Continue with one of the following: - -To create your first sandbox, refer to Create and Manage Sandboxes. -To supply API keys or tokens, refer to Providers. -To control what the agent can access, refer to Customize Sandbox Policies. -To use a pre-built environment, refer to the Community Sandboxes catalog. - - - - - -
- - - -Customize Sandbox Policies# -Use this page to apply and iterate policy changes on running sandboxes. For a full field-by-field YAML definition, use the Policy Schema Reference. - -Quick Start: Apply a Custom Policy# -Pass a policy YAML file when creating the sandbox: -$ openshell sandbox create --policy ./my-policy.yaml -- claude - - -openshell sandbox create keeps the sandbox running after the initial command exits, which is useful when you plan to iterate on the policy. Add --no-keep if you want the sandbox deleted automatically instead. -To avoid passing --policy every time, set a default policy with an environment variable: -$ export OPENSHELL_SANDBOX_POLICY=./my-policy.yaml -$ openshell sandbox create -- claude - - -The CLI uses the policy from OPENSHELL_SANDBOX_POLICY whenever --policy is not explicitly provided. - - -Iterate on a Running Sandbox# -To change what the sandbox can access, pull the current policy, edit the YAML, and push the update. The workflow is iterative: create the sandbox, monitor logs for denied actions, pull the policy, modify it, push, and verify. - - flowchart TD - A["1. Create sandbox with initial policy"] --> B["2. Monitor logs for denied actions"] - B --> C["3. Pull current policy"] - C --> D["4. Modify the policy YAML"] - D --> E["5. Push updated policy"] - E --> F["6. Verify the new revision loaded"] - F --> B - - style A fill:#76b900,stroke:#000000,color:#000000 - style B fill:#76b900,stroke:#000000,color:#000000 - style C fill:#76b900,stroke:#000000,color:#000000 - style D fill:#ffffff,stroke:#000000,color:#000000 - style E fill:#76b900,stroke:#000000,color:#000000 - style F fill:#76b900,stroke:#000000,color:#000000 - - linkStyle default stroke:#76b900,stroke-width:2px - The following steps outline the hot-reload policy update workflow. - -Create the sandbox with your initial policy by following Quick Start: Apply a Custom Policy above (or set OPENSHELL_SANDBOX_POLICY). -Monitor denials. Each log entry shows host, port, binary, and reason. Alternatively, use openshell term for a live dashboard. -$ openshell logs <name> --tail --source sandbox - - - -Pull the current policy. Strip the metadata header (Version, Hash, Status) before reusing the file. -$ openshell policy get <name> --full > current-policy.yaml - - - -Edit the YAML: add or adjust network_policies entries, binaries, access or rules, or inference.allowed_routes. -Push the updated policy. Exit codes: 0 = loaded, 1 = validation failed, 124 = timeout. -$ openshell policy set <name> --policy current-policy.yaml --wait - - - -Verify the new revision. If status is loaded, repeat from step 2 as needed; if failed, fix the policy and repeat from step 4. -$ openshell policy list <name> - - - - - - -Debug Denied Requests# -Check openshell logs <name> --tail --source sandbox for the denied host, path, and binary. -When triaging denied requests, check: - -Destination host and port to confirm which endpoint is missing. -Calling binary path to confirm which binaries entry needs to be added or adjusted. -HTTP method and path (for REST endpoints) to confirm which rules entry needs to be added or adjusted. - -Then push the updated policy as described above. - - -Examples# -Add these blocks to the network_policies section of your sandbox policy. Apply with openshell policy set <name> --policy <file> --wait. -Use Simple endpoint for host-level allowlists and Granular rules for method/path control. - - - -Simple endpoint -Allow pip install and uv pip install to reach PyPI: - pypi: - name: pypi - endpoints: - - host: pypi.org - port: 443 - - host: files.pythonhosted.org - port: 443 - binaries: - - { path: /usr/bin/pip } - - { path: /usr/local/bin/uv } - - -Endpoints without protocol or tls use TCP passthrough — the proxy allows the stream without inspecting payloads. - - - -Granular rules -Allow Claude and the GitHub CLI to reach api.github.com with per-path rules: read-only (GET, HEAD, OPTIONS) and GraphQL (POST) for all paths; full write access for alpha-repo; and create/edit issues only for bravo-repo. Replace <org_name> with your GitHub org or username. - -Tip -For an end-to-end walkthrough that combines this policy with a GitHub credential provider and sandbox creation, refer to Set Up a Sandbox of Claude Code with a Custom GitHub Policy. - - github_repos: - name: github_repos - endpoints: - - host: api.github.com - port: 443 - protocol: rest - tls: terminate - enforcement: enforce - rules: - - allow: - method: GET - path: "/**" - - allow: - method: HEAD - path: "/**" - - allow: - method: OPTIONS - path: "/**" - - allow: - method: POST - path: "/graphql" - - allow: - method: "*" - path: "/repos/<org_name>/alpha-repo/**" - - allow: - method: POST - path: "/repos/<org_name>/bravo-repo/issues" - - allow: - method: PATCH - path: "/repos/<org_name>/bravo-repo/issues/*" - binaries: - - { path: /usr/local/bin/claude } - - { path: /usr/bin/gh } - - -Endpoints with protocol: rest and tls: terminate enable HTTP request inspection — the proxy decrypts TLS and checks each HTTP request against the rules list. - - - - -Next Steps# -Explore related topics: - -To learn about policy structure and network access rules, refer to About Sandboxes. -To view the full field-by-field YAML definition, refer to the Policy Schema Reference. -To review the default policy breakdown, refer to Default Policy Reference. - - - - - -
- - - -Providers# -AI agents typically need credentials to access external services: an API key for the AI model provider, a token for GitHub or GitLab, and so on. OpenShell manages these credentials as first-class entities called providers. -Create and manage providers that supply credentials to sandboxes. - -Create a Provider# -Providers can be created from local environment variables or with explicit credential values. - -From Local Credentials# -The fastest way to create a provider is to let the CLI discover credentials from -your shell environment: -$ openshell provider create --name my-claude --type claude --from-existing - - -This reads ANTHROPIC_API_KEY or CLAUDE_API_KEY from your current environment -and stores them in the provider. - - -With Explicit Credentials# -Supply a credential value directly: -$ openshell provider create --name my-api --type generic --credential API_KEY=sk-abc123 - - - - -Bare Key Form# -Pass a key name without a value to read the value from the environment variable -of that name: -$ openshell provider create --name my-api --type generic --credential API_KEY - - -This looks up the current value of $API_KEY in your shell and stores it. - - - -Manage Providers# -List, inspect, update, and delete providers from the active cluster. -List all providers: -$ openshell provider list - - -Inspect a provider: -$ openshell provider get my-claude - - -Update a provider’s credentials: -$ openshell provider update my-claude --type claude --from-existing - - -Delete a provider: -$ openshell provider delete my-claude - - - - -Attach Providers to Sandboxes# -Pass one or more --provider flags when creating a sandbox: -$ openshell sandbox create --provider my-claude --provider my-github -- claude - - -Each --provider flag attaches one provider. The sandbox receives all -credentials from every attached provider at runtime. - -Warning -Providers cannot be added to a running sandbox. If you need to attach an -additional provider, delete the sandbox and recreate it with all required -providers specified. - - -Auto-Discovery Shortcut# -When the trailing command in openshell sandbox create is a recognized tool name (claude, codex, or opencode), the CLI auto-creates the required -provider from your local credentials if one does not already exist. You do not -need to create the provider separately: -$ openshell sandbox create -- claude - - -This detects claude as a known tool, finds your ANTHROPIC_API_KEY, creates -a provider, attaches it to the sandbox, and launches Claude Code. - - - -Supported Provider Types# -The following provider types are supported. - - -Type -Environment Variables Injected -Typical Use - - - -claude -ANTHROPIC_API_KEY, CLAUDE_API_KEY -Claude Code, Anthropic API - -codex -OPENAI_API_KEY -OpenAI Codex - -opencode -OPENCODE_API_KEY, OPENROUTER_API_KEY, OPENAI_API_KEY -opencode tool - -github -GITHUB_TOKEN, GH_TOKEN -GitHub API, gh CLI — refer to Set Up a Sandbox of Claude Code with a Custom GitHub Policy - -gitlab -GITLAB_TOKEN, GLAB_TOKEN, CI_JOB_TOKEN -GitLab API, glab CLI - -nvidia -NVIDIA_API_KEY -NVIDIA API Catalog - -generic -User-defined -Any service with custom credentials - -outlook -(none: no auto-discovery) -Microsoft Outlook integration - - - - - -Tip -Use the generic type for any service not listed above. You define the -environment variable names and values yourself with --credential. - - - -Next Steps# -Explore related topics: - -To control what the agent can access, refer to Customize Sandbox Policies. -To use a pre-built environment, refer to the Community Sandboxes catalog. -To view the complete field reference for the policy YAML, refer to the Policy Schema Reference. - - - - - -
- - - -Set Up a Sandbox of Claude Code with a Custom GitHub Policy# -This tutorial walks through an iterative sandbox policy workflow. You launch a sandbox, ask Claude Code to push code to GitHub, and observe the default network policy denying the request. -You then diagnose the denial from your machine and from inside the sandbox, apply a policy update, and verify that the policy update to the sandbox takes effect. -After completing this tutorial, you will have: - -A running sandbox with Claude Code that can push to a GitHub repository. -A custom network policy that grants GitHub access for a specific repository. -Experience with the policy iteration workflow: fail, diagnose, update, verify. - - -Note -This tutorial shows example prompts and responses from Claude Code. The exact wording you see might vary between sessions. Use the examples as a guide for the type of interaction, not as expected output. - - -Prerequisites# -This tutorial requires the following: - -A working OpenShell installation. Complete the Quickstart before proceeding. -A GitHub personal access token (PAT) with repo scope. Generate one from the GitHub personal access token settings page by selecting Generate new token (classic) and enabling the repo scope. -An Anthropic account with access to Claude Code. OpenShell provides the sandbox runtime, not the agent. You must authenticate with your own account. -A GitHub repository you own to use as the push target. A scratch repository is sufficient. You can create one with a README if needed. - -This tutorial uses two terminals to demonstrate the iterative policy workflow: - -Terminal 1: The sandbox terminal. You create the sandbox in this terminal by running openshell sandbox create and interact with Claude Code inside it. -Terminal 2: A terminal outside the sandbox on your machine. You use this terminal for viewing the sandbox logs with openshell term and applying an updated policy with openshell policy set. - -Each section below indicates which terminal to use. - - -Set Up a Sandbox with Your GitHub Token# -Depending on whether you start a new sandbox or use an existing sandbox, choose the appropriate tab and follow the instructions. - - - -Starting a new sandbox -In terminal 2, create a new sandbox with Claude Code. The default policy is applied automatically, which allows read-only access to GitHub. -Create a credential provider that injects your GitHub token into the sandbox automatically. The provider reads GITHUB_TOKEN from your host environment and sets it as an environment variable inside the sandbox: -$ GITHUB_TOKEN=<your-token> -$ openshell provider create --name my-github --type github --from-existing -$ openshell sandbox create --provider my-github -- claude - - -openshell sandbox create keeps the sandbox running after Claude Code exits, so you can apply policy updates later without recreating the environment. Add --no-keep if you want the sandbox deleted automatically instead. -Claude Code starts inside the sandbox. It prints an authentication link. Open it in your browser, sign in to your Anthropic account, and return to the terminal. When prompted, trust the /sandbox workspace to allow Claude Code to read and write files. - - - -Using an existing sandbox -In terminal 1, connect to a sandbox that is already running and set your GitHub token as an environment variable: -$ openshell sandbox connect <sandbox-name> -$ export GITHUB_TOKEN=<your-token> - - -To find the name of running sandboxes, run openshell sandbox list in terminal 2. - - - - -Push Code to GitHub# -In terminal 1, ask Claude Code to write a simple script and push it to your repository. Replace <org> with your GitHub organization or username and <repo> with your repository name. - - -Prompt -Write a hello_world.py script and push it to https://github.com/<org>/<repo>. - -Claude recognizes that it needs GitHub credentials. It asks how you want to authenticate. Provide your GitHub personal access token by pasting it into the conversation. Claude configures authentication and attempts the push. -The push fails. Claude reports an error, but the failure is not an authentication problem. The default sandbox policy permits read-only access to GitHub and blocks write operations, so the proxy denies the push before the request reaches the GitHub server. - - -Diagnose the Denial# -In this section, you diagnose the denial from your machine and from inside the sandbox. - -View the Logs from Your Machine# -In terminal 2, launch the OpenShell terminal: -$ openshell term - - -The dashboard shows sandbox status and a live stream of policy decisions. Look for entries with l7_decision=deny. Select a deny entry to see the full detail: -l7_action: PUT -l7_target: /repos/<org>/<repo>/contents/hello_world.py -l7_decision: deny -dst_host: api.github.com -dst_port: 443 -l7_protocol: rest -policy: github_rest_api -l7_deny_reason: PUT /repos/<org>/<repo>/contents/hello_world.py not permitted by policy - - -The log shows that the sandbox proxy intercepted an outbound PUT request to api.github.com and denied it. The github_rest_api policy allows read operations (GET) but blocks write operations (PUT, POST, DELETE) to the GitHub API. A similar denial appears for github.com if Claude attempted a git push over HTTPS. - - -Ask Claude Code to Check the Sandbox Logs# -In terminal 1, ask Claude Code to check the sandbox logs for denied requests: - - -Prompt -Check the sandbox logs for any denied network requests. What is blocking the push? - -Claude reads the deny entries and identifies the root cause. It explains that the failure is a sandbox network policy restriction, not a token permissions issue. For example, the following is a possible response: - - -Response -The sandbox runs a proxy that enforces policies on outbound traffic. -The github_rest_api policy allows GET requests (used to read the file) -but blocks PUT/write requests to GitHub. This is a sandbox-level restriction, -not a token issue. No matter what token you provide, pushes through the API -will be blocked until the policy is updated. - -Both perspectives confirm the same thing: the proxy is doing its job. The default policy is designed to be restrictive. To allow GitHub pushes, you need to update the network policy. -Copy the deny reason from Claude’s response. You paste it into an agent running on your machine in the next step. - - - -Update the Policy from Your Machine# -In terminal 2, paste the deny reason from the previous step into your coding agent on your machine, such as Claude Code or Cursor, and ask it to recommend a policy update. The deny reason gives the agent the context it needs to generate the correct policy rules. After pasting the following prompt sample, properly provide the GitHub organization and repository names of the repository you are pushing to. - - -Prompt -Based on the following deny reasons, recommend a sandbox policy update that allows GitHub pushes to https://github.com/<org>/<repo>, and save to /tmp/sandbox-policy-update.yaml: -The filesystem_policy, landlock, and process sections are static. They are read once at sandbox creation and cannot be changed by a hot-reload. They are included here for completeness so the file is self-contained, but only the network_policies section takes effect when you apply this to a running sandbox. - -The following steps outline the expected process done by the agent: - -Inspects the deny reasons. -Writes an updated policy that adds github_git and github_api blocks that grant write access to your repository. -Saves the policy to /tmp/sandbox-policy-update.yaml. - - - -Review the Generated Policy# -Refer to the following policy example to compare with the generated policy before applying it. Confirm that the policy grants only the access you expect. In this case, git push operations and GitHub REST API access scoped to a single repository. - - -Full reference policy -The following YAML shows a complete policy that extends the default policy with GitHub access for a single repository. Replace <org> with your GitHub organization or username and <repo> with your repository name. -The filesystem_policy, landlock, and process sections are static. They are read once at sandbox creation and cannot be changed by a hot-reload. They are included here for completeness so the file is self-contained, but only the network_policies section takes effect when you apply this to a running sandbox. -version: 1 - -# ── Static (locked at sandbox creation) ────────────────────────── - -filesystem_policy: - include_workdir: true - read_only: - - /usr - - /lib - - /proc - - /dev/urandom - - /app - - /etc - - /var/log - read_write: - - /sandbox - - /tmp - - /dev/null - -landlock: - compatibility: best_effort - -process: - run_as_user: sandbox - run_as_group: sandbox - -# ── Dynamic (hot-reloadable) ───────────────────────────────────── - -network_policies: - - # Claude Code ↔ Anthropic API - claude_code: - name: claude-code - endpoints: - - { host: api.anthropic.com, port: 443, protocol: rest, enforcement: enforce, access: full, tls: terminate } - - { host: statsig.anthropic.com, port: 443 } - - { host: sentry.io, port: 443 } - - { host: raw.githubusercontent.com, port: 443 } - - { host: platform.claude.com, port: 443 } - binaries: - - { path: /usr/local/bin/claude } - - { path: /usr/bin/node } - - # NVIDIA inference endpoint - nvidia_inference: - name: nvidia-inference - endpoints: - - { host: integrate.api.nvidia.com, port: 443 } - binaries: - - { path: /usr/bin/curl } - - { path: /bin/bash } - - { path: /usr/local/bin/opencode } - - # ── GitHub: git operations (clone, fetch, push) ────────────── - - github_git: - name: github-git - endpoints: - - host: github.com - port: 443 - protocol: rest - tls: terminate - enforcement: enforce - rules: - - allow: - method: GET - path: "/<org>/<repo>.git/info/refs*" - - allow: - method: POST - path: "/<org>/<repo>.git/git-upload-pack" - - allow: - method: POST - path: "/<org>/<repo>.git/git-receive-pack" - binaries: - - { path: /usr/bin/git } - - # ── GitHub: REST API ───────────────────────────────────────── - - github_api: - name: github-api - endpoints: - - host: api.github.com - port: 443 - protocol: rest - tls: terminate - enforcement: enforce - rules: - # GraphQL API (used by gh CLI) - - allow: - method: POST - path: "/graphql" - # Full read-write access to the repository - - allow: - method: "*" - path: "/repos/<org>/<repo>/**" - binaries: - - { path: /usr/local/bin/claude } - - { path: /usr/local/bin/opencode } - - { path: /usr/bin/gh } - - { path: /usr/bin/curl } - - # ── Package managers ───────────────────────────────────────── - - pypi: - name: pypi - endpoints: - - { host: pypi.org, port: 443 } - - { host: files.pythonhosted.org, port: 443 } - - { host: github.com, port: 443 } - - { host: objects.githubusercontent.com, port: 443 } - - { host: api.github.com, port: 443 } - - { host: downloads.python.org, port: 443 } - binaries: - - { path: /sandbox/.venv/bin/python } - - { path: /sandbox/.venv/bin/python3 } - - { path: /sandbox/.venv/bin/pip } - - { path: "/sandbox/.uv/python/**/python*" } - - { path: /usr/local/bin/uv } - - { path: "/sandbox/.uv/python/**" } - - # ── VS Code Remote ────────────────────────────────────────── - - vscode: - name: vscode - endpoints: - - { host: update.code.visualstudio.com, port: 443 } - - { host: "*.vo.msecnd.net", port: 443 } - - { host: vscode.download.prss.microsoft.com, port: 443 } - - { host: marketplace.visualstudio.com, port: 443 } - - { host: "*.gallerycdn.vsassets.io", port: 443 } - binaries: - - { path: /usr/bin/curl } - - { path: /usr/bin/wget } - - { path: "/sandbox/.vscode-server/**" } - - { path: "/sandbox/.vscode-remote-containers/**" } - - -The following table summarizes the two GitHub-specific blocks: - - -Block -Endpoint -Behavior - - - -github_git -github.com:443 -Git Smart HTTP protocol with TLS termination. Permits info/refs (clone/fetch), git-upload-pack (fetch data), and git-receive-pack (push) for the specified repository. Denies all operations on unlisted repositories. - -github_api -api.github.com:443 -REST API with TLS termination. Permits all HTTP methods for the specified repository and GraphQL queries. Denies API access to unlisted repositories. - - - - -The remaining blocks (claude_code, nvidia_inference, pypi, vscode) are identical to the default policy. The default policy’s github_ssh_over_https and github_rest_api blocks are replaced by the github_git and github_api blocks above, which grant write access to the specified repository. Sandbox behavior outside of GitHub operations is unchanged. -For details on policy block structure, refer to Network Access Rules. - - - -Apply the Policy# -After you have reviewed the generated policy, apply it to the running sandbox: -$ openshell policy set <sandbox-name> --policy /tmp/sandbox-policy-update.yaml --wait - - -Network policies are hot-reloadable. The --wait flag blocks until the policy engine confirms the new revision loaded, and the update takes effect immediately without restarting the sandbox or reconnecting Claude Code. - - -Retry the Push# -In terminal 1, ask Claude Code to retry the push: -The sandbox policy has been updated. Try pushing to the repository again. - - -The push completes successfully. The openshell term dashboard now shows l7_decision=allow entries for api.github.com and github.com where it previously showed denials. - - -Clean Up# -When you are finished, delete the sandbox to free cluster resources: -$ openshell sandbox delete <sandbox-name> - - - - -Next Steps# -The following resources cover related topics in greater depth: - -To add per-repository access levels (read-write vs read-only) or restrict to specific API methods, refer to the Policy Schema Reference. -To learn the full policy iteration workflow (pull, edit, push, verify), refer to Customize Sandbox Policies. -To inject credentials automatically instead of pasting tokens, refer to Providers. - - - - - -