Assistants API vs. Prompt Agents. How to access files generated by Code Interpreter tool in Prompt Agents? How to ensure file persistence of such generated files?

Question

Assistants API vs. Prompt Agents. How to access files generated by Code Interpreter tool in Prompt Agents? How to ensure file persistence of such generated files?

GenixPRO 206

Hi.

We're testing migration from Assistants API to Prompt Agents.
In our previous Azure OAI Assistants implementation, Code Interpreter generated files were returned as file IDs and we could retrieve them later via. the Assistants/Files API.
After migrating to Azure AI Foundry Agents / Responses API, generated files from Code Interpreter are returned as sandbox links {such as sandbox:/mnt/data/file.png}, with container_file_citation/container_id metadata. These files appear to live in a temporary container and expire quickly. Is this expected behavior for Foundry Agents Code Interpreter output?

3.1 In Assistants API, generated files resided permanently in Data files.

For a production chat app, what is the recommended way to persist generated files/images so users can view them later from chat history? Is there a supported option for durable file IDs/URLs, or should our backend immediately download the container file and upload it to our own persistent storage?
Note: We're testing 2 agents concurrently, and have attached memory to both respectively. However, no files are generated & saved in this memory. We've also attached vector store to each agent to process files for RAG etc.

Thnx.

Anshika Varshney 13,305 Reputation points Microsoft External Staff Moderator

2026-06-08T11:38:24.0866667+00:00
Hi @GenixPRO

What you’re seeing is expected behavior with the Azure AI Foundry Agents Code Interpreter tool.

The Code Interpreter tool runs inside a temporary sandbox container and stores generated files in paths such as:

sandbox:/mnt/data/...

These sandbox files are ephemeral and are automatically removed once the sandbox session expires (typically after a short retention period if the files are not retrieved). Unlike the Assistants API, Azure AI Foundry Agents currently do not provide a persistent file ID that can later be accessed through a Files API.

For production scenarios where users need to revisit generated images, CSVs, charts, or other files from chat history, the recommended approach is to persist the files externally.\

Recommended approach for file persistence

Detect when the agent response includes a sandbox file path

For example:

sandbox:/mnt/data/output.png

Immediately retrieve the file contents

- This can be done through: - your backend service - a follow-up tool execution - or another workflow that reads the generated file before the sandbox expires Upload the file to durable storage Examples: - Azure Blob Storage - Azure Files - CDN storage - your own application storage layer Store the returned file URL or identifier - Save the durable URL/file reference in your application database or chat history store. Surface the persistent URL back to users - This allows users to access the file later even after the Code Interpreter sandbox is destroyed.

At this time, there is no built-in setting in Azure AI Foundry Agents to automatically persist sandbox-generated files for long-term storage.

If durable retention is required, downloading and re-uploading the generated files to your own storage is the recommended pattern.

Difference from Assistants API

With the Assistants API:

Generated files can be associated with persistent file IDs

Files can later be retrieved using the Files API

With Azure AI Foundry Agents:

Sandbox files are temporary

No durable Files API access currently exists for sandbox-generated artifacts

References

Code Interpreter in Azure AI Foundry Agents

Code Interpreter file downloads in Azure OpenAI Assistants API

I hope this helps clarify the behavior and recommended architecture pattern. If needed, please share more details about your storage architecture or application flow, and the community can help suggest a more specific implementation approach.

Thank you!
Anshika Varshney 13,305 Reputation points Microsoft External Staff Moderator

2026-06-09T20:11:36.4033333+00:00

Hello @GenixPRO

Did you get any chance to review the response.

Thankyou!
GenixPRO 206 Reputation points

2026-06-10T09:36:46.88+00:00

@Anshika Varshney thanks for your response. What's the use-case for attaching memory to agents if it can't be used for persistent file store? we already attached vector DB for RAG. What's memory-attach good for?

Thnx.
Anshika Varshney 13,305 Reputation points Microsoft External Staff Moderator

2026-06-10T14:33:11.1566667+00:00
You’re correct that attached memory is not meant to act as a persistent file store, so its purpose is different from things like vector DBs or blob storage.

