Python: [Bug]: A local tool's approval response is serialized to the Responses API as an MCP approval response, with no matching request → 400

[antsok]

Description

1. Symptom

Approving a gated local tool call ends the run with a hard error from the Responses API:

Error code: 400 - {'error': {'message': "The following MCP approval requests have approval
responses but weren't passed as input: call_OWTUay5B7jQPNHM8IGvIFaC7", 'type':
'invalid_request_error', 'param': None, 'code': None}}

Every answered approval card on the Responses path fails this way, so a gated local tool can never complete its turn.

2. Root cause

Two independent defects, and either fix alone prevents the 400.

2a. PR #7407 made the response arm unconditional

PR #7407 "Preserve approval decisions under OpenAI continuation" (95ec5b7d) split one match arm in two and dropped the storage guard from the response half:

-                case "function_approval_response" | "function_approval_request":
+                case "function_approval_request":
                     if request_uses_service_side_storage:
                         continue
                     ...
+                case "function_approval_response":
+                    prepared = self._prepare_content_for_openai(...)   # no guard

Under request_uses_service_side_storage=True the request is now omitted while the response is always emitted. Before #7407 the shared guard kept the pair consistent — both omitted under storage, both sent without it — so this asymmetry could not arise; the PR even renamed the test that had asserted it (test_prepare_messages_strips_approval_items_under_storage). The failing payload carries an mcp_approval_response and no mcp_approval_request, which is that asymmetry exactly.

The PR's reasoning is sound for a hosted/MCP approval — the service issued and stored the request, so replaying it would duplicate. It assumes every function_approval_response has a server-stored request to pair with, which is false for a local FunctionTool.

The serializer it reaches, _prepare_content_for_openai (agent_framework_openai/_chat_client.py:1965), has no hosted-tool check at all:

case "function_approval_response":
    return {
        "type": "mcp_approval_response",
        "approval_request_id": content.id,
        "approve": content.approved,
    }

agent_framework._tools._is_hosted_tool_approval exists for exactly this distinction (function_call.additional_properties["server_label"]) and is used elsewhere in core, but not here. So a local FunctionTool's approval response — which has no server_label and must never leave the process — is emitted as an mcp_approval_response whose approval_request_id is a local call_id. No mcp_approval_request with that id can exist in the input, so the request is rejected.

The function_approval_request arm immediately above does read server_label, emitting None for a local tool — inconsistent with this arm, and arguably wrong in its own right.

2b. _approval_controls_to_keep only clears a response whose result comes later

PR #7345 "Improve function approval resume and replay" (5987a679) added _approval_controls_to_keep in agent_framework/_sessions.py, called from the concrete HistoryProvider.before_run via _filter_approval_control_messages.

It walks messages in order, registers a local function_approval_response into local_response_ids_by_call_id, and only pops it when it subsequently sees a terminal function_result for that call_id. When the terminal result is seated before the response — which is the layout the approval-resume path produces — the pop happens while the map is still empty, the response is then registered and never cleared, and it is preserved into model input as "unresolved".

This contradicts the stated contract. core/AGENTS.md says: "The base HistoryProvider.before_run filters resolved wrappers from later model replay, but preserves unresolved requests/responses until a terminal result or follow-up request closes them." Measured against the shipped function with one local approval response and that call's terminal result:

Layout	Response replayed?
response, then result — same message	no ✅
response, then result — later message	no ✅
result, then response — same message (the live layout)	yes ❌
result, then response — earlier message	yes ❌

The approval is equally resolved in all four. Order alone decides. Rejected decisions and repeated call_ids leak by the same mechanism.

3. Evidence

The outgoing payload, from the OpenAI client's own debug logging (wrapped here for readability):

