Azure AI Search Private Endpoint Connection Issue — HTTP 424 Tool Server Error

Setup (production, Japan East): Microsoft Foundry account with public network access disabled + private endpoint, standard agent setup with virtual network injection into a delegated subnet, project-level capability host with bring-your-own Azure AI Search / Cosmos DB / Storage, keyless (project managed identity) connection to the search service. The search service (standard tier, 3 replicas) has a private endpoint in a peered VNet, the privatelink DNS zone is linked to the agent VNet, and the project managed identity holds Search Index Data Contributor and Search Service Contributor.Symptom: every POST {project endpoint}/openai/v1/responses that includes the built-in azure_ai_search tool (single tool, tool_choice=required, max_tool_calls=1, store=false, model gpt-5.6-luna) fails with HTTP 424 after 10-13 seconds:{"error":{"code":"tool_server_error","type":"server_error","param":null,"message":"An error occurred while processing your request. You can retry your request, or contact us through an Azure support request ... Please include the request ID a2bc05e8-60c6-417e-8170-6e8254681c51 in your message.","request_id":"2f8cd45c2ec5d8f3608bde6dc8f19ac2"}}Other request IDs (2026-09-12 UTC): 4d971e8e-b4f0-4df7-9709-f35cb4edffe5, ce745f67-6e98-4ce0-95c6-71a580e2d554, c59fc929-8b3b-40fd-b1de-3d62dd093030, 54e65b1a-4976-46a6-bfb4-f74c88f403f9, 228c996e-5437-45cc-a9c1-221176ac8820.What we verified:- Azure AI Search diagnostic logs (OperationLogs) show no request of any kind from the tool in any failure window: no private-endpoint row, no public row, no rejected row. Requests from other callers in the same VNets are logged normally.- We repeated the call with the search service temporarily open to ALL networks (propagation verified by an HTTP 200 from an IP outside the former rules one second earlier): still HTTP 424 (request ID a2bc05e8-... above), and still zero rows at the search service during the call.- A Hosted agent container in the same delegated subnet reaches the same search private endpoint and its queries are logged (HTTP 200), so the subnet, DNS zone, peering and private endpoint work. The data proxy path also reaches the Cosmos DB private endpoint in the same VNet (thousands of logged requests from the project managed identity).- Both capability hosts (account and project) are Succeeded and the project capability host lists the search connection. Account diagnostic settings (RequestResponse/Trace) and a project Application Insights connection produced zero rows for the failing calls; ManagedNetworkEvent is empty; Resource Health and Service Health are clean.- In a development subscription the identical request succeeds 7/7, including with the production differences reproduced one by one and together (NSG + NAT gateway on the agent subnet, search private endpoint in a peered VNet, search public access enabled with IP rules and trusted-services bypass, account public access disabled, serverless Cosmos DB). Remaining untested differences: search tier (standard/3 replicas vs basic/1) and account networkAcls defaultAction (Deny vs Allow).- Possibly related: from the same delegated subnet, the Hosted agent's first TLS handshake to the search private endpoint took 11.2 s, while an App Service in the same VNet completes it in 12-18 ms.Question: which stage of the azure_ai_search tool execution fails for these request IDs (connection resolution, DNS, TCP/TLS to the private endpoint, token acquisition for the project managed identity, the Search HTTP call, or an internal timeout), and is there a known issue or unsupported condition for this topology? We have exhausted customer-visible telemetry; the tool server / data proxy logs are needed. Support case 2609130060000009 is open and linked to this thread; resource names and IDs can be provided privately.