What “memory” is actually used for

Memory attached to agents is designed to store structured or contextual information about interactions, not files. Typical use cases include:

User preferences (tone, format, recurring instructions)

Session history or important conversation facts

Light-weight structured data (for example: user profile details, prior decisions, context flags)

This helps the agent behave more consistently across interactions without needing to re-fetch or re-explain context each time.

How it differs from vector DB (RAG)

You already mentioned you’re using a vector DB for RAG, which is great. The distinction is:

Vector DB (RAG): Used for retrieving external knowledge (documents, files, large datasets)

Memory: Used for storing context about the user/session, not external knowledge

Why memory is useful (even without file persistence)

Memory is valuable in scenarios like:

Multi-step workflows where the agent needs to remember earlier outputs

Personalization (for example: “this user prefers short summaries”)

Keeping track of decisions made earlier in a session

Passing lightweight state across turns without re-sending it in every prompt

Why it doesn’t store files

File outputs from tools like Code Interpreter are:

Typically ephemeral (session-bound)

Intended for immediate use/download

For persistence, you still need:

Blob storage

Databases

Or external storage + RAG integration

I Hope this helps. Do let me know if you have any further queries.

In case if you have any resolution, please do share that same with the community as it can be helpful to others.

Thankyou!
Anshika Varshney 13,305 Reputation points Microsoft External Staff Moderator

2026-06-11T14:27:14.4533333+00:00

Hi @GenixPRO

Just checking back to see if you’re still facing the same issue. If the problem persists, please share a few more details and we’ll be happy to help you further.

Thankyou!

1 answer

Your answer

Anshika Varshney 13,305 Reputation points Microsoft External Staff Moderator

2026-06-09T20:11:36.4033333+00:00

Hello @GenixPRO

Did you get any chance to review the response.

Thankyou!
GenixPRO 206 Reputation points

2026-06-10T09:36:46.88+00:00

@Anshika Varshney thanks for your response. What's the use-case for attaching memory to agents if it can't be used for persistent file store? we already attached vector DB for RAG. What's memory-attach good for?

Thnx.
Anshika Varshney 13,305 Reputation points Microsoft External Staff Moderator

2026-06-10T14:33:11.1566667+00:00

You’re correct that attached memory is not meant to act as a persistent file store, so its purpose is different from things like vector DBs or blob storage.

What “memory” is actually used for

Memory attached to agents is designed to store structured or contextual information about interactions, not files. Typical use cases include:

User preferences (tone, format, recurring instructions)

Session history or important conversation facts

Light-weight structured data (for example: user profile details, prior decisions, context flags)

This helps the agent behave more consistently across interactions without needing to re-fetch or re-explain context each time.

How it differs from vector DB (RAG)

You already mentioned you’re using a vector DB for RAG, which is great. The distinction is:

Vector DB (RAG): Used for retrieving external knowledge (documents, files, large datasets)

Memory: Used for storing context about the user/session, not external knowledge

Why memory is useful (even without file persistence)

Memory is valuable in scenarios like:

Multi-step workflows where the agent needs to remember earlier outputs

Personalization (for example: “this user prefers short summaries”)

Keeping track of decisions made earlier in a session

Passing lightweight state across turns without re-sending it in every prompt

Why it doesn’t store files

File outputs from tools like Code Interpreter are:

Typically ephemeral (session-bound)

Intended for immediate use/download

For persistence, you still need:

Blob storage

Databases

Or external storage + RAG integration

I Hope this helps. Do let me know if you have any further queries.

In case if you have any resolution, please do share that same with the community as it can be helpful to others.

Thankyou!
Anshika Varshney 13,305 Reputation points Microsoft External Staff Moderator

2026-06-11T14:27:14.4533333+00:00

Hi @GenixPRO

Just checking back to see if you’re still facing the same issue. If the problem persists, please share a few more details and we’ll be happy to help you further.

Thankyou!

Answer 1

For Foundry Prompt Agents and the Code Interpreter tool, the behavior being observed is expected and differs from the classic Assistants API.

