The E2B Bug Fix That Explains Why Your Agent Hangs on the Second Run

The specific failure E2B describes is narrow and precise. The SDK caches the connection it uses to talk to its remote sandboxes, and it was indexing that cache by a numeric loop identifier. The runtime can reuse that identifier almost immediately after a loop is closed, so a sequence of separate runs could pick up a connection that belonged to a previous, already-dead session. The E2B release notes describe keying the cache by the loop object itself, held weakly, with entries released automatically when the loop is collected.

Notice the shape of the problem. It does not appear on the first run. It appears on the second, the third, the hundredth, whenever the same process spins up a fresh execution context after tearing down the last one. That is precisely the access pattern of an agent doing repeated, discrete tasks: handle a request, finish, reset, handle the next one.

A tool used once would never surface this. A tool used continuously, in a loop, by something that does not get tired, surfaces it constantly. The bug is a fingerprint of how agents actually behave in production. They are not interactive sessions a human babysits. They are long-lived processes that do the same setup-and-teardown dance thousands of times, and any defect that compounds across repetitions becomes their defining failure mode.

It helps to be clear about what E2B sells. It runs the disposable, isolated environments where an agent's code actually executes: the sandbox that catches the blast radius when a model decides to run something it shouldn't. That is not the model. It is the thing standing between the model and the rest of the world.

This maps cleanly onto what we have called the Harness Hypothesis: the value in AI is not in the model, it is in the harness that connects the model to the world. A frontier model that can write flawless code is worthless to an operator if the code has nowhere safe to run, no reliable way to be invoked twice in a row, and no guarantee that the second invocation behaves like the first.

The sandbox layer is the harness made literal. And the fact that a sandbox vendor's most consequential recent change is a reliability fix, not a capability addition, tells you where this part of the stack sits on its evolution curve. On a Wardley map, the model layer is still thrashing around in genesis and custom-build. The execution-environment layer is visibly sliding toward product and commodity, where the competitive question stops being "can it do this?" and becomes "does it do this every single time?"

That shift is what reliability fixes signal. You do not spend engineering effort hardening connection caches for a component nobody depends on. You harden it because customers have moved past evaluating it and started trusting it, which means they have also started getting burned by it. The bug report is a backhanded compliment: people are running this in anger, at volume, and the failure modes that only show up at volume have started to bite.

The same release adds something else worth examining: the SDK now retries connection establishment to E2B's API and its sandbox clients three times by default, configurable through an environment variable. The release notes frame this as a straightforward robustness improvement.

Read it less charitably and it is more interesting. You add automatic retries when you have accepted that connections will fail. Not might fail, will fail, often enough that surfacing every failure to the caller produces an unacceptable experience. The retry is a layer of defense built on the assumption that the layer beneath it is unreliable.

This is the Swiss Cheese Model arriving in agent infrastructure: accidents happen when the holes in multiple defense layers line up, so you stack layers. A transient network hiccup that would have killed a run now gets absorbed by retry logic. Combined with the cache fix that stops runs from inheriting dead connections, you can see two independent holes being patched in the same release. Neither alone was catastrophic. Aligned, they produced exactly the kind of intermittent, unreproducible failure that erodes an operator's trust faster than any outage.

For the person running agents rather than building them, the practical takeaway is uncomfortable: the reliability you experience is the sum of many small defenses you cannot see, layered by a vendor who knows the underlying network is hostile. When one of those layers is missing, you do not get a clear error. You get a flaky agent, and flakiness is harder to diagnose and harder to forgive than an honest failure.

E2B did not patch in isolation. Look at what else landed on June 15 across the agent-tooling stack and a pattern appears.

Google's agent development kit shipped a release whose notes are entirely bug fixes, including ensuring a streaming response always yields its final frame so a consumer is never left waiting on output that never arrives, per the ADK 1.35.1 notes. The agent framework Agno shipped a release migrating its web-search backend to a newly stable API and pinning the version floor, described in the Agno v2.6.16 changelog. The observability platform Langfuse shipped a release that, among other changes, blocks a legacy export path for new cloud users, documented in the Langfuse v3.186.0 notes.

None of these is a capability story. Every one is about making an existing behavior dependable, predictable, or correct. A streaming response that always closes properly. A search backend pinned to a stable contract. An export path locked down. A connection cache that does not poison the next run.

The pattern, and this is analysis rather than coordination, resembles a category-wide molt. Open-source agent infrastructure tends to move through predictable phases: rapid growth, then a hardening phase where the project's energy shifts from adding surface area to defending the surface it already has. A single such release proves nothing. Four of them, across sandboxing, frameworks, and observability, on the same day, suggests the layer beneath the models has collectively entered its hardening phase. The growth happened. Now comes the unglamorous work of making it not break.

The reader who configures an agent rather than building one might reasonably ask why a connection-cache fix in a sandbox SDK deserves their attention. The answer is that this is the layer that determines whether your setup is trustworthy, and you have almost no visibility into it.

When you wire an agent into a workflow, you are stacking dependencies you will never inspect. Your orchestration tool calls a framework, which calls a sandbox SDK, which opens a network connection to a remote execution environment. A defect three layers down, like a recycled connection identifier, manifests at your layer as an agent that worked in testing and fails intermittently in production. You will blame your prompt. You will blame the model. You will rarely suspect the plumbing, because the plumbing is invisible until it leaks.

This is the operational cost of the Autonomy Spectrum. The more autonomous your deployment, the less a human is watching each run, and the more these compounding, low-level reliability defects matter. A copilot failure gets caught by the person sitting in front of it. A fully autonomous failure runs silently until something downstream breaks, and by then the cause is buried under thousands of successful runs.

The practical move for an operator is not to read SDK changelogs. It is to treat reliability as a procurement criterion, not an afterthought. When you evaluate agent infrastructure, the question "how often does this fail, and how loudly?" deserves more weight than "how capable is the underlying model?" The model is increasingly a commodity you can swap. The harness, the part that decides whether autonomy is actually safe to leave unattended, is where your real risk lives.

Step back and the strategic picture clarifies. Aggregation Theory says platforms win by aggregating demand and then commoditizing supply. In the agent stack, the models are rapidly becoming the commoditized supply, interchangeable, swappable, racing each other to the floor on price. The layer that aggregates the user relationship, the harness that the operator actually depends on day to day, is where durable advantage accumulates.

E2B's release is a small data point in that larger movement. A vendor at the execution layer is investing in reliability because reliability is what its customers will eventually pay a premium for, and what they will switch away from a competitor to get. Capability gets you evaluated. Reliability gets you deployed and kept. The vendor that owns the dependable harness owns the relationship, regardless of which model is bolted on top this quarter.

There is a trade-off lurking here too, the Capability versus Controllability frontier. More capable models are harder to contain, which puts more pressure on the sandbox to be both permissive enough to be useful and reliable enough to be trusted. Every connection retry and every cache fix is the harness layer absorbing the consequences of the model layer getting more powerful. The smarter the thing inside the box, the more the box itself has to be bulletproof.

None of this is visible in a benchmark. It is visible in a changelog, in the slow accumulation of fixes that no marketing team will ever feature, on a release that most readers would skip. Which is the point. The interesting story in agent infrastructure right now is not the next model announcement. It is the quiet, coordinated turn toward making the existing stack dependable, because dependability is the moat the model layer can no longer provide.