ModelRefs / Sandboxed Code Execution — Tool Pattern
Sandboxed Code Execution — Tool Pattern
Execute model-generated code inside an isolated, resource-capped sandbox and return stdout, stderr, and artifacts.
Overview
Expose 'run_code(language, source)' as a tool backed by a sandboxed runtime (container, Pyodide, microVM). Capture stdout, stderr, exit code, and produced files; return them as structured tool results.
When to use it: You need the model to compute, analyze data, or transform files via real code rather than text emulation.
Pattern details
| Pattern class | code-execution |
|---|---|
| Difficulty | advanced |
| Invocation mode | synchronous |
| Also known as | code interpreter, python tool |
| Last reviewed | 2026-06-07 |
Known failure modes
- Infinite loop — Generated code runs without bound. Mitigation: Enforce wall-clock timeout and kill on breach.
- Data exfiltration — Code attempts to call out to the network. Mitigation: Disable network egress at the sandbox layer.
- Out of memory — Code allocates beyond limits. Mitigation: Cap memory; return clear OOM signal.
When not to use it
- Running model-generated code in the same process as the application.
- Granting the sandbox arbitrary network or filesystem access.
Continue your research
Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Sandboxed Code Execution — Tool Pattern.
Frequently asked questions
When should I use the Sandboxed Code Execution tool pattern?
You need the model to compute, analyze data, or transform files via real code rather than text emulation.
What are common failure modes of Sandboxed Code Execution?
Infinite loop • Data exfiltration • Out of memory
Is Sandboxed Code Execution production-ready?
Yes when paired with the safety controls and observability hooks documented on the pattern page.