06-reference

technically code sandboxes

2026-06-18·reference·source: Technically·by Justin Gage

"What are code sandboxes?" — Technically

Why this is in the vault

Sandboxes are the missing infrastructure layer between RDCO's Claude Code sub-agent architecture and safe autonomous code execution — understanding the space matters as we build toward L5 agent capability.

The core argument

Justin Gage's framing: a sandbox is isolated computing environment for untrusted code — "solitary confinement, but for a program." The prison analogy runs throughout: your production infrastructure is the general population; any code you haven't examined line-by-line is an unknown inmate who might start a riot.

Three classes of "untrusted code" driving current demand:

  1. Internal coding agents — LLM-generated code (e.g. Claude Code sub-agent output) that needs a safe run environment before merging into a real codebase
  2. RL training — agents generating and executing code during training; by design they try destructive actions ("that's how RL works")
  3. User-submitted code — the original use case (Retool, etc.), now dwarfed by the agent demand

The piece notes sandboxes have existed for years (Gage's former employer Retool used them for user-code isolation) but LLMs triggered a "second wind for the ages" — now dozens of startups compete in the space.

Specific tools named: Retool (legacy reference). The article is paywalled past the intro; specific modern vendor names (E2B, Modal, Daytona, Firecracker, etc.) likely appear in the paid section. The free excerpt doesn't enumerate them.

The key risk illustrated: coding agents in the wild have "accidentally" deleted entire databases. Sandbox = blast-radius containment so a rogue agent action can't propagate beyond the isolated environment.

Mapping against Ray Data Co

Reinforces existing discipline — strong signal:

Gap this surfaces:

RDCO currently relies on Claude Code's built-in protections + worktree isolation for sub-agent work. We don't have a formal sandbox for executing code that sub-agents produce — e.g. if a sub-agent writes a Python migration script and runs it, that runs on the host. The RL training use case Gage describes is aspirational for RDCO (not current), but the internal coding-agent case is live today.

Specific question this raises: When we dispatch implementation sub-agents (per [[02-sops/2026-05-18-implementation-notes-pattern-for-sub-agent-dispatches]]), should the execution step happen inside an ephemeral sandbox rather than directly on the host machine? The Google Managed Agents note ([[2026-05-22-alphasignal-google-managed-agents-ai-studio-mobile-kaist-sam3]]) references "isolated, ephemeral Linux sandbox with bash terminal" as the default execution model — we should evaluate whether that pattern applies to our own sub-agent dispatches.

Does this change project direction? Not immediately — but it confirms that sandbox infrastructure is becoming table-stakes for serious agent deployments. Worth tracking the vendor landscape (E2B, Modal, etc.) as RDCO's autonomous coding work scales past the current single-founder scope.

Related