Skip to content

Build1 publisher3 min readPublished

Foundry's Code Interpreter forgets your dataframe unless you pin the container ID

A dev.to walkthrough of Microsoft Foundry's Agent Service pulls the tool declaration apart from the lazily provisioned container and the hour-long billable session. Which of the three you hold a reference to decides whether the second question still has the data.

The Engineer · Build desk

Illustration accompanying Foundry's Code Interpreter forgets your dataframe unless you pin the container ID

What happened

  • A dev.to walkthrough of Microsoft Foundry's Agent Service separates three things developers conflate: the Code Interpreter tool definition, the sandbox container, and the session.
  • Two concurrent conversations calling the tool get two separate container sessions, with no shared state and no shared filesystem between them.
  • Developers who do not hold a container reference get a fresh, empty sandbox on every call, and the agent appears to forget data it analysed moments before.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • decision The container ID becomes application state. Whoever writes the agent has to decide where it is stored and which turns are allowed to share it.
  • cost Billing follows concurrency. A burst of simultaneous users is a burst of container sessions even when each one runs a second of Python.
  • constraint The idle timeout sets the outer limit on how long a user can wander off mid-analysis, so long-running work needs either keepalive execution or a re-upload path.
  • capability Exact arithmetic and large-CSV filtering become a container's job instead of the model's, bought with a lifecycle someone now has to operate.

Amnesia here has a specific cause. The thing you attach to the agent definition is `CodeInterpreterTool` in the Python SDK, or `CodeInterpreterToolboxTool` when it goes through a toolbox, and the post is blunt that this only declares a capability [3]. A container arrives later, provisioned lazily on first use, bound either to an explicit ID you manage or to an automatically managed lifecycle tied to the conversation [4]. Keep no ID and you take the automatic path, which the post says quietly returns a fresh, empty sandbox on every call [7]. An agent that cannot remember a dataframe it loaded 40 seconds ago is on its second container.

The session is the billable, time-bounded life of that container: up to one hour by default, with a 30-minute idle timeout that tears it down early [5]. The two numbers interact. Sixty minutes of ceiling divided by a 30-minute idle window leaves two windows, so the hour is only reachable if something executes in each of them [15]. A user who comes back with "now compute the median" 35 minutes later is addressing a container that no longer exists, along with every intermediate file it wrote [5][7].

Isolation is per conversation. Two concurrent conversations calling the tool get two container sessions, with no shared state and no shared filesystem [6]. Any state that two conversations both need has to live somewhere other than the sandbox.

Files move through a staging path outside the model's context. The post describes the lifecycle as upload, execute, citation, download, with file staging through Azure Storage and citations returned as annotations [8]. It also flags that prompt agents and hosted agents built on the Microsoft Agent Framework take divergent paths through the runtime [9]. That split is where container-handling code would have to change to port from one to the other.

The payoff for accepting all this machinery is deterministic execution. According to the post, LLMs are terrible at arithmetic and at exact string manipulation over large datasets, and GPT-5-class models asked to reason out the factorial of 100 in tokens return plausible-looking wrong answers more often than you would like [11]. What the sandbox gets is a real Python runtime with no network access to your infrastructure and no persistent state across unrelated conversations [10]. OpenAI shipped the same pattern as Code Interpreter for ChatGPT, and it appears as the local sandbox tool in Anthropic's Claude and in Gemini [12].

Provenance matters for the two numbers people will plan against. This is one developer's write-up, day 8 of a 100-day Foundry series on dev.to, not Microsoft's own documentation [1]. The copy available here stops mid-sentence in the request-flow section, ahead of the sections it advertises on security, session economics and cost [14][13]. Before anyone sizes a session budget on a one-hour default and a 30-minute idle timeout, those defaults should be read out of the service docs [5].

What to watch

  • Whether Microsoft's service documentation confirms the one-hour session default and the 30-minute idle timeout, and whether either is configurable.
  • The unpublished remainder of the post's request-flow, session economics and cost sections, which would put a price on a container hour.
  • Whether hosted agents on the Microsoft Agent Framework expose the container reference the same way prompt agents do.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories