Entorno de ejecución en sandbox para agentes de IA autónomos con políticas YAML declarativas que aplican restricciones de sistema de archivos, red y procesos, además de inyección de credenciales vinculadas al endpoint.
OpenShell es el entorno de ejecución seguro y privado para agentes de IA autónomos. Proporciona entornos de ejecución en sandbox que protegen tus datos, credenciales e infraestructura — gobernados por políticas YAML declarativas que impiden el acceso no autorizado a archivos, la exfiltración de datos y la actividad de red no controlada.
OpenShell está diseñado con un enfoque agent-first. Incluye habilidades de agente públicas para usar y operar OpenShell, además de flujos de trabajo separados con conocimiento del repositorio para colaboradores y mantenedores.
Binario (recomendado):```bash curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
El instalador instala la última versión estable por defecto. Para instalar una versión específica, configure `OPENSHELL_VERSION`. También está disponible una [versión `dev`](https://github.com/NVIDIA/OpenShell/releases/tag/dev) que sigue el último commit en `main`.
El paquete `openshell` en PyPI proporciona únicamente el SDK de Python. No instala la CLI `openshell`. Añada el SDK a un proyecto de Python con [uv](https://docs.astral.sh/uv/):```bash
uv add openshell
Helm chart:
Experimental — la ruta de despliegue en Kubernetes está en desarrollo activo. Espere asperezas y cambios que rompan la compatibilidad.
Despliegue la puerta de enlace de OpenShell en un clúster de Kubernetes desde el chart de OCI publicado en GHCR:```bash helm install openshell oci://ghcr.io/nvidia/openshell/helm-chart
Consulta [`deploy/helm/openshell/README.md`](https://github.com/nvidia/openshell/blob/main/deploy/helm/openshell/README.md) para conocer las versiones disponibles, las convenciones de etiquetas de desarrollo y la configuración.
Para desplegar OpenShell en OpenShift, consulta [`deploy/helm/openshell/README.md#install-on-openshift`](https://github.com/nvidia/openshell/blob/main/deploy/helm/openshell/README.md#install-on-openshift).
### Crear un sandbox```bash
openshell sandbox create -- claude # or opencode, codex, copilot
El contenedor sandbox incluye las siguientes herramientas por defecto:
Para más detalles, consulta https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base.
Cada sandbox comienza con acceso saliente mínimo. Puedes abrir acceso adicional con una breve política YAML que el proxy aplica a nivel de método y ruta HTTP, sin reiniciar nada.```bash
openshell sandbox create
sandbox$ curl -sS https://api.github.com/zen curl: (56) Received HTTP code 403 from proxy after CONNECT
sandbox$ exit openshell policy set demo --policy examples/sandbox-policy-quickstart/policy.yaml --wait
openshell sandbox connect demo sandbox$ curl -sS https://api.github.com/zen Anything added dilutes everything else.
sandbox$ curl -sS -X POST https://api.github.com/repos/octocat/hello-world/issues -d '{"title":"oops"}' {"error":"policy_denied","detail":"POST /repos/octocat/hello-world/issues not permitted by policy"}
Consulta el [recorrido completo](https://github.com/nvidia/openshell/blob/main/examples/sandbox-policy-quickstart) o ejecuta la demostración automatizada:```bash
bash examples/sandbox-policy-quickstart/demo.sh
OpenShell aísla cada sandbox en su propio contenedor con enrutamiento de egreso aplicado por políticas. Una puerta de enlace ligera coordina el ciclo de vida del sandbox, y cada conexión saliente es interceptada por el motor de políticas, que hace una de tres cosas:
OpenShell ejecuta un plano de control de puerta de enlace que gestiona el ciclo de vida del sandbox a través de un controlador de cómputo configurado. Las plataformas de cómputo compatibles incluyen Docker, Podman, MicroVM y Kubernetes.
OpenShell aplica defensa en profundidad a través de cuatro dominios de política:
Las políticas son archivos YAML declarativos. Las secciones estáticas (sistema de archivos, procesos) se bloquean en la creación; la política de red y las vinculaciones de proveedores se pueden actualizar en un sandbox en ejecución.
Los agentes necesitan credenciales — claves de API, tokens, cuentas de servicio. OpenShell las gestiona como proveedores: paquetes de credenciales con nombre que se inyectan en los sandboxes en el momento de la creación. La CLI descubre automáticamente las credenciales de agentes reconocidos (Claude, Codex, OpenCode, Copilot) desde tu entorno de shell, o puedes crear proveedores explícitamente con openshell provider create. Las credenciales nunca se filtran al sistema de archivos del sandbox; se inyectan como variables de entorno en tiempo de ejecución.
El acceso a inferencia utiliza el mismo flujo de trabajo de proveedores. Vincula un proveedor con capacidad de inferencia a un sandbox, llama al endpoint nativo del proveedor y selecciona el modelo en el cliente. Los perfiles de proveedor aportan la política de endpoints y vinculan los marcadores de posición de credenciales al destino autorizado.
Experimental — el paso directo de GPU funciona en hosts compatibles pero está en desarrollo activo. Espera asperezas y cambios disruptivos.
OpenShell puede pasar las GPU del host a los sandboxes para inferencia local, ajuste fino o cualquier carga de trabajo con GPU. Añade --gpu al crear un sandbox:```bash
openshell sandbox create --gpu --from [gpu-enabled-sandbox] -- claude
Los sandboxes de GPU respaldados por Docker seleccionan automáticamente CDI cuando está disponible y, de lo contrario, recurren a la ruta de solicitud de GPU de NVIDIA de Docker (`--gpus all`).
**Requisitos:** Los controladores de NVIDIA y el [NVIDIA Container Toolkit](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/install-guide.html) deben estar instalados en el host. La propia imagen del sandbox debe incluir los controladores y las bibliotecas de GPU adecuados para su carga de trabajo — la imagen `base` predeterminada no los incluye. Consulte el [ejemplo de BYOC](https://github.com/NVIDIA/OpenShell/tree/main/examples/bring-your-own-container) para crear una imagen de sandbox personalizada con soporte de GPU.
## Agentes compatibles
| Agente | Origen | Notas |
| ------------------------------------------------------------- | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| [Claude Code](https://docs.anthropic.com/en/docs/claude-code) | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | Funciona sin configuración adicional. El proveedor usa `ANTHROPIC_API_KEY`. |
| [OpenCode](https://opencode.ai/) | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | Funciona sin configuración adicional. El proveedor usa `OPENAI_API_KEY` o `OPENROUTER_API_KEY`. |
| [Codex](https://developers.openai.com/codex) | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | Funciona sin configuración adicional. El proveedor usa `OPENAI_API_KEY`. |
| [GitHub Copilot CLI](https://docs.github.com/en/copilot/github-copilot-in-the-cli) | [`base`](https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base) | Funciona sin configuración adicional. El proveedor usa `GITHUB_TOKEN` o `COPILOT_GITHUB_TOKEN`. |
| [OpenClaw](https://openclaw.ai/) | [NemoClaw](https://github.com/NVIDIA/NemoClaw) | Ejecute OpenClaw de forma más segura dentro de NVIDIA OpenShell con el blueprint de NemoClaw. |
| [Hermes Agent](https://github.com/NousResearch/hermes-agent) | [NemoClaw](https://github.com/NVIDIA/NemoClaw) | Ejecute Hermes Agent de forma más segura dentro de NVIDIA OpenShell con el blueprint de NemoClaw. |
| [Ollama](https://ollama.com/) | [Community](https://github.com/NVIDIA/OpenShell-Community) | Inicie con `openshell sandbox create --from ollama`. |
| [Pi](https://pi.dev/) | [Community](https://github.com/NVIDIA/OpenShell-Community) | Inicie con `openshell sandbox create --from pi`. |
## Comandos clave
| Comando | Descripción |
| ---------------------------------------------------------- | ----------------------------------------------- |
| `openshell sandbox create -- <agent>` | Cree un sandbox e inicie un agente. |
| `openshell sandbox connect [name]` | Conéctese por SSH a un sandbox en ejecución. |
| `openshell sandbox list` | Enumere todos los sandboxes. |
| `openshell provider create --type [type] --from-existing` | Cree un proveedor de credenciales a partir de variables de entorno. |
| `openshell sandbox provider attach <sandbox> <provider>` | Adjunte un proveedor a un sandbox en ejecución. |
| `openshell policy set <name> --policy file.yaml` | Aplique o actualice una política en un sandbox en ejecución. |
| `openshell policy get <name>` | Muestre la política activa. |
| `openshell logs [name] --tail` | Transmita los registros del sandbox. |
| `openshell term` | Inicie la interfaz de terminal en tiempo real para la depuración. |
Consulte la [documentación completa](https://docs.nvidia.com/openshell/latest) para guías de comandos, tutoriales y material de referencia.
## Interfaz de terminal
OpenShell incluye un panel de terminal en tiempo real para monitorear gateways, sandboxes y proveedores — inspirado en [k9s](https://k9scli.io/).```bash
openshell term
La TUI te ofrece una vista en vivo controlada por teclado de tu gateway y sandboxes. Navega con Tab para cambiar de panel, j/k para moverte por las listas, Enter para seleccionar y : para el modo comando. El estado del gateway y de los sandboxes se actualiza automáticamente cada dos segundos.
Usa --from para crear sandboxes desde el catálogo de OpenShell Community o desde una imagen de contenedor:```bash
openshell sandbox create --from gemini # community catalog
docker build -t my-sandbox:latest ./my-sandbox-dir # Docker gateway
openshell sandbox create --from my-sandbox:latest # Docker built image
podman build -t localhost/my-sandbox:latest ./my-sandbox-dir # Podman gateway
openshell sandbox create --from localhost/my-sandbox:latest # Podman built image
openshell sandbox create --from registry.io/img:v1 # container image
Compila con el motor de contenedores que utiliza tu gateway local. Para un gateway remoto, sube la imagen a un registro desde el que el gateway pueda descargarla.
Consulta el catálogo de [OpenShell Community](https://github.com/NVIDIA/OpenShell-Community) y el [ejemplo de BYOC](https://github.com/NVIDIA/OpenShell/tree/main/examples/bring-your-own-container) para más detalles.
## Usa OpenShell con tu agente
OpenShell proporciona cuatro skills portables para usuarios y operadores: flujos de trabajo de CLI (`openshell-cli`), solución de problemas del gateway (`debug-openshell-cluster`), solución de problemas de inferencia (`debug-inference`) y generación de políticas (`generate-sandbox-policy`). Instálalos con la CLI de Agent Skills:```bash
npx skills add NVIDIA/OpenShell
Estas habilidades públicas e instalables residen en skills/ y utilizan la ayuda del CLI instalado y la documentación publicada como sus fuentes de verdad. No requieren una copia del código fuente de OpenShell.
OpenShell se desarrolla utilizando los mismos flujos de trabajo impulsados por agentes que habilita. Las habilidades para colaboradores y mantenedores residen por separado en .agents/skills/; automatizan el trabajo en el repositorio de OpenShell y no se incluyen cuando los usuarios instalan las habilidades públicas:
create-spike; una persona lo acepta con state:accepted o su ubicación en el roadmap, o lo rechaza. El trabajo aceptado puede permanecer bajo responsabilidad humana o entrar en el flujo de trabajo opcional y controlado por humanos de planificación e implementación agent:*.triage-issue. Los agentes establecen la validez técnica y el impacto; los humanos deciden si el proyecto debe actuar y dónde se sitúa el trabajo en el roadmap.review-security-issue produce una evaluación de severidad y un plan de remediación. fix-security-issue lo implementa.sync-agent-infra, update-docs-from-commits y otros flujos de trabajo internos mantienen consistentes el código, la documentación y la infraestructura de agentes.La implementación por agentes está dirigida por humanos: un usuario puede solicitar una fase directamente, o los mantenedores pueden usar el flujo de trabajo opcional agent:* para encolar y aprobar la planificación e implementación. Consulta AGENTS.md para la documentación completa de la cadena de flujos de trabajo.
npx skills add NVIDIA/OpenShellrfcOpenShell se construye con un enfoque agent-first. Los issues deben incluir una historia de usuario, una declaración del problema, el impacto y los criterios de aceptación. El impacto debe explicar las consecuencias del comportamiento actual y por qué los workarounds existentes son insuficientes. Las solicitudes de funcionalidades también requieren un diseño propuesto a nivel de flujo de trabajo y alternativas; los informes de errores añaden pasos de reproducción, detalles del entorno y registros relevantes. Una vez que el trabajo está autorizado a través del flujo de trabajo del proyecto o una solicitud directa, los colaboradores deben usar las habilidades en .agents/skills/ para investigar el código y el comportamiento actuales, implementar el cambio y verificarlo. Si un issue contiene diagnósticos previos, verifícalos en lugar de confiar en ellos. Consulta CONTRIBUTING.md para la tabla completa de habilidades de agentes, el flujo de trabajo de contribución y la configuración de desarrollo.
OpenShell recopila telemetría anónima para ayudar a mejorar el proyecto para los desarrolladores. Estos datos no se utilizan para rastrear el comportamiento individual de los usuarios. Nos ayudan a comprender el uso agregado de los flujos de trabajo de sandbox, proveedores y políticas, de modo que podamos priorizar mejoras del producto y compartir tendencias de uso con la comunidad.
Desactiva la telemetría en tiempo de ejecución estableciendo OPENSHELL_TELEMETRY_ENABLED=false en el despliegue del gateway. Para instalaciones con Helm, establece server.telemetryEnabled=false. OpenShell propaga esta configuración de despliegue a los entornos del supervisor del sandbox para que la recopilación de telemetría del lado del sandbox también quede desactivada.
También puedes compilar sin telemetría por completo. El soporte de telemetría es una característica de Cargo telemetry activada por defecto, y cada crate que la incluye también define un alias defaults-without-telemetry que cubre todas las demás características por defecto. Compila artefactos sin telemetría con --no-default-features --features defaults-without-telemetry:```shell
cargo build --release -p openshell-gateway --no-default-features --features defaults-without-telemetry
cargo build --release -p openshell-sandbox --no-default-features --features defaults-without-telemetry
cargo build --release -p openshell-driver-vm --no-default-features --features defaults-without-telemetry
Los binarios resultantes no contienen ningún endpoint de telemetría, ningún cliente HTTP de telemetría ni código de emisión. Con la telemetría compilada fuera, el gateway no emite nada y reporta la telemetría como deshabilitada a los sandboxes que lanza. Cargo no tiene forma de restar una única característica predeterminada, por lo que `defaults-without-telemetry` debe combinarse con `--no-default-features`; pasarlo por sí solo deja los valores predeterminados en su lugar y hace fallar la compilación en lugar de producir un binario que siga emitiendo.
El gateway también expone características de Cargo separadas para sus controladores de cómputo integrados: `compute-driver-kubernetes`, `compute-driver-docker`, `compute-driver-podman`, `compute-driver-vm` y `compute-driver-mxc`. Deshabilite el conjunto de características predeterminado y, a continuación, habilite únicamente los controladores y el modo de telemetría requeridos por el binario de destino. Por ejemplo:```shell
# Docker only, with telemetry support.
cargo build --release -p openshell-gateway --no-default-features --features telemetry,compute-driver-docker
# Docker and VM only, with telemetry compiled out.
cargo build --release -p openshell-gateway --no-default-features --features compute-driver-docker,compute-driver-vm
# Windows MXC only, with telemetry support and bundled Z3.
cargo build --release -p openshell-gateway --no-default-features --features telemetry,compute-driver-mxc,bundled-z3
Las compilaciones regulares conservan su conjunto de controladores de plataforma a través de la característica de compatibilidad predeterminada in-tree-compute-drivers. En Windows, compute-driver-mxc selecciona MXC; las otras cuatro características instalan stubs de controladores no compatibles. En otras plataformas, MXC se excluye.
Los eventos de telemetría se limitan a categorías operativas anónimas y recuentos, como resultados del ciclo de vida del sandbox, agrupaciones de perfiles de proveedores, recuentos de decisiones de políticas y categorías agregadas de denegación de actividad de red. La telemetría de OpenShell no recopila nombres ni ID de sandbox, nombres de host, rutas de archivos, rutas de binarios, prompts, credenciales, nombres de proveedores, nombres de modelos ni contenido del usuario.
La exclusión voluntaria se aplica únicamente a la telemetría emitida por OpenShell. Los servicios de terceros, proveedores de modelos, endpoints de inferencia, agentes o herramientas que configures y utilices con OpenShell pueden tener sus propios términos y prácticas de privacidad.
Publicamos tendencias de uso agregadas a partir de esta telemetría cada dos semanas. Consulta los informes de telemetría de la comunidad para obtener el resumen más reciente.
Este software recupera, accede o interactúa automáticamente con materiales externos. Dichos materiales recuperados no se distribuyen con este software y se rigen únicamente por términos, condiciones y licencias separados. Eres el único responsable de encontrar, revisar y cumplir con todos los términos, condiciones y licencias aplicables, así como de verificar la seguridad, integridad e idoneidad de cualquier material recuperado para tu caso de uso específico. Este software se proporciona "TAL CUAL", sin garantía de ningún tipo. El autor no ofrece ninguna declaración ni garantía con respecto a los materiales recuperados, y no asume ninguna responsabilidad por pérdidas, daños, responsabilidades o consecuencias legales derivadas de tu uso o incapacidad de uso de este software o de cualquier material recuperado. Utiliza este software y los materiales recuperados bajo tu propio riesgo.
Este proyecto está licenciado bajo la Licencia Apache 2.0.
| Categoría | Herramientas |
|---|
| Agente | claude, opencode, codex, copilot |
| Lenguaje | python (3.14), node (22) |
| Desarrollador | gh, git, vim, nano |
| Redes | ping, dig, nslookup, nc, traceroute, netstat |
| Componente |
|---|
| Rol |
|---|
| Gateway | API del plano de control que coordina el ciclo de vida del sandbox y actúa como límite de autenticación. |
| Sandbox | Entorno de ejecución aislado con supervisión de contenedores y enrutamiento de egreso aplicado por políticas. |
| Policy Engine | Aplica restricciones de sistema de archivos, red y procesos desde la capa de aplicación hasta el kernel. |
| Provider Access | Endpoints definidos por perfil, política de binarios e inyección de credenciales vinculadas a endpoints para API de modelos y otros servicios. |
| Capa | Qué protege | Cuándo se aplica |
|---|
| Filesystem | Evita lecturas/escrituras fuera de las rutas permitidas. | Bloqueada en la creación del sandbox. |
| Network | Bloquea conexiones salientes no autorizadas. | Recargable en caliente en tiempo de ejecución. |
| Process | Bloquea la escalada de privilegios y llamadas al sistema peligrosas. | Bloqueada en la creación del sandbox. |
| Providers | Otorga credenciales vinculadas a endpoints y acceso a la red. | Recargable en caliente en tiempo de ejecución. |