Deploy preview for PR 677 🛫

pr-preview/pr-677/about/architecture.json

@@ -1 +1 @@
-{"id":"about/architecture","title":"How OpenShell Works","url":"about/architecture.html","last_modified":"2026-03-30T18:03:24.369520+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"OpenShell architecture overview covering the gateway, sandbox, policy engine, and privacy router.","tags":["AI Agents","Sandboxing","Security","Architecture"],"topics":["Generative AI","Cybersecurity"],"content_type":"concept","learning_level":"technical_beginner","audience":["engineer","data_scientist"],"content":"How OpenShell Works OpenShell runs inside a Docker container. Each sandbox is an isolated environment 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. If the target is https://inference.local , the proxy handles it as managed inference before policy evaluation. OpenShell strips sandbox-supplied credentials, injects the configured backend credentials, and forwards the request to the managed model endpoint. For every other destination, the proxy queries the policy engine with the destination, port, and calling binary. The policy engine returns one of two decisions: Allow - the destination and binary match a policy block. Traffic flows directly to the external service. Deny - no policy block matched. 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, on a remote host, or behind a cloud proxy. The architecture is identical in all cases — only the Docker container location and authentication mode change. Mode Description Command Local The gateway runs inside Docker on your workstation. The CLI provisions it automatically on first use. openshell gateway start Remote The gateway runs on a remote host via SSH. Only Docker is required on the remote machine. openshell gateway start --remote user@host Cloud A gateway already running behind a reverse proxy (e.g. Cloudflare Access). Register and authenticate via browser. openshell gateway add https://gateway.example.com You can register multiple gateways and switch between them with openshell gateway select . For the full deployment and management workflow, refer to the Gateways section. Next Steps Continue with one of the following: To deploy or register a gateway, refer to Gateways . To create your first sandbox, refer to the Quickstart . To learn how OpenShell enforces isolation across all protection layers, refer to Sandboxes","format":"text","summary":"OpenShell runs inside a Docker container. Each sandbox is an isolated environment managed through the gateway. Four components work together to keep agents secure.","headings":[{"text":"How OpenShell Works","level":1},{"text":"Components","level":2},{"text":"How a Request Flows","level":2},{"text":"Deployment Modes","level":2},{"text":"Next Steps","level":2}]}
+{"id":"about/architecture","title":"How OpenShell Works","url":"about/architecture.html","last_modified":"2026-03-30T18:08:14.776034+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"OpenShell architecture overview covering the gateway, sandbox, policy engine, and privacy router.","tags":["AI Agents","Sandboxing","Security","Architecture"],"topics":["Generative AI","Cybersecurity"],"content_type":"concept","learning_level":"technical_beginner","audience":["engineer","data_scientist"],"content":"How OpenShell Works OpenShell runs inside a Docker container. Each sandbox is an isolated environment 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. If the target is https://inference.local , the proxy handles it as managed inference before policy evaluation. OpenShell strips sandbox-supplied credentials, injects the configured backend credentials, and forwards the request to the managed model endpoint. For every other destination, the proxy queries the policy engine with the destination, port, and calling binary. The policy engine returns one of two decisions: Allow - the destination and binary match a policy block. Traffic flows directly to the external service. Deny - no policy block matched. 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, on a remote host, or behind a cloud proxy. The architecture is identical in all cases — only the Docker container location and authentication mode change. Mode Description Command Local The gateway runs inside Docker on your workstation. The CLI provisions it automatically on first use. openshell gateway start Remote The gateway runs on a remote host via SSH. Only Docker is required on the remote machine. openshell gateway start --remote user@host Cloud A gateway already running behind a reverse proxy (e.g. Cloudflare Access). Register and authenticate via browser. openshell gateway add https://gateway.example.com You can register multiple gateways and switch between them with openshell gateway select . For the full deployment and management workflow, refer to the Gateways section. Next Steps Continue with one of the following: To deploy or register a gateway, refer to Gateways . To create your first sandbox, refer to the Quickstart . To learn how OpenShell enforces isolation across all protection layers, refer to Sandboxes","format":"text","summary":"OpenShell runs inside a Docker container. Each sandbox is an isolated environment managed through the gateway. Four components work together to keep agents secure.","headings":[{"text":"How OpenShell Works","level":1},{"text":"Components","level":2},{"text":"How a Request Flows","level":2},{"text":"Deployment Modes","level":2},{"text":"Next Steps","level":2}]}

pr-preview/pr-677/about/overview.json

@@ -1 +1 @@
-{"id":"about/overview","title":"Overview of NVIDIA OpenShell","url":"about/overview.html","last_modified":"2026-03-30T18:03:24.379390+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"OpenShell is the safe, private runtime for autonomous AI agents. Run agents in sandboxed environments that protect your data, credentials, and infrastructure.","tags":["AI Agents","Sandboxing","Security","Privacy","Inference Routing"],"topics":["Generative AI","Cybersecurity"],"content_type":"concept","learning_level":"technical_beginner","audience":["engineer","data_scientist"],"content":"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 Sandbox Policies 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","format":"text","summary":"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 ...","headings":[{"text":"Overview of NVIDIA OpenShell","level":1},{"text":"Why OpenShell Exists","level":2},{"text":"Common Risks and Controls","level":2},{"text":"Protection Layers at a Glance","level":2},{"text":"Common Use Cases","level":2},{"text":"Next Steps","level":2}]}
+{"id":"about/overview","title":"Overview of NVIDIA OpenShell","url":"about/overview.html","last_modified":"2026-03-30T18:08:14.783524+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"OpenShell is the safe, private runtime for autonomous AI agents. Run agents in sandboxed environments that protect your data, credentials, and infrastructure.","tags":["AI Agents","Sandboxing","Security","Privacy","Inference Routing"],"topics":["Generative AI","Cybersecurity"],"content_type":"concept","learning_level":"technical_beginner","audience":["engineer","data_scientist"],"content":"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 Sandbox Policies 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","format":"text","summary":"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 ...","headings":[{"text":"Overview of NVIDIA OpenShell","level":1},{"text":"Why OpenShell Exists","level":2},{"text":"Common Risks and Controls","level":2},{"text":"Protection Layers at a Glance","level":2},{"text":"Common Use Cases","level":2},{"text":"Next Steps","level":2}]}

pr-preview/pr-677/about/release-notes.json

@@ -1 +1 @@
-{"id":"about/release-notes","title":"NVIDIA OpenShell Release Notes","url":"about/release-notes.html","last_modified":"2026-03-30T18:03:24.394656+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"Track the latest changes and improvements to NVIDIA OpenShell.","tags":["Release Notes","Changelog","AI Agents"],"topics":["Generative AI","Cybersecurity"],"content_type":"reference","learning_level":"technical_beginner","audience":["engineer","data_scientist"],"content":"NVIDIA OpenShell Release Notes NVIDIA OpenShell follows a frequent release cadence. Use the following GitHub resources directly. Resource Description Releases Versioned release notes and downloadable assets. Release comparison Diff between any two tags or branches. Merged pull requests Individual changes with review discussion. Commit history Full commit log on main","format":"text","summary":"NVIDIA OpenShell follows a frequent release cadence. Use the following GitHub resources directly.","headings":[{"text":"NVIDIA OpenShell Release Notes","level":1}]}
+{"id":"about/release-notes","title":"NVIDIA OpenShell Release Notes","url":"about/release-notes.html","last_modified":"2026-03-30T18:08:14.786041+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"Track the latest changes and improvements to NVIDIA OpenShell.","tags":["Release Notes","Changelog","AI Agents"],"topics":["Generative AI","Cybersecurity"],"content_type":"reference","learning_level":"technical_beginner","audience":["engineer","data_scientist"],"content":"NVIDIA OpenShell Release Notes NVIDIA OpenShell follows a frequent release cadence. Use the following GitHub resources directly. Resource Description Releases Versioned release notes and downloadable assets. Release comparison Diff between any two tags or branches. Merged pull requests Individual changes with review discussion. Commit history Full commit log on main","format":"text","summary":"NVIDIA OpenShell follows a frequent release cadence. Use the following GitHub resources directly.","headings":[{"text":"NVIDIA OpenShell Release Notes","level":1}]}

pr-preview/pr-677/about/supported-agents.json

@@ -1 +1 @@
-{"id":"about/supported-agents","title":"Supported Agents","url":"about/supported-agents.html","last_modified":"2026-03-30T18:03:24.397008+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"content":"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 . 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 . GitHub Copilot CLI base Full coverage Pre-installed. Works out of the box. Requires GITHUB_TOKEN or COPILOT_GITHUB_TOKEN . OpenClaw openclaw Bundled Agent orchestration layer. Launch with openshell sandbox create --from openclaw . Ollama ollama Bundled Run cloud and local models. Includes Claude Code, Codex, and OpenCode. Launch with openshell sandbox create --from ollama . More community agent sandboxes are available in the ../sandboxes/community-sandboxes catalog. For a complete support matrix, refer to the ../reference/support-matrix page","format":"text","summary":"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.","headings":[{"text":"Supported Agents","level":1}]}
+{"id":"about/supported-agents","title":"Supported Agents","url":"about/supported-agents.html","last_modified":"2026-03-30T18:08:14.791831+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"content":"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 . 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 . GitHub Copilot CLI base Full coverage Pre-installed. Works out of the box. Requires GITHUB_TOKEN or COPILOT_GITHUB_TOKEN . OpenClaw openclaw Bundled Agent orchestration layer. Launch with openshell sandbox create --from openclaw . Ollama ollama Bundled Run cloud and local models. Includes Claude Code, Codex, and OpenCode. Launch with openshell sandbox create --from ollama . More community agent sandboxes are available in the ../sandboxes/community-sandboxes catalog. For a complete support matrix, refer to the ../reference/support-matrix page","format":"text","summary":"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.","headings":[{"text":"Supported Agents","level":1}]}

pr-preview/pr-677/get-started/quickstart.json

@@ -1 +1 @@
-{"id":"get-started/quickstart","title":"Quickstart","url":"get-started/quickstart.html","last_modified":"2026-03-30T18:03:24.400901+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"Install the OpenShell CLI and create your first sandboxed AI agent in two commands.","tags":["AI Agents","Sandboxing","Installation","Quickstart"],"topics":["Generative AI","Cybersecurity"],"content_type":"get_started","learning_level":"technical_beginner","audience":["engineer","data_scientist"],"content":"Quickstart This page gets you from zero to a running, policy-enforced sandbox in two commands. Prerequisites Before you begin, make sure you have: Docker Desktop running on your machine. For a complete list of requirements, refer to ../reference/support-matrix . Install the OpenShell CLI Run the install script: $ curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh\nIf you prefer uv : $ uv tool install -U openshell\nAfter installing the CLI, run openshell --help in your terminal to see the full CLI reference, including all commands and flags. You can also clone the NVIDIA OpenShell GitHub repository and use the /openshell-cli skill to load the CLI reference into your agent. Create Your First OpenShell Sandbox Create a sandbox and launch an agent inside it\nChoose the tab that matches your agent: Claude Code Run the following command to create a sandbox with Claude Code: $ openshell sandbox create -- claude\nThe CLI prompts you to create a provider from local credentials\nType yes to continue\nIf ANTHROPIC_API_KEY is set in your environment, the CLI picks it up automatically\nIf 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\nThe CLI prompts you to create a provider from local credentials\nType yes to continue\nIf OPENAI_API_KEY or OPENROUTER_API_KEY is set in your environment, the CLI picks it up automatically\nIf 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\nThe CLI prompts you to create a provider from local credentials\nType yes to continue\nIf OPENAI_API_KEY is set in your environment, the CLI picks it up automatically\nIf 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\nThe --from flag pulls a pre-built sandbox definition from the OpenShell Community catalog\nEach definition bundles a container image, a tailored policy, and optional skills into a single package. Community Sandbox Use the --from flag to pull other OpenShell sandbox images from the NVIDIA Container Registry\nFor example, to pull the base image, run the following command: $ openshell sandbox create --from base\nDeploy a Gateway (Optional) Running openshell sandbox create without a gateway auto-bootstraps a local one\nTo start the gateway explicitly or deploy to a remote host, choose the tab that matches your setup. Brev Deploy an OpenShell gateway on Brev by clicking Deploy on the OpenShell Launchable . After the instance starts running, find the gateway URL in the Brev console under Using Secure Links\nCopy the shareable URL for port 8080 , which is the gateway endpoint. $ openshell gateway add https://<your-port-8080-url>.brevlab.com\nopenshell status\nDGX Spark 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\nopenshell status\nAfter openshell status shows the gateway as healthy, all subsequent commands route through the SSH tunnel","format":"text","summary":"This page gets you from zero to a running, policy-enforced sandbox in two commands.","headings":[{"text":"Quickstart","level":1},{"text":"Prerequisites","level":2},{"text":"Install the OpenShell CLI","level":2},{"text":"Create Your First OpenShell Sandbox","level":2},{"text":"Deploy a Gateway (Optional)","level":2}]}
+{"id":"get-started/quickstart","title":"Quickstart","url":"get-started/quickstart.html","last_modified":"2026-03-30T18:08:14.796455+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"Install the OpenShell CLI and create your first sandboxed AI agent in two commands.","tags":["AI Agents","Sandboxing","Installation","Quickstart"],"topics":["Generative AI","Cybersecurity"],"content_type":"get_started","learning_level":"technical_beginner","audience":["engineer","data_scientist"],"content":"Quickstart This page gets you from zero to a running, policy-enforced sandbox in two commands. Prerequisites Before you begin, make sure you have: Docker Desktop running on your machine. For a complete list of requirements, refer to ../reference/support-matrix . Install the OpenShell CLI Run the install script: $ curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh\nIf you prefer uv : $ uv tool install -U openshell\nAfter installing the CLI, run openshell --help in your terminal to see the full CLI reference, including all commands and flags. You can also clone the NVIDIA OpenShell GitHub repository and use the /openshell-cli skill to load the CLI reference into your agent. Create Your First OpenShell Sandbox Create a sandbox and launch an agent inside it\nChoose the tab that matches your agent: Claude Code Run the following command to create a sandbox with Claude Code: $ openshell sandbox create -- claude\nThe CLI prompts you to create a provider from local credentials\nType yes to continue\nIf ANTHROPIC_API_KEY is set in your environment, the CLI picks it up automatically\nIf 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\nThe CLI prompts you to create a provider from local credentials\nType yes to continue\nIf OPENAI_API_KEY or OPENROUTER_API_KEY is set in your environment, the CLI picks it up automatically\nIf 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\nThe CLI prompts you to create a provider from local credentials\nType yes to continue\nIf OPENAI_API_KEY is set in your environment, the CLI picks it up automatically\nIf 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\nThe --from flag pulls a pre-built sandbox definition from the OpenShell Community catalog\nEach definition bundles a container image, a tailored policy, and optional skills into a single package. Community Sandbox Use the --from flag to pull other OpenShell sandbox images from the NVIDIA Container Registry\nFor example, to pull the base image, run the following command: $ openshell sandbox create --from base\nDeploy a Gateway (Optional) Running openshell sandbox create without a gateway auto-bootstraps a local one\nTo start the gateway explicitly or deploy to a remote host, choose the tab that matches your setup. Brev Deploy an OpenShell gateway on Brev by clicking Deploy on the OpenShell Launchable . After the instance starts running, find the gateway URL in the Brev console under Using Secure Links\nCopy the shareable URL for port 8080 , which is the gateway endpoint. $ openshell gateway add https://<your-port-8080-url>.brevlab.com\nopenshell status\nDGX Spark 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\nopenshell status\nAfter openshell status shows the gateway as healthy, all subsequent commands route through the SSH tunnel","format":"text","summary":"This page gets you from zero to a running, policy-enforced sandbox in two commands.","headings":[{"text":"Quickstart","level":1},{"text":"Prerequisites","level":2},{"text":"Install the OpenShell CLI","level":2},{"text":"Create Your First OpenShell Sandbox","level":2},{"text":"Deploy a Gateway (Optional)","level":2}]}

pr-preview/pr-677/reference/default-policy.json

@@ -1 +1 @@
-{"id":"reference/default-policy","title":"Default Policy Reference","url":"reference/default-policy.html","last_modified":"2026-03-30T18:03:24.429845+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"Breakdown of the built-in default policy applied when you create an OpenShell sandbox without a custom policy.","tags":["ai_agents","sandboxing","security","policy"],"topics":["generative_ai","cybersecurity"],"content_type":"reference","learning_level":"technical_beginner","audience":["engineer","data_scientist"],"keywords":["openshell default policy","sandbox policy","agent compatibility"],"content":"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. 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","format":"text","summary":"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.","headings":[{"text":"Default Policy Reference","level":1},{"text":"Agent Compatibility","level":2},{"text":"Default Policy Blocks","level":2}]}
+{"id":"reference/default-policy","title":"Default Policy Reference","url":"reference/default-policy.html","last_modified":"2026-03-30T18:08:14.817328+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"Breakdown of the built-in default policy applied when you create an OpenShell sandbox without a custom policy.","tags":["ai_agents","sandboxing","security","policy"],"topics":["generative_ai","cybersecurity"],"content_type":"reference","learning_level":"technical_beginner","audience":["engineer","data_scientist"],"keywords":["openshell default policy","sandbox policy","agent compatibility"],"content":"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. 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","format":"text","summary":"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.","headings":[{"text":"Default Policy Reference","level":1},{"text":"Agent Compatibility","level":2},{"text":"Default Policy Blocks","level":2}]}

pr-preview/pr-677/reference/gateway-auth.json

@@ -1 +1 @@
-{"id":"reference/gateway-auth","title":"Gateway Authentication","url":"reference/gateway-auth.html","last_modified":"2026-03-30T18:03:24.437232+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"Gateway resolution, authentication modes, connection flow, and credential file layout.","tags":["Gateway","Authentication","mTLS","Edge Authentication","Reference"],"topics":["Generative AI","Cybersecurity"],"content_type":"reference","learning_level":"technical_intermediate","audience":["engineer"],"content":"Gateway Authentication This page describes how the CLI resolves a gateway, authenticates with it, and where credentials are stored. For how to deploy or register gateways, refer to /sandboxes/manage-sandboxes . Gateway Resolution When any CLI command needs to talk to the gateway, it resolves the target through a priority chain: --gateway-endpoint <URL> flag (direct URL). -g <NAME> flag. OPENSHELL_GATEWAY environment variable. Active gateway from ~/.config/openshell/active_gateway . The CLI loads gateway metadata from disk to determine the endpoint URL and authentication mode. Authentication Modes The CLI uses one of three connection modes depending on the gateway’s authentication configuration. mTLS (local and remote gateways) The default mode for self-deployed gateways. When you run gateway start or gateway add --local / gateway add --remote , the CLI extracts mTLS certificates from the running container and stores them locally. Every subsequent request presents a client certificate to prove identity. The CLI loads three PEM files from ~/.config/openshell/gateways/<name>/mtls/ : File Purpose ca.crt CA certificate. Verifies the gateway’s server certificate. tls.crt Client certificate. Proves the CLI’s identity to the gateway. tls.key Client private key. The connection flow: The CLI loads the three certificate files. Opens a TCP connection to the gateway endpoint. Performs a TLS handshake, presenting the client certificate. The gateway verifies the client certificate against its CA. An HTTP/2 channel is established. All CLI commands use this channel. Edge JWT (cloud gateways) For gateways behind a reverse proxy that handles authentication (e.g. Cloudflare Access), the CLI uses a browser-based login flow and routes traffic through a WebSocket tunnel. Registration flow ( openshell gateway add https://gateway.example.com ): The CLI stores gateway metadata with the edge authentication mode. Opens your browser to the gateway’s authentication endpoint. The reverse proxy handles login (SSO, identity provider, etc.). After authentication, the browser relays the authorization token back to the CLI via a localhost callback. The CLI stores the token and sets the gateway as active. Connection flow (subsequent commands): The CLI starts a local proxy that listens on an ephemeral port. The proxy opens a WebSocket connection ( wss:// ) to the gateway, attaching the stored bearer token in the upgrade headers. The reverse proxy authenticates the WebSocket upgrade request. The gateway bridges the WebSocket into the same service that handles direct mTLS connections. CLI commands send requests through the local proxy as plaintext HTTP/2 over the tunnel. This is transparent to the user. All CLI commands work the same regardless of whether the gateway uses mTLS or edge authentication. Re-authentication : If the token expires, run openshell gateway login to open the browser flow again and update the stored token. Plaintext When a gateway is deployed with --plaintext , TLS is disabled entirely. The CLI connects over plain HTTP/2. This mode is intended for gateways behind a trusted reverse proxy or tunnel that handles TLS termination externally. File Layout All gateway credentials and metadata are stored under ~/.config/openshell/ : openshell\nactive_gateway # Plain text: active gateway name\ngateways\nname\nmetadata.json # Gateway metadata (endpoint, auth mode, type\nmtls/ # mTLS bundle (local and remote gateways\nca.crt # CA certificate\ntls.crt # Client certificate\ntls.key # Client private key\nedge_token # Edge auth JWT (cloud gateways\nlast_sandbox # Last-used sandbox for this gateway","format":"text","summary":"This page describes how the CLI resolves a gateway, authenticates with it, and where credentials are stored. For how to deploy or register gateways, refer to /sandboxes/manage-sandboxes.","headings":[{"text":"Gateway Authentication","level":1},{"text":"Gateway Resolution","level":2},{"text":"Authentication Modes","level":2},{"text":"mTLS (local and remote gateways)","level":3},{"text":"Edge JWT (cloud gateways)","level":3},{"text":"Plaintext","level":3},{"text":"File Layout","level":2}]}
+{"id":"reference/gateway-auth","title":"Gateway Authentication","url":"reference/gateway-auth.html","last_modified":"2026-03-30T18:08:14.821434+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"Gateway resolution, authentication modes, connection flow, and credential file layout.","tags":["Gateway","Authentication","mTLS","Edge Authentication","Reference"],"topics":["Generative AI","Cybersecurity"],"content_type":"reference","learning_level":"technical_intermediate","audience":["engineer"],"content":"Gateway Authentication This page describes how the CLI resolves a gateway, authenticates with it, and where credentials are stored. For how to deploy or register gateways, refer to /sandboxes/manage-sandboxes . Gateway Resolution When any CLI command needs to talk to the gateway, it resolves the target through a priority chain: --gateway-endpoint <URL> flag (direct URL). -g <NAME> flag. OPENSHELL_GATEWAY environment variable. Active gateway from ~/.config/openshell/active_gateway . The CLI loads gateway metadata from disk to determine the endpoint URL and authentication mode. Authentication Modes The CLI uses one of three connection modes depending on the gateway’s authentication configuration. mTLS (local and remote gateways) The default mode for self-deployed gateways. When you run gateway start or gateway add --local / gateway add --remote , the CLI extracts mTLS certificates from the running container and stores them locally. Every subsequent request presents a client certificate to prove identity. The CLI loads three PEM files from ~/.config/openshell/gateways/<name>/mtls/ : File Purpose ca.crt CA certificate. Verifies the gateway’s server certificate. tls.crt Client certificate. Proves the CLI’s identity to the gateway. tls.key Client private key. The connection flow: The CLI loads the three certificate files. Opens a TCP connection to the gateway endpoint. Performs a TLS handshake, presenting the client certificate. The gateway verifies the client certificate against its CA. An HTTP/2 channel is established. All CLI commands use this channel. Edge JWT (cloud gateways) For gateways behind a reverse proxy that handles authentication (e.g. Cloudflare Access), the CLI uses a browser-based login flow and routes traffic through a WebSocket tunnel. Registration flow ( openshell gateway add https://gateway.example.com ): The CLI stores gateway metadata with the edge authentication mode. Opens your browser to the gateway’s authentication endpoint. The reverse proxy handles login (SSO, identity provider, etc.). After authentication, the browser relays the authorization token back to the CLI via a localhost callback. The CLI stores the token and sets the gateway as active. Connection flow (subsequent commands): The CLI starts a local proxy that listens on an ephemeral port. The proxy opens a WebSocket connection ( wss:// ) to the gateway, attaching the stored bearer token in the upgrade headers. The reverse proxy authenticates the WebSocket upgrade request. The gateway bridges the WebSocket into the same service that handles direct mTLS connections. CLI commands send requests through the local proxy as plaintext HTTP/2 over the tunnel. This is transparent to the user. All CLI commands work the same regardless of whether the gateway uses mTLS or edge authentication. Re-authentication : If the token expires, run openshell gateway login to open the browser flow again and update the stored token. Plaintext When a gateway is deployed with --plaintext , TLS is disabled entirely. The CLI connects over plain HTTP/2. This mode is intended for gateways behind a trusted reverse proxy or tunnel that handles TLS termination externally. File Layout All gateway credentials and metadata are stored under ~/.config/openshell/ : openshell\nactive_gateway # Plain text: active gateway name\ngateways\nname\nmetadata.json # Gateway metadata (endpoint, auth mode, type\nmtls/ # mTLS bundle (local and remote gateways\nca.crt # CA certificate\ntls.crt # Client certificate\ntls.key # Client private key\nedge_token # Edge auth JWT (cloud gateways\nlast_sandbox # Last-used sandbox for this gateway","format":"text","summary":"This page describes how the CLI resolves a gateway, authenticates with it, and where credentials are stored. For how to deploy or register gateways, refer to /sandboxes/manage-sandboxes.","headings":[{"text":"Gateway Authentication","level":1},{"text":"Gateway Resolution","level":2},{"text":"Authentication Modes","level":2},{"text":"mTLS (local and remote gateways)","level":3},{"text":"Edge JWT (cloud gateways)","level":3},{"text":"Plaintext","level":3},{"text":"File Layout","level":2}]}

pr-preview/pr-677/reference/support-matrix.json

@@ -1 +1 @@
-{"id":"reference/support-matrix","title":"Support Matrix","url":"reference/support-matrix.html","last_modified":"2026-03-30T18:03:24.465579+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"content":"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 Experimental 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 through 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 ../about/supported-agents page","format":"text","summary":"This page lists the platform, software, runtime, and kernel requirements for running OpenShell.","headings":[{"text":"Support Matrix","level":1},{"text":"Supported Platforms","level":2},{"text":"Software Prerequisites","level":2},{"text":"Sandbox Runtime Versions","level":2},{"text":"Container Images","level":2},{"text":"Kernel Requirements","level":2},{"text":"Agent Compatibility","level":2}]}
+{"id":"reference/support-matrix","title":"Support Matrix","url":"reference/support-matrix.html","last_modified":"2026-03-30T18:08:14.837809+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"content":"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 Experimental 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 through 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 ../about/supported-agents page","format":"text","summary":"This page lists the platform, software, runtime, and kernel requirements for running OpenShell.","headings":[{"text":"Support Matrix","level":1},{"text":"Supported Platforms","level":2},{"text":"Software Prerequisites","level":2},{"text":"Sandbox Runtime Versions","level":2},{"text":"Container Images","level":2},{"text":"Kernel Requirements","level":2},{"text":"Agent Compatibility","level":2}]}

pr-preview/pr-677/sandboxes/community-sandboxes.json

@@ -1 +1 @@
-{"id":"sandboxes/community-sandboxes","title":"Community Sandboxes","url":"sandboxes/community-sandboxes.html","last_modified":"2026-03-30T18:03:24.480968+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"Use pre-built sandboxes from the OpenShell Community catalog or contribute your own.","tags":["Community","Sandbox","Container Image","Open Source"],"topics":["Generative AI","Cybersecurity"],"content_type":"concept","learning_level":"technical_beginner","audience":["engineer","data_scientist"],"content":"Community Sandboxes Use pre-built sandboxes from the OpenShell Community catalog, or contribute your\nown. What Are Community Sandboxes Community sandboxes are ready-to-use environments published in the\nOpenShell Community repository\nEach sandbox bundles a Dockerfile, policy, optional skills, and startup scripts\ninto 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 ollama Ollama with cloud and local model support, Claude Code, OpenCode, and Codex pre-installed. Use ollama launch inside the sandbox to start coding agents with zero config. openclaw Open agent manipulation and control sdg Synthetic data generation workflows Use a Community Sandbox Launch a community sandbox by name with the --from flag: $ openshell sandbox create --from openclaw\nWhen you pass --from with a community sandbox name, the CLI: Resolves the name against the\nOpenShell 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\npreconfigured by the community package. Other Sources The --from flag also accepts: Local directory paths: Point to a directory on disk that contains a\nDockerfile and optional policy/skills: $ openshell sandbox create --from ./my-sandbox-dir\nContainer image references: Use an existing container image directly: $ openshell sandbox create --from my-registry.example.com/my-image:latest\nContribute a Community Sandbox Each community sandbox is a directory under sandboxes/ in the\nOpenShell Community repository\nAt minimum, a sandbox directory must contain the following files: Dockerfile that defines the container image. README.md that describes the sandbox and how to use it. You can also include the following optional files: policy.yaml that defines the default policy applied when the sandbox launches. skills/ that contains agent skill definitions bundled with the sandbox. Startup scripts that are any scripts the Dockerfile or entrypoint invokes. To contribute, fork the repository, add your sandbox directory, and open a pull\nrequest. Refer to the repository’s\nCONTRIBUTING.md\nfor submission guidelines. The community catalog is designed to grow. If you have built a sandbox that\nsupports a particular workflow (data processing, simulation, code review\nor 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 manage-providers for credential management. Want to customize the sandbox policy? Write custom rules in policies","format":"text","summary":"Use pre-built sandboxes from the OpenShell Community catalog, or contribute your own.","headings":[{"text":"Community Sandboxes","level":1},{"text":"What Are Community Sandboxes","level":2},{"text":"Current Catalog","level":2},{"text":"Use a Community Sandbox","level":2},{"text":"Other Sources","level":3},{"text":"Contribute a Community Sandbox","level":2},{"text":"Next Steps","level":2}]}
+{"id":"sandboxes/community-sandboxes","title":"Community Sandboxes","url":"sandboxes/community-sandboxes.html","last_modified":"2026-03-30T18:08:14.851079+00:00","book":{"title":"NVIDIA OpenShell Developer Guide","version":"latest"},"product":{"name":"OpenShell","version":"latest"},"description":"Use pre-built sandboxes from the OpenShell Community catalog or contribute your own.","tags":["Community","Sandbox","Container Image","Open Source"],"topics":["Generative AI","Cybersecurity"],"content_type":"concept","learning_level":"technical_beginner","audience":["engineer","data_scientist"],"content":"Community Sandboxes Use pre-built sandboxes from the OpenShell Community catalog, or contribute your\nown. What Are Community Sandboxes Community sandboxes are ready-to-use environments published in the\nOpenShell Community repository\nEach sandbox bundles a Dockerfile, policy, optional skills, and startup scripts\ninto 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 ollama Ollama with cloud and local model support, Claude Code, OpenCode, and Codex pre-installed. Use ollama launch inside the sandbox to start coding agents with zero config. openclaw Open agent manipulation and control sdg Synthetic data generation workflows Use a Community Sandbox Launch a community sandbox by name with the --from flag: $ openshell sandbox create --from openclaw\nWhen you pass --from with a community sandbox name, the CLI: Resolves the name against the\nOpenShell 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\npreconfigured by the community package. Other Sources The --from flag also accepts: Local directory paths: Point to a directory on disk that contains a\nDockerfile and optional policy/skills: $ openshell sandbox create --from ./my-sandbox-dir\nContainer image references: Use an existing container image directly: $ openshell sandbox create --from my-registry.example.com/my-image:latest\nContribute a Community Sandbox Each community sandbox is a directory under sandboxes/ in the\nOpenShell Community repository\nAt minimum, a sandbox directory must contain the following files: Dockerfile that defines the container image. README.md that describes the sandbox and how to use it. You can also include the following optional files: policy.yaml that defines the default policy applied when the sandbox launches. skills/ that contains agent skill definitions bundled with the sandbox. Startup scripts that are any scripts the Dockerfile or entrypoint invokes. To contribute, fork the repository, add your sandbox directory, and open a pull\nrequest. Refer to the repository’s\nCONTRIBUTING.md\nfor submission guidelines. The community catalog is designed to grow. If you have built a sandbox that\nsupports a particular workflow (data processing, simulation, code review\nor 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 manage-providers for credential management. Want to customize the sandbox policy? Write custom rules in policies","format":"text","summary":"Use pre-built sandboxes from the OpenShell Community catalog, or contribute your own.","headings":[{"text":"Community Sandboxes","level":1},{"text":"What Are Community Sandboxes","level":2},{"text":"Current Catalog","level":2},{"text":"Use a Community Sandbox","level":2},{"text":"Other Sources","level":3},{"text":"Contribute a Community Sandbox","level":2},{"text":"Next Steps","level":2}]}