'json_data': {'include': ['reasoning.encrypted_content'], 'input': [
  {'type': 'message', 'role': 'user', 'content': [{'type': 'input_text', 'text': '…'}]},
  {'call_id': 'call_OWTUay5B7jQPNHM8IGvIFaC7', 'type': 'function_call_output', 'output': "File 'notes.md' not found."},
  {'type': 'mcp_approval_response', 'approval_request_id': 'call_OWTUay5B7jQPNHM8IGvIFaC7', 'approve': True},
  {'call_id': 'call_zGSd8XqalyjdoHvYs14lDQCZ', 'type': 'function_call_output', 'output': "File 'notes.md' written."},
  …

call_OWTUay… is file_access_read, a local harness tool. Both defects are visible in three lines: its terminal function_call_output precedes the response (2b), and the response is serialized as an mcp_approval_response (2a). Item-type census over one failing run:

10 function_approval_request
 5 function_approval_response
 1 mcp_approval_response      <-- the leak

A probe on the message list as the chat client receives it, immediately before upstream's serialization, shows the leftover is already present and already local:

  [0/user]      text
  [1/tool]      function_result             call_id=call_WMZ0CiDqutoPaeKXq93hjkxs
  [1/tool]      function_approval_response  id=call_WMZ0Ci…  server_label=None  HOSTED=False
  [1/tool]      function_result             call_id=call_clAPm9keQggSCUnru1CI1QcU
  [2/user]      text
  [3/assistant] function_call               call_id=call_clAPm9keQggSCUnru1CI1QcU
  [3/assistant] function_call               call_id=call_WMZ0CiDqutoPaeKXq93hjkxs
  [4/system]    text

Two things this settles. HOSTED=False — no server_label, so it is unambiguously a local tool's approval, and §2a's missing guard is what mis-serializes it. And the response sits in the same role="tool" message as its own terminal function_result, immediately after it — so §2b's order-dependence is triggered within a single message and needs no message-level reordering to bite. _replace_approval_contents_with_results was expected to replace that response with the result; it left both.

4. Reproduction

1. Register a local FunctionTool with approval_mode="always_require". A harness-contributed tool such as file_access_read works, but nothing about the reproduction depends on the harness — any gated local tool reaches the same path.
2. Run against the Responses API with service-side storage in effect.
3. Drive a turn that calls the gated tool, and approve the resulting card.
4. The next request carries an mcp_approval_response with no matching mcp_approval_request, and the API returns the 400 in §1.

Reproduced consistently on azure_foundry/gpt-5.4-mini over the Responses API. Any application that gates a local tool on this path reaches the same failure.

Code Sample

Error Messages / Stack Traces

Package Versions

agent-framework-core: 1.12.1, agent-framework-openai: 1.11.0

Python Version

No response

Additional Context

5. Proposed fix

Primary — 2a. Gate the MCP projection on the approval actually being hosted, mirroring what core already does elsewhere:

case "function_approval_response":
    if not _is_hosted_tool_approval(content):
        return {}          # local approvals are resolved in-process; never send them
    return {"type": "mcp_approval_response", "approval_request_id": content.id, "approve": content.approved}

…and the same guard on the function_approval_request arm, instead of emitting server_label: None.

Nothing is lost by dropping a local approval response. It is resolved in-process by ToolApprovalMiddleware, and its outcome already travels as the ordinary function_call_output for the same call_id — which is why the shared if request_uses_service_side_storage: continue guard could drop it for as long as it did without anyone noticing.

Secondary — 2b. Make _approval_controls_to_keep order-independent: collect terminal results per call_id in a first pass, then decide which responses are unresolved, rather than relying on the result appearing after the response.

6. The same leftover breaks two other connectors

§2b's leftover is not only a Responses-path problem. The same resolved-but-replayed local approval response reaches every provider, and two others cannot represent it either.

Ollama — an outright request failure, and independent of §2a. The AG-UI approval-resume path synthesizes a role="user" message whose only contents are approval controls (_canonical_approval_resume_messages). agent_framework_ollama's _format_user_message rejects any user message with no text or data:

ChatClientInvalidRequestException: Ollama connector currently only supports user messages
with TextContent or DataContent.

This is an inconsistency between two upstream components rather than a consequence of #7407, and it does not need the Responses path at all — it was observed on the previous pin, before #7407 and #7345 merged. It is arguably worth its own issue; it is recorded here because §2b's leftover is what puts those contents in that message.

Gemini — a latent, ordering-dependent unsigning. Since PR #7095 the Gemini 3 thought_signature travels as base64 protected_data on a text_reasoning content and is re-attached by adjacency to the call that immediately follows. _convert_message_contents implements that with a pending_signature local and clears it on every non-reasoning content before the match, so a leaked approval control between carrier and call takes the signature with it and then discards itself via case _. Measured on the pinned connector:

contents	signature on the functionCall part
carrier, call	present
carrier, approval_response, call	None → 400 "Function call is missing a thought_signature in functionCall parts."
carrier, approval_request, call	None → same 400
carrier, call, approval_request	present

Whether it fires is ordering luck — a control after the call is harmless. Note that a separately observed Gemini 400 with the same message has a different cause (the approval replay carries no carrier at all, so there is no signature to eat); that is out of scope for this report, and this section describes only the hazard the leftover creates when a carrier is present.

Chat-completions providers are structurally immune. Mistral, OpenRouter and Hugging Face go through OpenAIChatCompletionClient, whose converter drops approval contents outright — verified offline against the real client, which yields [('tool', result)], [('assistant', tool_calls)], and [] for an approvals-only message. They never reach _prepare_content_for_openai's Responses arm.

[github-actions]

👋 Hi @antsok — thanks for the report! We weren't able to reproduce this against the current codebase, and it looks like it may already be addressed in a more recent release.

• You reported using: agent-framework-core: 1.12.1, agent-framework-openai: 1.11.0

Could you try upgrading to the latest release and let us know if the issue still reproduces? If it does, please reopen this issue or leave a comment with a fresh snippet and stack trace and we'll take another look. 🙏

[antsok]

Retried on the latest releases as asked — it still reproduces. Upgraded from the pin I originally reported against (core 1.12.1 / openai 1.11.0) to agent-framework-core==1.13.0, agent-framework-openai==1.12.0, agent-framework-foundry==1.10.4, and reproduced live against a real Azure Foundry gpt-5.4-mini deployment using the stock FoundryChatClient with no application code.

Why it probably didn't reproduce for you

The ordinary agent loop doesn't fail. Gate a local tool, approve it, and the continuation succeeds — I verified that against the live endpoint. In that layout the approval response precedes its terminal result, so _approval_controls_to_keep drops it and nothing reaches the serializer.

The failure needs the approval-resume layout, where the tool's terminal result is already seated when the answer arrives. Same call, same objects, only the order differs:

response BEFORE result (ordinary agent loop) -> resolved approval replayed: False
result BEFORE response (approval resume)     -> resolved approval replayed: True

So any reproduction that approves a tool inside a single agent loop passes every time. My original report didn't spell that out, which I think is what cost you the repro — apologies.

Reproduction

Needs az login and a Foundry deployment; set FOUNDRY_PROJECT_ENDPOINT and FOUNDRY_MODEL. Step 1 runs the ordinary loop and succeeds; step 2 replays the same service-issued call_id in the resume layout and 400s; step 3 shows offline why the approval was still attached.

"""Live reproduction of #7452 against a real Azure Foundry deployment, latest MAF.

Stock `agent_framework.foundry.FoundryChatClient` — no application code.

  STEP 1  the ordinary agent loop: gated local tool -> approve -> continuation SUCCEEDS.
          Core's `_approval_controls_to_keep` drops the resolved approval here, because
          in this layout the approval response precedes its terminal result.

  STEP 2  the same real, service-issued call_id, with the resolved approval still in the
          history when it reaches the client -> 400 from Azure. This is defect 2a: the
          serializer has no hosted-tool check, so a LOCAL approval becomes an
          `mcp_approval_response` whose `approval_request_id` no MCP request can match.

  STEP 3  offline, no request: core's filter PRESERVES that same resolved approval when
          the terminal result precedes it, which is the layout an approval-resume
          produces. That is defect 2b, and it is what feeds step 2 in production.

Env:  FOUNDRY_PROJECT_ENDPOINT, FOUNDRY_MODEL.   Auth: az login.
"""

from __future__ import annotations

import asyncio
import importlib.metadata as md
import os
import traceback
from typing import Annotated

from agent_framework import Content, Message, RawAgent, tool
from agent_framework._sessions import _filter_approval_control_messages
from agent_framework.foundry import FoundryChatClient
from azure.identity.aio import AzureCliCredential


@tool(approval_mode="always_require")
def read_file(path: Annotated[str, "File to read"]) -> str:
    """Read a file from the local workspace."""
    return f"{path} contains: alpha"


def history(request: Content, *, result_first: bool) -> list[Message]:
    call = request.function_call
    approval = request.to_function_approval_response(approved=True)
    result = Content.from_function_result(call_id=call.call_id, result="notes.md contains: alpha")
    return [
        Message(role="user", contents=[Content.from_text("Read notes.md and tell me its contents.")]),
        Message(role="assistant", contents=[call]),
        Message(role="tool", contents=[result, approval] if result_first else [approval, result]),
    ]


async def main() -> int:
    for pkg in ("agent-framework-core", "agent-framework-openai", "agent-framework-foundry"):
        print(f"{pkg}: {md.version(pkg)}")
    endpoint, model = os.environ["FOUNDRY_PROJECT_ENDPOINT"], os.environ["FOUNDRY_MODEL"]
    print(f"endpoint: {endpoint}\nmodel:    {model}\n")

    async with AzureCliCredential() as credential:
        client = FoundryChatClient(project_endpoint=endpoint, model=model, credential=credential)
        agent = RawAgent(client, "Use the tools you have.", tools=[read_file])
        session = agent.create_session()

        print("=" * 78)
        print("STEP 1 — ordinary agent loop: gated local tool, approved")
        print("=" * 78)
        first = await agent.run("Read notes.md with the read_file tool and tell me its contents.", session=session)
        requests = [c for m in first.messages for c in m.contents if c.type == "function_approval_request"]
        if not requests:
            print(f"no approval raised; text={first.text!r}")
            return 1
        request, conversation_id = requests[0], first.response_id
        call_id = request.function_call.call_id
        print(f"call_id      : {call_id}   (issued by the service)")
        print(f"server_label : {request.function_call.additional_properties.get('server_label')!r}  -> LOCAL tool")
        approved = await agent.run(
            Message(role="user", contents=[request.to_function_approval_response(approved=True)]),
            session=session,
        )
        print(f"continuation : SUCCEEDED -> {approved.text!r}")
        print("  (core dropped the resolved approval: response precedes result here)\n")

        print("=" * 78)
        print("STEP 2 — same call_id, resolved approval still present when it reaches the client")
        print("=" * 78)
        try:
            await client.get_response(
                history(request, result_first=True), options={"conversation_id": conversation_id}
            )
        except Exception:
            print("400 from Azure Foundry — REPRODUCED\n")
            print(traceback.format_exc())
        else:
            print("NOT reproduced; the request succeeded")
            return 1

        print("=" * 78)
        print("STEP 3 — offline: why the approval is still there (core's filter is order-dependent)")
        print("=" * 78)
        for result_first in (False, True):
            kept = _filter_approval_control_messages(history(request, result_first=result_first))
            survived = any(c.type == "function_approval_response" for m in kept for c in m.contents)
            order = "result BEFORE response (approval-resume)" if result_first else "response BEFORE result (agent loop)"
            print(f"  {order:44} -> resolved approval replayed: {survived}")
        return 0


if __name__ == "__main__":
    raise SystemExit(asyncio.run(main()))

Output:

agent-framework-core: 1.13.0
agent-framework-openai: 1.12.0
agent-framework-foundry: 1.10.4

STEP 1 — ordinary agent loop: gated local tool, approved
call_id      : call_RiajEHByeTcVkWeVlt6I3np8   (issued by the service)
server_label : None  -> LOCAL tool
continuation : SUCCEEDED -> 'notes.md contains: alpha'

STEP 2 — same call_id, resolved approval still present when it reaches the client
400 from Azure Foundry — REPRODUCED

STEP 3 — offline: why the approval is still there
  response BEFORE result (agent loop)      -> resolved approval replayed: False
  result BEFORE response (approval-resume) -> resolved approval replayed: True

Stack trace

Traceback (most recent call last):
  File ".../agent_framework_openai/_chat_client.py", line 793, in _get_response
    raw_response = await client.responses.with_raw_response.create(stream=False, **run_options)
  File ".../openai/_legacy_response.py", line 386, in wrapped
    return cast(LegacyAPIResponse[R], await func(*args, **kwargs))
  File ".../openai/resources/responses/responses.py", line 2851, in create
    return await self._post(
  File ".../openai/_base_client.py", line 1977, in post
    return await self.request(cast_to, opts, stream=stream, stream_cls=stream_cls)
  File ".../openai/_base_client.py", line 1762, in request
    raise self._make_status_error_from_response(err.response) from None
openai.BadRequestError: Error code: 400 - {'error': {'message': "The following MCP approval
requests have approval responses but weren't passed as input:
call_RiajEHByeTcVkWeVlt6I3np8", 'type': 'invalid_request_error', 'param': None, 'code': None}}

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "repro_7452_live_foundry.py", line 86, in main
    await client.get_response(
  File ".../agent_framework/_tools.py", line 2930, in _get_response_with_function_invocation
    await super_get_response(
  File ".../agent_framework/observability.py", line 1672, in _get_response
    await super_get_response(
  File ".../agent_framework_openai/_chat_client.py", line 796, in _get_response
    self._handle_request_error(ex)
  File ".../agent_framework_openai/_chat_client.py", line 642, in _handle_request_error
    raise ChatClientException(
agent_framework.exceptions.ChatClientException: ("<class
'agent_framework_foundry._chat_client.FoundryChatClient'> service failed to complete the
prompt: Error code: 400 - ...", BadRequestError(...))

call_Riaj… is issued by the service in step 1, not synthesized — worth knowing if you try to shortcut the setup, because a hand-made id fails earlier and differently (No tool call found for function call output with call_id …).

Same failure without an Azure subscription

If it's easier to run with no credentials, this reaches the identical openai.BadRequestError against a local stub that replays the 400 body. The request is still built entirely by the framework — only the response is canned.

"""Stack trace for #7452, offline.

Drives the PUBLIC client API against a local stub that replays the Responses API's real
400 body, so the request payload is built entirely by the framework and the traceback
frames are genuine. No credentials, no Azure, no MCP server.
"""

from __future__ import annotations

import asyncio
import json
import threading
import traceback
from http.server import BaseHTTPRequestHandler, HTTPServer

from agent_framework import Content, Message
from agent_framework_openai import RawOpenAIChatClient

CALL_ID = "call_LOCAL_TOOL_1"
CAPTURED: dict = {}

ERROR_BODY = {
    "error": {
        "message": (
            "The following MCP approval requests have approval responses "
            f"but weren't passed as input: {CALL_ID}"
        ),
        "type": "invalid_request_error",
        "param": None,
        "code": None,
    }
}


class Stub(BaseHTTPRequestHandler):
    def do_POST(self) -> None:  # noqa: N802
        body = self.rfile.read(int(self.headers.get("Content-Length", 0)))
        CAPTURED["request"] = json.loads(body)
        payload = json.dumps(ERROR_BODY).encode()
        self.send_response(400)
        self.send_header("Content-Type", "application/json")
        self.send_header("Content-Length", str(len(payload)))
        self.end_headers()
        self.wfile.write(payload)

    def log_message(self, *args) -> None:  # silence
        pass


def history() -> list[Message]:
    call = Content.from_function_call(call_id=CALL_ID, name="read_file", arguments={"path": "notes.md"})
    response = Content.from_function_approval_response(True, id=CALL_ID, function_call=call)
    result = Content.from_function_result(call_id=CALL_ID, result="the file contents")
    return [
        Message(role="user", contents=[Content.from_text("read notes.md")]),
        Message(role="assistant", contents=[call]),
        # The approval-resume layout: terminal result seated BEFORE the approval response.
        Message(role="tool", contents=[result, response]),
    ]


async def main() -> None:
    server = HTTPServer(("127.0.0.1", 0), Stub)
    threading.Thread(target=server.serve_forever, daemon=True).start()
    port = server.server_address[1]

    client = RawOpenAIChatClient(
        "gpt-4o-mini", api_key="sk-not-used", base_url=f"http://127.0.0.1:{port}/v1"
    )
    try:
        # conversation_id is what sets request_uses_service_side_storage.
        await client.get_response(history(), options={"conversation_id": "conv_repro"})
    except Exception:
        print("=== request the framework built (input item types) ===")
        items = CAPTURED.get("request", {}).get("input", [])
        print([i.get("type") for i in items])
        for i in items:
            if i.get("type") == "mcp_approval_response":
                print("orphan item:", i)
        print("\n=== traceback ===")
        print(traceback.format_exc())
    finally:
        server.shutdown()


asyncio.run(main())

Root cause, briefly

agent_framework/_sessions.py, _approval_controls_to_keep — registers a local function_approval_response, and pops it only when it subsequently sees that call's terminal function_result. When the result comes first the pop runs against an empty map, so a fully resolved approval survives as "unresolved". core/AGENTS.md states the opposite contract ("filters resolved wrappers from later model replay").

agent_framework_openai/_chat_client.py:1965, _prepare_content_for_openai — has no hosted-tool check, so any function_approval_response becomes {"type": "mcp_approval_response", "approval_request_id": content.id, ...}. For a local FunctionTool that id is a local call_id no MCP request can match. agent_framework._tools._is_hosted_tool_approval already exists for this distinction and is used elsewhere in core.

Note also :1704 vs :1714 — the function_approval_request arm is guarded by if request_uses_service_side_storage: continue, the function_approval_response arm is not, so under service-side storage the request is suppressed while the response is still emitted. That is why the payload can carry a response with no request at all.

Either fix alone breaks the chain.