Smolbox
Smolbox is a proof-of-concept agentic coding environment that runs entirely in a browser tab: an x86_64 Alpine Linux VM under WebAssembly, an LLM running via WebGPU exposed to the VM as tool calls, and an optional read-only folder mount through the browser file picker — "very similar to Claude Code or Codex, except that there's no server side processing." Its author (remyhax) frames it not as a product but as an argument: agentic AI was always possible to run privately on locked-down hardware, and the security industry's instinct to gate it behind servers, subscriptions, and guardrails is "a disservice" to the next generation of users who will simply take riskier paths instead.
Key Quotes
"The combined result being very similar to that of Claude Code or Codex, except that there's no server side processing. The linux VM sandbox, LLM, tool calls, and file access controls only exist in the user's browser tab."
The technical thesis in one sentence. The entire agent stack — sandbox, model, tool calls, filesystem — collapses into a single client-side artifact with no server to trust, no credentials to leak, and no data to collect. It is the endpoint of the "boundary moves below the model" logic in Security and Sandboxing taken to its extreme: not an OS sandbox around a cloud agent, but a whole agent that never leaves the browser.
"I knew exactly what I wanted, how to do it, what to use, and how to validate success. AI put all the pieces together for smolbox exactly as I asked with zero ambiguity."
An unusually honest attribution. The author claims no credit for the artifact — the specification was the human contribution, the assembly was the model's. This is Specifications as the Product in its purest anecdotal form: a person with a clear, validated goal and a cheap agent produced a working system with "zero ambiguity." It is also a counter to the claim that AI can only assemble when a senior engineer is steering.
"All they did was make something possible."
The emotional core. The author's teenage origin story — reverse-engineering a Verizon MMS↔email bridge to browse the web over unlimited texts, then exploiting a ringtone path-traversal to replace the phone's World Clock app with mini-golf — is a parable about a random developer's small, slow, badly-formatted service opening a career. Smolbox is the author deliberately occupying that role for the next teenager.
"But it makes things possible for a large population of people to do safely, and it's easy for a random developer to do."
The synthesis of the technical and the moral argument. "Safely" is doing the heavy lifting: a WASM VM sandbox and a WebGPU model need no special permissions, work on school iPads and library computers, and can't cause real-world damage. The alternative path the author sketches — hacked account tokens bought through "fly-by-night vendors on some random Telegram messaging channel" — is what kids reach for when no safe path exists.
Key Themes
Sandbox-as-browser-tab. The isolation mechanism is a WebAssembly VM running a full Linux userspace, not a cloud microVM (Firecracker/gVisor) or an OS sandbox (Seatbelt/Landlock/seccomp). There is no server to provision, no credentials to scope, no egress to filter — the "blast radius" is bounded by construction because there is nothing outside the tab that the agent can reach. This is a genuinely different point on the isolation spectrum than Best Infrastructure Platforms for Coding Agents in 2026's seven platforms, all of which assume a server. Wanix — Wasm-Native Unix Sandboxing for the Web is the same point reached as a library rather than a proof-of-concept: a browser-native Unix assembled from custom HTML elements, running both Wasm and x86 (via v86), with Plan 9 per-process namespaces where Smolbox uses a single compiled VM.
Local inference as privacy. The LLM runs through WebGPU in the browser, the same substrate Gemma Gem uses. Smolbox goes one step further: instead of a browser-embedded model answering questions about the page, it is a browser-embedded model driving tool calls inside a VM. The privacy claim is total because "not collecting any data whatsoever" is a property of the architecture, not a policy promise.
Security as enablement, not lockdown. The author's actual grievance is that "the state of AI security" spends its energy making agentic AI less accessible — paywalls, subscription gatekeeping, guardrails that must be evaded — rather than giving people a safe sandbox to play in. This inverts the usual framing in Security and Sandboxing, which is about constraining agents that already exist; Smolbox's question is whether the field is building the safe on-ramp for the next generation at all.
"Makes it possible" as the unit of value. The post is less a technical release than a reminder that a tool doesn't need to be fast or polished to change someone's trajectory — it needs to remove the obstacle. It reads as a companion to the accessibility thread in Local and Open Source Inference ("AI is too critical to be just a provided service") but grounded in a lived origin story rather than a sovereignty argument.
Critical Analysis
The strongest part of this post is its argument, not its artifact, and the author is refreshingly upfront about that. Smolbox is "slow," "kludgy at times," and "not particularly great at anything other than being private." The honest self-assessment is what makes the piece land: it is not claiming to be a better Claude Code, only a proof that the server-side assumption was never load-bearing.
The privacy claim deserves scrutiny. "No server side processing" is true for the model and the sandbox, but a WASM VM still needs a host to serve the bytes and a browser to run them; "not collecting any data whatsoever" is a property of this deployment, easily undermined if someone forks it behind analytics or a CDN. The architecture is private by construction; the distribution channel is not guaranteed to be. This is the same caveat that applies to any client-side tool — the code is local, but getting the code can still be observed.
The accessibility argument is the most debatable part. The author assumes the binding constraint on a teenager using agentic AI is install and subscription — a WASM tab solves both. But the deeper constraint may be the model itself: a WebGPU-bound LLM is small and slow, and the "AI put it together with zero ambiguity" experience the author enjoyed is not reproducible on a small local model. Smolbox makes agentic AI runnable on a locked-down iPad; it does not necessarily make it capable. The author's own framing — "it's possible; what remains is a question of who is both capable and willing" — quietly concedes this.
What makes the piece worth keeping in this wiki is that it sits at the intersection of three threads that are usually separate: the sandboxing conversation (A Deep Dive on Agent Sandboxes), the local-inference conversation (Local and Open Source Inference), and the accessibility/education conversation (Building When It Feels Like There's Nothing Left to Build). Smolbox is the only source here that argues from who is being left out rather than what the agent can do.
Sources: raw/smolbox, Agentic AI in a Smolbox Last updated: 2026-08-21