Behavior difference vs. classic Assistants API

In classic Azure OpenAI Assistants, Code Interpreter output files are stored as durable “files” and exposed via file IDs that can be retrieved later through the Files API.
In Azure AI Foundry agents (Prompt Agents / Hosted Agents), Code Interpreter runs in a sandboxed container session. Files created there are container-scoped and exposed as sandbox paths (for example, sandbox:/mnt/data/...) plus container/file metadata. These are not automatically promoted to durable “data files” and are expected to be temporary.
The sandbox is a dynamic session with a limited lifetime and is isolated per session. Files in that sandbox are therefore ephemeral by design.

Relevant behaviors:

Code Interpreter runs in a Microsoft-managed sandbox using dynamic sessions in Azure Container Apps.
Each session is isolated and has a limited lifetime (idle timeout and max duration).
Files in the sandbox are accessible to the Python runtime and can be returned as downloadable outputs, but they are not guaranteed to persist beyond the session.

[Context: Code Interpreter tool for Microsoft Foundry agents – Sandboxed execution environment]

How to access files generated by Code Interpreter in Prompt Agents

For Prompt Agents / Foundry agents, the supported pattern is:

When Code Interpreter generates a file, the agent response includes annotations with container/file metadata (for example, content[]._meta.container_id and file IDs/names).
Use the container and file APIs to list and download those files while the container is still active.

Typical flow (REST):

List files in the container

Extract container_id from the tools/call response metadata.

Call the Container Files API:

  GET {project_endpoint}/containers/{container_id}/files?api-version=v1
  Authorization: Bearer {token}

The response returns file names and IDs for all files in that container.

Download a specific file

Use the file name/ID from step 1 with the File API download endpoint (as documented under the File API download endpoint for Foundry).

This is the recommended way to retrieve Code Interpreter outputs for Foundry agents.

[Context: Curate intent-based toolbox in Foundry (preview) (rest-api)] [Context: Code Interpreter tool for Microsoft Foundry agents (csharp)] [Context: Code Interpreter tool for Microsoft Foundry agents (python)]

Persistence model and production recommendation

The container sandbox is not a durable storage mechanism. Files there are tied to the session and will expire when the session/container is cleaned up.
There is no indication in the provided context that Foundry agents automatically convert these container files into durable, globally addressable file IDs like the classic Assistants Files API.

For a production chat application that needs persistent access to generated files (charts, images, CSVs) from chat history, the recommended pattern based on the documented APIs is:

Immediately after receiving a response that includes Code Interpreter file annotations:
- Parse the container/file metadata from the response.
- Call the Container Files API to list and then the File API to download the relevant files.
Store the downloaded files in an application-controlled persistent store:
- For example, Azure Blob Storage, a database, or any other long-term storage.
- Persist the mapping between the chat message (or conversation ID) and the stored file URL/path in the app’s own data model.
When rendering chat history:
- Use the app’s own persistent URLs/paths to serve those files to users.

This pattern ensures durability and user access independent of the sandbox lifecycle.

Memory and vector stores vs. file persistence

The “memory” attached to agents and the vector stores used for RAG are separate concepts from Code Interpreter’s sandbox file system.
The context only indicates that Code Interpreter can access attached files and generate new files in the sandbox; it does not state that generated files are automatically stored into memory or vector stores.
Therefore, not seeing generated files “saved in memory” is consistent with the documented behavior. Memory/vector stores are for knowledge and retrieval, not for automatic file persistence.

Summary

Yes, ephemeral sandbox file behavior for Code Interpreter outputs in Foundry agents is expected.
To persist files for production use:
- Use container/file APIs to download outputs as soon as they are generated.
- Store them in application-managed durable storage.
- Reference those stored locations in chat history.
Memory and vector stores do not automatically capture or persist Code Interpreter-generated files.

References:

Share via

Assistants API vs. Prompt Agents. How to access files generated by Code Interpreter tool in Prompt Agents? How to ensure file persistence of such generated files?

1 answer

Your answer