Description
When a Python Foundry hosted agent uses FoundryToolbox with the Work IQ preview tool, the first delegated OAuth request returns the expected JSON-RPC CONSENT_REQUIRED error and consent URL. However, ResponsesHostServer does not emit an oauth_consent_request output item. The URL is only visible in the hosted-agent logs and the client receives a failed response.
This is similar to #5535 and the .NET flow fixed by #6562, but it has a different root cause: Work IQ identifies its toolbox source as a2a_preview, while the Python hosting consent parser only accepts mcp.
Steps to reproduce
- Create a Foundry OAuth2
RemoteA2A connection targeting Work IQ at https://workiq.svc.cloud.microsoft/a2a/.
- Add a
WorkIQPreviewToolboxTool backed by that connection to a Foundry toolbox.
- Create a Python hosted agent using
FoundryToolbox and ResponsesHostServer.
- Invoke the agent as a user who has not yet completed delegated OAuth authorization for the connection.
The toolbox gateway returns a sanitized error with this shape:
{
"code": -32006,
"message": "tools/list failed ... {\"errors\":[{\"name\":\"work-iq-connection\",\"type\":\"a2a_preview\",\"error\":{\"code\":\"CONSENT_REQUIRED\",\"message\":\"https://<consent-url>\"}}]}"
}Expected behavior
ResponsesHostServer should return a client-visible output item such as:
{
"type": "oauth_consent_request",
"server_label": "work-iq-connection",
"consent_link": "https://<consent-url>"
}The user can then open the link, authorize once, and resend the original prompt. Automatic turn resumption is separately tracked by #5594.
Actual behavior
The consent URL is logged, but no actionable oauth_consent_request reaches the client.
Root cause
In agent_framework_foundry_hosting._responses.consent_url_from_error, extraction currently requires:
error.get("type") == "mcp"Work IQ emits:
Therefore the parser returns None, and the host treats the connection-time consent exception as a generic failure.
Workaround and validation
A local compatibility wrapper that preserves the existing parser and additionally accepts a2a_preview when the outer JSON-RPC code is -32006 and the nested error code is CONSENT_REQUIRED resolves the issue.
This workaround was validated both with a synthetic parser test and with a deployed Python hosted agent. The deployed invocation returned a completed response containing type: oauth_consent_request, server_label: work-iq-connection, and the short-lived consent link.
A more future-proof upstream fix may be to identify the consent condition from the JSON-RPC and nested error codes rather than restricting it to one toolbox source type.
Package versions
agent-framework-core==1.11.0agent-framework-foundry==1.10.1agent-framework-foundry-hosting==1.0.0a260709 (latest available during reproduction)- Python 3.13
Related issues
Disclosure
This issue was written by GitHub Copilot based on a reproduced failure, inspection of the installed package source, and a successful deployed workaround.
Description
When a Python Foundry hosted agent uses
FoundryToolboxwith the Work IQ preview tool, the first delegated OAuth request returns the expected JSON-RPCCONSENT_REQUIREDerror and consent URL. However,ResponsesHostServerdoes not emit anoauth_consent_requestoutput item. The URL is only visible in the hosted-agent logs and the client receives a failed response.This is similar to #5535 and the .NET flow fixed by #6562, but it has a different root cause: Work IQ identifies its toolbox source as
a2a_preview, while the Python hosting consent parser only acceptsmcp.Steps to reproduce
RemoteA2Aconnection targeting Work IQ athttps://workiq.svc.cloud.microsoft/a2a/.WorkIQPreviewToolboxToolbacked by that connection to a Foundry toolbox.FoundryToolboxandResponsesHostServer.The toolbox gateway returns a sanitized error with this shape:
{ "code": -32006, "message": "tools/list failed ... {\"errors\":[{\"name\":\"work-iq-connection\",\"type\":\"a2a_preview\",\"error\":{\"code\":\"CONSENT_REQUIRED\",\"message\":\"https://<consent-url>\"}}]}" }Expected behavior
ResponsesHostServershould return a client-visible output item such as:{ "type": "oauth_consent_request", "server_label": "work-iq-connection", "consent_link": "https://<consent-url>" }The user can then open the link, authorize once, and resend the original prompt. Automatic turn resumption is separately tracked by #5594.
Actual behavior
The consent URL is logged, but no actionable
oauth_consent_requestreaches the client.Root cause
In
agent_framework_foundry_hosting._responses.consent_url_from_error, extraction currently requires:Work IQ emits:
Therefore the parser returns
None, and the host treats the connection-time consent exception as a generic failure.Workaround and validation
A local compatibility wrapper that preserves the existing parser and additionally accepts
a2a_previewwhen the outer JSON-RPC code is-32006and the nested error code isCONSENT_REQUIREDresolves the issue.This workaround was validated both with a synthetic parser test and with a deployed Python hosted agent. The deployed invocation returned a completed response containing
type: oauth_consent_request,server_label: work-iq-connection, and the short-lived consent link.A more future-proof upstream fix may be to identify the consent condition from the JSON-RPC and nested error codes rather than restricting it to one toolbox source type.
Package versions
agent-framework-core==1.11.0agent-framework-foundry==1.10.1agent-framework-foundry-hosting==1.0.0a260709(latest available during reproduction)Related issues
Disclosure
This issue was written by GitHub Copilot based on a reproduced failure, inspection of the installed package source, and a successful deployed workaround.