How to Save and Persist Code Interpreter Files Beyond the Session

Every code interpreter, whether it runs inside ChatGPT, the OpenAI API, or Microsoft Foundry agents, executes Python inside a sandboxed container. Files you upload get mounted into that container, typically at a path like /mnt/data. Files the interpreter generates (charts, CSVs, cleaned datasets) land in the same temporary directory.

The catch: that container is ephemeral. OpenAI's code interpreter sessions expire after roughly 60 minutes of inactivity, and Microsoft Foundry's sandbox has a one-hour active timeout with a 30-minute idle cutoff. Once the session ends, the container is destroyed. Your upload links stop working, generated files become unreachable, and download URLs return errors.

This is by design. Sandboxed execution needs to be disposable for security and resource management. But it creates a real problem when you need to keep outputs, share results with teammates, or chain code interpreter runs into a longer workflow.

Code interpreter sandboxes are short-lived for three reasons:

Security isolation. Each session runs in its own container (Hyper-V boundaries on Azure, Docker-style isolation on OpenAI). Destroying the container after use prevents data leakage between sessions and users.

Resource limits. Sandboxes consume compute and memory. OpenAI caps container memory at 1 GB by default. Keeping sessions alive indefinitely would be expensive and wasteful.

No persistent filesystem. The sandbox has no durable disk. Files exist only in the container's temporary storage. When the container stops, the filesystem goes with it.

For the OpenAI API, you can partially work around this by uploading files to the Files API first. The file remains in your account even after a session expires, and you can reference it by file_id in new sessions. But generated outputs still disappear unless you download them before the session ends.

Microsoft Foundry agents work differently. Files are uploaded to Azure storage and mounted into the sandbox via container references. Generated files get a container_file_citation annotation in the response, which gives you a container_id and file_id to download the output. But that download window is still tied to the session lifecycle.

Here is how the two approaches compare for persisting code interpreter outputs:

Built-in storage (OpenAI Files API, Azure containers)

• Files persist in your account between sessions
• You can re-mount uploaded files by file_id
• Generated outputs still require manual download before session ends
• No built-in sharing, versioning, or search across outputs
• Storage counts toward platform-specific limits (10 GB on OpenAI)

External workspace storage (S3, Google Drive, Fast.io)

• Files persist independently of any interpreter session
• Outputs can be pushed to storage programmatically during the session
• Built-in sharing, access controls, and collaboration features
• Search, versioning, and audit trails for compliance
• Storage limits depend on the platform, not the interpreter

The practical difference: built-in storage is tied to the interpreter platform. External storage decouples your files from the session entirely. If an interpreter session crashes or times out before you download a chart, that output is gone. With external storage, you push files out as they're created.

Give Your Agents Persistent File Storage

Stop losing code interpreter outputs to session timeouts. Fast.io gives every agent 50 GB of free workspace storage with built-in AI indexing, file versioning, and MCP access. No credit card required.

Sign Up Free

The general pattern works regardless of which interpreter you use: generate the file, then immediately push it to persistent storage before the session ends.

Option 1: Download and re-upload manually

After the interpreter generates a file, download it through the UI or API, then upload it to your storage platform of choice. This works but does not scale. If you are running batch analysis jobs or chaining multiple interpreter sessions, manual downloads become a bottleneck.

Option 2: Use the interpreter to push files via API

Most code interpreters can make HTTP requests (with some restrictions). You can write Python inside the interpreter that uploads generated files directly to an external API. For example, using the Fast.io MCP server or REST API, an agent can upload files to a persistent workspace during the session:

import requests

# After generating your output file
with open("/mnt/data/analysis_results.csv", "rb") as f:
    response = requests.post(
        "https://api.fast.io/blob",
        headers={"Authorization": "Bearer YOUR_API_KEY"},
        files={"file": f}
    )

Note that OpenAI's sandbox restricts outbound network access, so this approach works better with Microsoft Foundry's custom code interpreter or self-hosted interpreters like Open Interpreter. Check your platform's network policy before relying on this method.

Option 3: Post-session automation with MCP

If your interpreter runs inside an AI agent framework (Claude, GPT-4, or a custom agent), the agent itself can handle persistence. The agent runs code in the interpreter, retrieves the output, then uses an MCP server to store files in a workspace. This separates the compute step (interpreter) from the storage step (workspace), so a session timeout does not mean data loss.

For agents using the Fast.io MCP server, the workflow looks like this:

1. Agent sends code to the interpreter
2. Interpreter generates output files
3. Agent downloads the files from the interpreter session
4. Agent uploads files to a Fast.io workspace via the upload tool
5. Files are now persistent, versioned, searchable, and shareable

If you are building agent workflows that depend on code interpreter outputs, here is how to set up a durable storage layer.

Pick a storage backend

Local disk works for single-user development but breaks down with multiple agents or team access.

S3 or GCS gives you durability and scale but no built-in collaboration, search, or AI features.

Google Drive or Dropbox adds sharing but lacks agent-native APIs.

Fast.io is designed for this use case: agents and humans share the same workspaces, with built-in RAG, file versioning, and an MCP server that any LLM-based agent can use.

Structure your workspaces

Create separate workspaces for different projects or data pipelines. Inside each workspace, use folders to organize interpreter inputs, raw outputs, and processed results. This makes it easy to find outputs later and gives you a clear audit trail.

Enable Intelligence Mode

On Fast.io, enabling Intelligence Mode on a workspace automatically indexes every uploaded file for semantic search and AI chat. After your interpreter generates a report or dataset, uploading it to an intelligent workspace means you can immediately ask questions about the output, search across multiple runs, and get citations back to specific files and pages.

Handle concurrent agents

If multiple agents are running code interpreter sessions and writing to the same workspace, use file locks to prevent conflicts. Fast.io supports lock and unlock operations through the MCP server, so agents can coordinate writes without overwriting each other's work.

Here is what each major platform offers for code interpreter file storage as of April 2026:

OpenAI (ChatGPT and API)

• Session timeout: ~60 minutes of inactivity
• Container memory: 1 GB default
• Account storage: 10 GB cap (files from old chats count)
• File persistence: uploaded files persist via Files API; generated outputs do not
• Network access: restricted (no outbound HTTP from sandbox)
• Max upload size: 20 MB per file (larger files cause timeouts)

Microsoft Foundry Agents

• Session timeout: 1 hour active, 30 minutes idle
• Sandbox: Hyper-V isolated containers in Azure Container Apps
• File persistence: uploads stored in Azure; outputs accessible via container citations
• Network access: no outbound requests from sandbox
• Custom code interpreter: available for advanced use cases with configurable runtimes
• Updated April 2026 with SDK support for Python, C#, TypeScript, Java, and REST

Open Interpreter (self-hosted)

• No session timeout (runs locally)
• Full filesystem access on host machine
• No storage limits beyond disk space
• Full network access
• Trade-off: no sandbox isolation, so security depends on your setup

Fast.io (external workspace storage)

• Free agent plan: 50 GB storage, 5,000 credits/month, no credit card required
• No session concept: files persist indefinitely
• MCP server access via Streamable HTTP at /mcp
• Built-in versioning, search, audit trails, and AI indexing
• File locks for concurrent multi-agent access
• Ownership transfer lets agents build workspaces and hand them off to humans