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

Hi.

1. We're testing migration from Assistants API to Prompt Agents.
2. 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.
3. 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.

4. 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?
5. 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.

Answer 1

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!

Answer 2

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

1. 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]

2. 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):

1. 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.

2. 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)]

3. 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:

1. 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.
2. 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.
3. 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.

4. 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.

5. 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:

• Code Interpreter tool for Microsoft Foundry agents (rest)
• Curate intent-based toolbox in Foundry (preview) (rest-api)
• Code Interpreter tool for Microsoft Foundry agents (csharp)
• Code Interpreter tool for Microsoft Foundry agents (python)
• Azure OpenAI Assistants Code Interpreter (Preview)
• Azure OpenAI Assistants Code Interpreter (Preview) (classic)