Containers API returning HTTP 500 for all existing containers — Code Interpreter output files unretrievable (East US , since ~Aug 9 2026)

Marco117 85 Reputation points
2026-08-11T01:44:06.16+00:00

TL;DR

Every endpoint under /openai/v1/containers/* returns HTTP 500 for containers that actually

exist, while the rest of the same resource is healthy under the same token. Code Interpreter runs

complete successfully and return valid cfile_ / cntr_ IDs, but the generated files can never be

retrieved. Reproducible with raw HTTP, with the .NET SDK, and in the Foundry Playground UI.

Started around 2026-08-08. Worked normally through 2026-08-07 with no changes on our side.

There is a repro script below if you want to check whether your resource is affected.

Environment

| | |

|---|---|

| Service | Microsoft Foundry — Agent Service / Responses API |

| Path | services.ai.azure.com/api/projects/<project> (Foundry Agents, not the classic Assistants API) |

| Region | East US |

| Model | gpt-5.2-chat (unchanged since well before onset) |

| Tool | Code Interpreter, container: { type: "auto" } |

| Client | .NET 8, Azure Functions isolated worker v4 |

| Auth | DefaultAzureCredential, audience https://ai.azure.com |

Packages:


<PackageReference Include="Azure.AI.Projects" Version="2.0.0-beta.1" />

<PackageReference Include="Azure.AI.Projects.OpenAI" Version="2.0.0-beta.1" />

<PackageReference Include="Azure.Identity" Version="1.18.0-beta.1" />

<!-- transitive: OpenAI 2.8.0, System.ClientModel 1.9.0 -->

Symptom

The agent run itself succeeds. The response completes with status: Completed and the annotations

contain valid container file references. Only retrieval fails:


[Information]  Foundry response completed with status: Completed

[Error]        Error downloading generated file cfile_6a7a717b20a88190a4f23199b306a6a6:

               HTTP 500 (server_error: )

               The server had an error processing your request. Sorry about that! ...

               (Please include the request ID a2a7abfb-7637-4b9c-94f8-2083e46f22ee in your email.)

[Error]        Error downloading generated file cfile_6a7a7180a68c8190b41211846efef7f6:

               HTTP 500 (server_error: )

               ... (request ID f4919d6d-8c73-4cd3-9fbd-f6f4866f03bb)

Note that both files came from the same container but produced different request IDs, so

each content request fails individually — it is not a single failed session or a dead container.

The 500 body is the generic server_error with no detail field populated.

Client code — both the manual and the SDK approach fail identically

The container and file IDs come from the response annotations, which are populated correctly:


// annotation carries FileId, Filename and ContainerId — all present and well-formed

string fileId      = "cfile_6a7a761a56508190a8243d82b3329d44";

string fileName    = "synthetic_time_series.png";

string containerId = "cntr_6a7a760a4488819083b031fb23041e7808c9661d4ee9a3f9";

Approach 1 — manual HTTP against the documented endpoint. This is what we ran in production

until it broke:


AccessToken token = await credential.GetTokenAsync(

    new TokenRequestContext(["https://ai.azure.com/.default"]), CancellationToken.None);

using var request = new HttpRequestMessage(

    HttpMethod.Get,

    new Uri($"{projectEndpoint}/openai/v1/containers/{containerId}/files/{fileId}/content"));

request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token.Token);

using HttpResponseMessage response = await httpClient.SendAsync(request);

response.EnsureSuccessStatusCode();          // throws — HTTP 500

return await response.Content.ReadAsByteArrayAsync();

Approach 2 — the SDK ContainerClient, as the current documentation recommends:


ContainerClient containerClient = projectOpenAIClient.GetContainerClient();

BinaryData fileData = await containerClient.DownloadContainerFileAsync(

    containerId: containerId,

    fileId: fileId);                         // throws ClientResultException — HTTP 500

byte[] bytes = fileData.ToArray();

Both fail with the same generic server_error. Switching from the manual call to the SDK changed

nothing except the exception type — which is worth knowing if you are considering that migration as

a fix. It is not one.

One practical note if you do migrate: ClientResultException surfaces the service response body,

whereas EnsureSuccessStatusCode() discards it. That is how we obtained the request IDs above. If

you are still on the manual approach and getting opaque failures, read the response body before

throwing.

Side note — Azure.AI.Extensions.OpenAI is not installable alongside Azure.AI.Projects.OpenAI 2.0.0-beta.1

The documentation for ContainerClient points at the Azure.AI.Extensions.OpenAI package. Adding

it to a project that already references Azure.AI.Projects.OpenAI 2.0.0-beta.1 produces a runtime

MissingMethodException, because the two have incompatible OpenAI dependencies:

| Package | Requires |

|---|---|

| Azure.AI.Extensions.OpenAI 2.0.0 | OpenAI >= 2.9.1 |

| Azure.AI.Projects.OpenAI 2.0.0-beta.1 | OpenAI >= 2.8.0, compiled against 2.8.0 |

NuGet silently resolves to 2.9.1, which changed the ResponsesClient constructor and

CreateResponseOptions signatures. It compiles cleanly and then fails at runtime with, for example:


Method not found: 'Void OpenAI.Responses.ResponsesClient..ctor(

    System.ClientModel.Primitives.ClientPipeline, System.String, OpenAI.OpenAIClientOptions)'

The extra package turns out to be unnecessary: OpenAI 2.8.0 already ships

OpenAI.Containers.ContainerClient and GetContainerClient(), so ContainerClient is reachable

with the existing dependency set. Worth flagging since the docs lead you into the incompatible

combination.

Isolation results

All of the following were issued back-to-back, with the same bearer token, as raw HTTP with no

SDK in the path:

| Request | Result |

|---|---|

| GET /openai/v1/files | 200 OK |

| GET /openai/v1/containers/cntr_0000...0000 (nonexistent) | 404, well-formed invalid_request_error |

| GET /openai/v1/containers (list all) | timeout — no response after 60s |

| GET /openai/v1/containers/{real_id} | 500 server_error |

| GET /openai/v1/containers/{real_id}/files | 500 server_error |

| GET /openai/v1/containers/{real_id}/files/{file_id} | 500 server_error |

| GET /openai/v1/containers/{real_id}/files/{file_id}/content | 500 server_error |

The API front end is clearly alive and routing correctly — it returns a clean 404 for a container

that does not exist. It only fails for containers that do exist, and hangs entirely when asked

to enumerate them. That pattern points at the backing store rather than the API layer.

Reproduce it on your own resource

Generate a chart with Code Interpreter, capture the cntr_ and cfile_ IDs from the response

annotations, then run this within 20 minutes (containers expire on idle):


$ep  = "https://<your-resource>.services.ai.azure.com/api/projects/<your-project>"

$cnt = "cntr_..."   # container ID from the annotation

$fid = "cfile_..."  # file ID from the annotation

$tok = az account get-access-token --resource "https://ai.azure.com" --query accessToken -o tsv

$h   = @{ Authorization = "Bearer $tok" }

# Control — should be 200. Proves auth and the resource are healthy.

(Invoke-WebRequest "$ep/openai/v1/files" -Headers $h -SkipHttpErrorCheck).StatusCode

# Control — should be 404. Proves the Containers API routes and handles errors correctly.

(Invoke-WebRequest "$ep/openai/v1/containers/cntr_0000000000000000000000000000000000000000000000" `

    -Headers $h -SkipHttpErrorCheck).StatusCode

# The failures — all 500 for us.

(Invoke-WebRequest "$ep/openai/v1/containers/$cnt" -Headers $h -SkipHttpErrorCheck).StatusCode

(Invoke-WebRequest "$ep/openai/v1/containers/$cnt/files" -Headers $h -SkipHttpErrorCheck).StatusCode

(Invoke-WebRequest "$ep/openai/v1/containers/$cnt/files/$fid/content" -Headers $h -SkipHttpErrorCheck).StatusCode

# Hangs for us — no response after 60s.

(Invoke-WebRequest "$ep/openai/v1/containers" -Headers $h -SkipHttpErrorCheck -TimeoutSec 60).StatusCode

bash equivalent:


EP="https://<your-resource>.services.ai.azure.com/api/projects/<your-project>"

TOK=$(az account get-access-token --resource "https://ai.azure.com" --query accessToken -o tsv)

for U in \

  "$EP/openai/v1/files" \

  "$EP/openai/v1/containers/cntr_0000000000000000000000000000000000000000000000" \

  "$EP/openai/v1/containers/$CNT" \

  "$EP/openai/v1/containers/$CNT/files" \

  "$EP/openai/v1/containers/$CNT/files/$FID/content" ; do

  printf '%s -> %s\n' "$U" "$(curl -s -o /dev/null -w '%{http_code}' -H "Authorization: Bearer $TOK" "$U")"

done

Already ruled out

Listing these so nobody repeats the work:

  • Authentication / RBAC — the standard Files API returns 200 with the identical token.
  • Token audience — https://ai.azure.com is correct. Using https://cognitiveservices.azure.com returns an explicit 401 naming ai.azure.com as expected.
  • Deprecated or removed endpoint — the endpoint is still documented, and a nonexistent container ID returns a properly formed 404.
  • api-version — passing it on the /v1 path returns 400 "api-version query parameter is not allowed when using /v1 path", so there is no alternate API version to fall back to.
  • Container expiry — an expired or absent container returns 404. Ours returns 500.
  • Client SDK or client code — reproduced with raw HTTP, with the .NET SDK, and in the Foundry Playground UI. The Playground failing is what first told us this was not client-side.
  • Model configuration — unchanged since long before onset, and the same model worked through 2026-08-07.
  • Region or resource specific — another tenant reports the same thing within a day of our onset (see Related reports), and our production resource began failing a few days after our test resource did.
  • Microsoft Q&A #5969971 (2026-08-08) — different tenant, same generic server_error on the Code Interpreter file-output path, no official resolution: https://learn.microsoft.com/en-ca/answers/questions/5969971/my-foundry-agent-give-error-when-i-ask-to-draw-cha In that report the run itself returns 500, whereas ours completes and fails on retrieval — a different stage, but consistent with the same backing store being unavailable.
  • Azure/azure-sdk-for-net #54965 — cfile_ IDs not retrievable (404 via the Files API), still open, labelled Service Attention.
  • microsoft/agent-framework #3081 — same 404 class, closed.

Impact and timeline

Chart and image generation is a user-facing feature of our production data-analysis service. Users

currently receive text-only answers with all visualizations silently missing.

| | |

|---|---|

| Working normally through | 2026-08-07 |

| Test resource failing | ~2026-08-08 onwards |

| Production resource still working while test was already failing | 2026-08-08 to 2026-08-10 |

| Production resource failing | 2026-08-11 (confirmed) |

Two separate resources started failing a few days apart, which suggests a progressive rollout

rather than a resource-level fault. Note also that the Microsoft Q&A report linked above is dated

2026-08-08 — an unrelated tenant hitting this within a day of our own onset.

Microsoft Foundry
Microsoft Foundry

A unified Azure platform for creating and managing AI models, agents, and applications with built‑in enterprise security, monitoring, and governance

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.