Sandbox Compatibility With LangChain and LlamaIndex Agents

Sandbox compatibility with LangChain and LlamaIndex is not a plug-in checklist. It is a question of where, exactly, an orchestration framework hands off code execution to an isolated environment, and whether that handoff holds up when the agent's state and the sandbox's state stop agreeing with each other.

How the two-layer agent stack creates an execution boundary problem

Production agent systems in 2026 run on a two-layer stack. One layer plans, tracks state, and decides which tool to call next. The other layer, a purpose-built sandbox, actually runs the code that layer produces. That split did not happen by accident, and understanding why it exists matters before getting into the mechanics of wiring it up.

LangChain itself illustrates the layering. The project has split into langchain-core, the main langchain package, langchain-community for integrations, and LangGraph for agent orchestration, with LangGraph now serving as the primary way to build agents according to LangChain's own framework guide. LlamaIndex took a parallel path with Workflows 1.0, shipped June 30, 2025, an event-driven, async-first, step-based system for orchestrating agentic behavior in Python and TypeScript. Neither framework tries to be the thing that runs the code. Plenty of production systems, in fact, use both at once: LlamaIndex handling ingestion and retrieval, LangChain handling the orchestration on top.

Why keep execution somewhere else entirely? Agents generate code, run shell commands, and touch filesystems in ways that cannot be fully predicted ahead of time, so the orchestration layer, which is built for planning and tool routing, has no safe way to also be the thing that contains that execution. That's the boundary this piece is about: not a config flag, but a real architectural seam between what an agent decides to do and where it's actually allowed to do it. Every section that follows is really just asking the same question from a different angle: how does each framework expose that seam, and what happens when the sandbox on the other side doesn't behave the way the framework assumes it will?

Why the execution boundary must be enforced by isolation, not trust

The uncomfortable part is this. An agent's code cannot be predicted in advance, not fully. It's a hope. Shell commands, file access, and network calls can appear in ways no one scripted for, so isolation has to do the work that trust cannot.

This isn't hypothetical. PromptArmor disclosed a vulnerability in Snowflake's Cortex Code CLI in early 2026, with coordinated public disclosure on March 16, 2026, and a fix that had already shipped in version 1.0.25 on February 28, 2026. That timeline matters: the fix predated the disclosure by more than two weeks, which is roughly how responsible disclosure is supposed to work, but it also confirms the vulnerability was real and reached a shipping product used by developers who assumed their execution environment was closed off.

The trend line underneath all this is produced by rapidly improving model performance, and it is not flattering to anyone who calibrated a sandbox two years ago. Frontier models' success rate on apprentice-level cybersecurity tasks sat under ten percent in late 2023 and early 2024. By 2025 it was near half, and the first expert-level task completion happened that same year. A sandbox designed around what models could do in 2024 is being asked to hold back models that have gotten meaningfully better at exactly the kind of task a sandbox exists to contain. That's the argument for purpose-built execution environments over repurposed developer tooling or generic containers: the tooling has to be built for this job specifically, not adapted from something that was built for a calmer one.

LangChain's own Deep Agents documentation frames isolation as necessary "so they can't access credentials, files, or the network". That phrasing does not describe the sandbox as a nice-to-have or a performance optimization. It doesn't describe the sandbox as a nice-to-have or a performance optimization. It describes it as the thing standing between an agent and the credentials on the host machine.

How LangChain and LangGraph expose execution boundaries to sandboxes

LangChain and LangGraph give developers two genuinely different ways to wire in a sandbox, and picking the wrong one for the job is a common source of friction.

The first is sandbox as tool. Here the sandbox call gets wrapped as something the agent can choose to invoke mid-reasoning, the same way it might choose a search tool or a calculator. LLM Sandbox's documentation shows this pattern cleanly: decorate a function with @tool, open a SandboxSession inside that function, call session.run(code), and register the whole thing in the agent's tool list. A more production-ready version of this swaps the plain function for a StructuredTool with a Pydantic input schema, so the agent can pass along the language and an optional list of libraries alongside the code itself. That schema step sounds minor, but an agent with a defined contract for what it's allowed to send behaves differently from one that occasionally passes malformed input.

