Is srt the same thing as Claude Code's built-in Sandbox?
Per aiweekly, it is the execution layer behind Claude Code's sandbox, now open-sourced on its own. I could not compare against the README, so verify the claim of being identical yourself.
In practice, assume similar behavior but no guarantee of equivalence, and go by your test results.
Can I use a research preview in production?
A research preview usually means interfaces and configuration formats may change, and there may be gaps not yet known. It suits internal tools and testing, but before production, pin the version and prepare a fallback for when something breaks.
For customer data or compliance requirements, I would wait until its status is stable.
With a Sandbox, do I still need other protections?
Yes. A sandbox limits what a process can touch, but it cannot stop an agent from making a wrong decision within what is allowed, such as deleting files you let it reach.
So it should still be paired with least-privilege credentials, outbound network limits and human approval for irreversible actions.
How do I verify it really blocks things?
Actually run the operations you expect to be blocked: read a protected path, reach a domain that is not allowed, and repeat the same operation from a child process. Only if all three are blocked has it passed at first glance.
Rerun the same set after each version upgrade, because behavior may change during the research preview.
Anthropic has open-sourced under the Apache license Sandbox-runtime (command srt), the execution layer behind Claude Code's sandbox, so you can wrap your own agent or any command in the same restrictions. A caution first: the details here come from an aiweekly write-up, and I could not fetch the GitHub README itself, so below I separate what is secondhand from what I can confirm. Check the README before relying on any of it.
What I can confirm is the direction: this is the execution layer behind Claude Code's sandbox, now usable on its own and at the research preview stage. Its value is pulling the job of restricting what an agent can touch, in files and network, out of Claude Code so you do not rebuild it for every agent you write. For teams building agents with the Agent SDK or another framework, this is a piece they used to assemble themselves.
I did not check the following against the README or official documentation, so confirm each before going live: supported operating systems and the underlying isolation mechanism, the format and defaults of file system and network rules, whether child processes inherit the restrictions, where the configuration lives, whether DNS or non-HTTP traffic can be blocked, and whether the configuration format may change during the research preview. The Apache license is what the write-ups agree on, but read the repo's LICENSE before production use.
Start on an isolated test machine with no production credentials. Pick a command you know will misbehave, such as trying to read a sensitive file in the home directory or connect to a domain that is not allowed, and confirm it is blocked before putting a real agent inside. The point of testing is not whether it runs but what it stops: a restriction only counts within the range you have verified yourself. Also note what the error messages look like, because when an agent hits a blocked operation it reads that message and may try another route.
The biggest cost risk of a home-built agent is that it does something you did not expect while unattended, and a sandbox is cheap insurance. This project is free and its code can be inspected, so half a day of verification in a test environment is worthwhile. But until you have confirmed the details, do not treat it as a boundary that has passed security review: treat it as one layer among several, still paired with least-privilege credentials, outbound network limits and human approval. If your environment has compliance requirements, wait until the README and security model are clear before deploying.