NVIDIA's agent sandbox OpenShell gained 2,456 GitHub stars in a day, the same week reports said it stops after 2 hours 16 minutes

This week's biggest topic in the AI agent world wasn't a new model. It was a "box" for confining AI agents while they run. NVIDIA's OpenShell climbed rapidly on GitHub's trending charts over the past three days.

In the same week that its star count rose, however, bug reports from people who had actually started using it piled up just as quickly. We did not run OpenShell ourselves for this report. It is based on the repository, its issue tracker, where users report bugs and request features, and NVIDIA's official blog.

2,456 stars in a day. What is NVIDIA's "box"?

OpenShell is a sandbox for autonomous AI agents: an isolated environment that keeps an agent from doing harm outside it. It is written in Rust and released under the Apache 2.0 license, so anyone can inspect, modify and use the code.

Broadly, it provides three layers of protection:

• Kernel-level isolation: at the deepest layer of the operating system, the agent's environment is strictly separated from the host machine
• Policies: rules define which files the agent may touch, which system calls (the interface programs use to ask the OS to do things) it may make, and which network destinations it may reach
• No real credentials: the agent can do its work without ever seeing the actual API keys or passwords

Letting an agent run arbitrary commands is risky. OpenShell's answer is to put the entire foundation of the harness, the framework that controls an agent's actions and tool use, inside a box. An official post on NVIDIA Perspectives says a single command, openshell sandbox create -- claude, launches Claude Code in isolation, which shows how much NVIDIA is emphasizing ease of use.

Then there are the growth figures. According to agents-radar, which tracks trending repositories, OpenShell gained 1,281 stars on Oct. 1 and 2,456 on Oct. 2, so its growth sped up. The repository itself showed 14.4k stars and 1.7k forks as of Oct. 3. The latest release, v0.1.2, came out on Sept. 28, so a crowd gathered in less than a week.

A box that goes silent after 4,096 runs: about 2 hours 16 minutes at one command every 2 seconds

The most striking report was Issue #4103, filed by drew.

Each time the sandbox is asked to run a command, it issues an "execution request ID." IDs for finished requests should be cleaned up, but according to the report they are never removed and keep accumulating. Once there are more than 4,096 of them, the sandbox refuses all new executions. Reproducing the bug is very simple: run the true command, which does nothing and exits successfully, 4,097 times in a row. The report says the bug affects every driver (the backend that runs the sandbox) from v0.1.0 through v0.1.2.

4,096 runs sounds like a lot, but it isn't. An automation that sends one command every 2 seconds reaches the limit after 4,096 × 2 = 8,192 seconds, or about 2 hours 16 minutes. Agents run many small commands as they read files, run tests and apply fixes, so a job meant to run for half a day can easily hit that number.

Once the sandbox stops, the only options are to recreate it or apply a patch. That conflicts directly with long-running uses, such as leaving an agent to work overnight or keeping one running as a monitor. However strong the isolation is, a sandbox that stops after just over two hours can't be used for always-on work. It also suggests that without Agent Observability, meaning systems that log and monitor what agents do, including how many commands they run, operators may notice the problem late.

Stronger protection broke browsers and Make

Other reports show the strict protection backfiring. One is Issue #4098, filed by SidShaytay.

The reporter used Fedora 44 Silverblue with two setups: rootless Podman, which runs containers without administrator privileges, and a microVM, a very lightweight virtual machine. In both, they started an Ubuntu 24.04 guest (the OS running inside the sandbox) in a v0.1.2 sandbox and installed Playwright CLI 0.1.22 and Chromium revision 1247. Chromium failed to launch because it could not create its own small sandbox. The cause is that OpenShell's seccomp filter, which restricts the system calls a process may use, denies CLONE_NEWUSER, the call that creates a new user namespace. Running unshare -Ur returns "Operation not permitted."

Browsers have their own built-in sandboxing, so in effect the browser tried to build a box inside the box, and the outer box stopped it. The reporter did not ask for the protection to be removed. Instead, they asked for a way to run Chromium with the protection still in place and for a regression test to make sure the problem does not return.

Several similar reports were filed on Oct. 2:

• #4102: GNU Make, which doesn't change UIDs/GIDs (user and group IDs), can't start its recipes (build steps)
• #4097: child processes can't add their own seccomp filters
• #4129: a restarted sandbox's status goes back from Ready to Error

On Oct. 3, timeouts in Kubernetes end-to-end tests and in unit tests were also reported. In the issue list we were able to retrieve, about 10 of the 15 new issues opened from Oct. 2 to Oct. 3 were bug reports, including at least eight on Oct. 2 alone. Browser automation and builds are among the jobs people most want to hand to agents, so having both blocked at once is a real setback.

Stars don't prove it runs safely. If you try it, go in this order

None of this means OpenShell is a failure. These bugs were found by people who started using it this week and tried to move their real work into the sandbox. Stars alone would never have surfaced these reports. Attention and working software are different things, and this week the numbers showed the gap between them.

Some context. According to the repository, the latest release is still in the 0.1 series, v0.1.2 (released Sept. 28). It states clearly that Windows support is experimental and runs on WSL 2. There are 349 open issues. This is young software, and users should treat it that way.

Still, the isolation approach looks sound. Risks of agents being tricked, such as Tool Poisoning (hiding malicious instructions in a tool's description) and Rug Pulls (a tool provider changing the tool's behavior after the fact), aren't going away. That is exactly why a box that contains the damage when an agent is fooled is needed. The reporter of #4098 asking that the protection stay in place likely reflects that same view of its value.

For anyone trying it now, here is a suggested order:

• Start with short tasks: following the official guide, run Claude Code in the sandbox with openshell sandbox create -- claude and give it a task that takes about 30 minutes
• Hold off on long-running uses: until #4103 is fixed, either recreate the sandbox before it reaches 4,096 executions or don't use it for always-on production work
• Check before adding browsers and builds: watch the progress of #4098 and #4102 before moving Playwright/Chromium work or Make builds into it

The attention on "boxes for running agents" shows how many people now want to hand agents real work. We'll keep watching the issues to see how the next release deals with these three bugs.