The second pattern is sandbox as backend, and it's a different shape of thing entirely. Deep Agents, LangChain's harness for long-running agent workflows, exposes a backend abstraction where the sandbox isn't one tool among several, it's the whole environment the agent lives inside. Configure a sandbox backend and the agent automatically gets the standard filesystem tools, ls, read_file, write_file, edit_file, glob, grep, plus an execute tool for arbitrary shell commands, according to LangChain's Deep Agents sandbox documentation published September 23, 2026.

The LangGraph create_react_agent signature has changed. Anyone copying code snippets from older blog posts should check the version-pinned examples rather than trusting anything that predates the 1.0 split.

LangGraph's state model shapes how sandbox state has to be managed whether or not a developer thinks about it explicitly, and it produces both patterns. Each LangGraph node takes in the current state and returns updates to it, and compiling the graph with a checkpointer saves that state at step boundaries, which is what makes resumable execution and fault recovery possible. But sandbox state and graph state are not the same thing, and treating them as if they were is where things quietly break. A sandbox that resets itself between tool calls has no idea that the LangGraph checkpoint sitting one layer up assumes everything is continuous. That mismatch gets its own full treatment later in this piece, because it turns out to be the most common way these integrations fail in practice.

LangGraph agents using langchain-mcp-adapters can reach any MCP-capable sandbox provider over the standard MCP protocol, with no custom integration code required. That's a meaningfully different proposition from either tool-wrapping or backend-configuring, since it sidesteps provider-specific SDKs altogether. Deep Agents Code has built-in sandbox support via the --sandbox flag, with dedicated flags --sandbox-id and --sandbox-setup.

How LlamaIndex Workflows exposes execution boundaries to sandboxes

LlamaIndex Workflows reaches sandboxes mostly through tool wrapping at the step or agent level, but the framework's event-driven, ephemeral-by-default design sets up a different kind of statefulness problem than LangGraph's explicit checkpointing does.

The mechanics are straightforward enough. Sandbox calls get wrapped as FunctionTool objects, typically via FunctionTool.from_defaults(fn=...), and handed to a FunctionAgent or dropped into a workflow step. For simple tool-use flows, that's plenty. Developer comparisons from August 2026 generally agree that FunctionAgent handles straightforward cases fine, while LangGraph is the better fit once an agent needs conditional branching, cycles, or genuinely complex state. LLM Sandbox's own LlamaIndex documentation predates the FunctionAgent workflow API, so anyone building against it should pull from the version-pinned examples rather than the older snippets.

Each framework thinks about state differently. Workflows carry data on events, and whatever needs to persist across a run gets stored in a shared Context object, which is a considerably lighter model than LangGraph's explicit graph checkpointer. Workflows are ephemeral by default. A process can serialize that Context and pick it back up later to continue a run, but nothing about that is automatic, someone has to do it deliberately. For teams that need automatic recovery rather than manual serialization, LlamaIndex Workflows supports runtime plugins, including a DBOS integration, though that's a bolt-on rather than a built-in default.

What kind of code a LlamaIndex sandbox is usually running in the first place shapes which sandbox features actually matter. LlamaIndex's strength is document-heavy, RAG-grounded pipelines, and in that context the sandbox is more often loading files, running analysis libraries, and generating outputs than generating arbitrary general-purpose code. That's a narrower job than what a Deep Agents backend is often asked to do, so raw shell access is less important than reliable, repeatable data processing.

Given how often teams pair LlamaIndex for retrieval with LangChain for orchestration, sandbox integration in a real production system frequently isn't a single-framework decision at all. It can mean wiring a sandbox into both layers of the same application, which raises the state-alignment issue twice rather than once.

Resolving the statefulness mismatch between frameworks and sandboxes

This is where things go wrong in production, more often than any security misconfiguration. The root cause is almost embarrassingly simple once it's named: each Sandbox() context manager creates a fresh, fully isolated environment, and everything in it, files, variables, installed packages, disappears the moment that context closes. That happens regardless of the agent's own state, a LangGraph checkpoint or a LlamaIndex Context, sitting there perfectly intact one layer up. The agent remembers what it was doing. The environment it's executing in does not.

