Python: FoundryChatClient sends unsupported reasoning.encrypted_content include for non-reasoning models under stateless (store=False) requests

[jiks-hue]

Describe the bug

FoundryChatClient (agent_framework.foundry) sends every stateless request (no conversation_id/previous_response_id) with include: ["reasoning.encrypted_content"] automatically appended, even when the configured model doesn't support reasoning. For non-reasoning models (e.g. gpt-4.1-mini, gpt-5.4-mini), the Foundry endpoint rejects the request outright:

Error code: 400 - {'error': {'message': 'Encrypted content is not supported with this model.', 'type': 'invalid_request_error', 'param': 'include', 'code': None}}

This breaks every chat request for any agent using a non-reasoning model under the documented store: False / stateless pattern (the standard setup for Foundry Hosted Agent Service, where Foundry — not the client — owns session history).

Reproduction

from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient

client = FoundryChatClient(...)  # project pointing at a non-reasoning model, e.g. gpt-4.1-mini
agent = Agent(client=client, name="Test", default_options={"store": False})

await agent.run("Hello!")  # -> 400 "Encrypted content is not supported with this model."

Also reproduces when hosted via agent_framework_foundry_hosting.ResponsesHostServer and hit over HTTP with a plain (no previous_response_id) /responses request.

Expected behavior

A non-reasoning model should work under store: False without the caller needing to do anything special — include should only carry reasoning.encrypted_content if the caller explicitly requested it, or if the framework has some way of knowing the model supports reasoning.

Root cause (traced in the installed package source)

In agent_framework_openai/_chat_client.py, _prepare_options unconditionally appends the value whenever the request doesn't use service-side storage:

request_uses_service_side_storage = False
for key in ("conversation_id", "previous_response_id", "conversation"):
    value = options.get(key)
    if isinstance(value, str) and value:
        request_uses_service_side_storage = True
        break
if not request_uses_service_side_storage:
    include = list(run_options.get("include", []))
    if "reasoning.encrypted_content" not in include:
        include.append("reasoning.encrypted_content")
    run_options["include"] = include

There's already a fix for exactly this scenario, but it lives on a different, sibling class — agent_framework_foundry/_agent.py's Foundry-Agent-Service class (FoundryAgent/_FoundryAgentChatClient) overrides _prepare_options to strip the auto-added value unless the caller explicitly asked for it:

# Foundry Agent deployments can reject the OpenAI client's automatic encrypted-reasoning
# opt-in even when the configured model otherwise supports reasoning. Preserve an explicit
# caller request, but do not add this provider capability implicitly.
if not caller_requested_encrypted_reasoning and isinstance(run_options.get("include"), list):
    include = [item for item in run_options["include"] if item != "reasoning.encrypted_content"]
    ...

FoundryChatClient (agent_framework_foundry/_chat_client.py) — the class used for Foundry Hosted Agent Service / agent_framework.foundry.FoundryChatClient — does not have this override. RawFoundryChatClient inherits directly from RawOpenAIChatClient with no _prepare_options override, so it hits the bug unguarded. The fix appears to exist for the wrong (or rather, only one of the two) Foundry client classes.

Bisection

Confirmed via testing the actual paired release trains (agent-framework-core/-foundry/-openai release together, so testing packages independently gives false signals):

Release train (date)	core	foundry	openai	Result
2026-07-10	1.11.0	1.10.1	1.10.1	✅ works
2026-07-21	1.12.0	1.10.2	1.10.2	✅ works
2026-07-23	1.12.1	1.10.3	1.11.0	❌ broken
2026-07-30	1.13.0	1.10.4	1.12.0	❌ broken

So the regression was introduced in agent-framework-openai 1.11.0.

Versions

• Broken: agent-framework-openai 1.11.0–1.12.0 (latest at time of filing), agent-framework-foundry 1.10.3–1.10.4
• Working (currently pinned as a workaround): agent-framework-core 1.12.0, agent-framework-foundry 1.10.2, agent-framework-openai 1.10.2
• Python 3.12, macOS (also reproduces in the deployed Linux container via Foundry Hosted Agent Service)

[Neallin-917]

I will investigate this regression against the current main branch. I plan to add a focused unit regression test and keep the fix limited to preserving an explicit caller request while avoiding the unsupported implicit include for FoundryChatClient. I will share a PR only after reproducing and validating the behavior locally.

[Neallin-917]

Update: before making changes I found #7536, an open, approved PR that already implements this same FoundryChatClient behavior and its focused regression tests. To avoid duplicate work, I will not open a competing PR.