What does that actually look like in practice? An agent installs a package in step one, then in step two the tool call opens a brand-new Sandbox() instance, and the package is gone, so the agent has to reinstall it, or worse, fails silently and the developer spends an afternoon debugging something that was never a logic error to begin with.

Three fixes address this, and they're not mutually exclusive. The first is sandbox pooling: instead of spinning up a new sandbox per call, keep a persistent pool warm in production where call volume is high, which cuts startup overhead and keeps the environment's state intact across invocations. The second is snapshotting, capturing both filesystem and memory state of a running sandbox so an agent can start from an already-prepared environment, packages installed, configuration set, dependencies resolved, rather than rebuilding from nothing every single run. The third is more code-level: build explicit session management into a custom memory object, the way LLM Sandbox's CodeExecutionMemory class holds one persistent SandboxSession open across multiple execute() calls. That third option is the right fit for LangChain agents specifically built for continuity rather than one-shot execution.

None of these fixes happen automatically just because the orchestration framework has its own state story sorted out. LlamaIndex's manual Context serialization has the identical problem in a different outfit: restoring a workflow from a serialized Context restores the workflow's own memory, not the sandbox's, unless the sandbox was snapshotted separately.

The fact that this is now an active research problem, not just a workaround developers reach for on their own, says something about how widespread it's become. That kind of engineering effort doesn't get invested unless the underlying mismatch is costing real time and real money at scale. LangGraph's checkpointer and sandbox persistence operate at different layers and must be aligned deliberately, as a LangGraph checkpoint does not keep a sandbox alive. An active research direction confirms the scale of this problem: the 2026 arXiv preprint DeltaBox: Scaling Stateful AI Agents with Millisecond-Level Sandbox Checkpoint/Rollback addresses checkpoint and rollback at scale, while Tencent Cloud's CubeSandbox v0.3.0, released June 2026, uses a Copy-on-Write snapshot engine for hundred-millisecond snapshot, clone, and rollback of AI Agent sandboxes.

Which sandbox providers integrate with LangChain and LlamaIndex, and on what terms

A handful of purpose-built sandbox platforms document direct integration with LangChain, LangGraph, and LlamaIndex, though they don't compete on identical terms, integration depth, statefulness support, and compliance posture all vary.

For teams already living in the LangChain ecosystem, that's about as low-friction as the setup gets.

Blaxel holds SOC 2 Type II, ISO 27001, and HIPAA support, and is listed in the OpenAI Agents SDK's roster of seven supported providers.

And then there's the protocol-level path that sidesteps providers entirely. MCP is natively supported by seven of the ten major agent frameworks as of an August 2026 count from Alice Labs, and LangGraph agents using langchain-mcp-adapters can connect to any MCP-capable sandbox without writing custom integration code. That's less a vendor decision than an infrastructure decision, choosing a protocol over a proprietary SDK, and it's worth weighing against the first-party and dedicated-provider options on their own merits rather than assuming one approach is obviously correct for every team. Northflank counts Writer, Sentry, and cto.new among its production customers, and is HIPAA compliant, supports BAAs under Enterprise contracts, and is SOC 2 Type 2 certified.

Isolation technology under the hood: what container tools, lightweight virtual machines, and sandboxing runtimes mean for agent workloads

The integration patterns above depend on the isolation beneath them; if that isolation is thin, the patterns don't matter much. Containers, microVMs, and kernel-level sandboxing techniques like gVisor represent genuinely different tradeoffs between startup speed and the strength of the isolation boundary, and which one sits underneath a given sandbox provider shapes what that provider can credibly promise an agent developer. A standard container shares a kernel with its host, which is fast to spin up but leaves a thinner wall between agent code and the underlying system. A microVM adds a real hypervisor boundary, closer to a full virtual machine's isolation, at some cost in startup latency. Kernel-level interception approaches intercept system calls before they reach the host kernel at all, trading some performance for a narrower attack surface. None of these approaches is universally correct. What matters for an agent workload specifically is that the isolation choice is deliberate, matched to what the agent is actually allowed to touch, rather than inherited from developer tooling that was never built with an autonomous, occasionally unpredictable caller in mind.