🔴 Required Information
Please ensure all items in this section are completed to allow for efficient
triaging. Requests without complete information may be rejected / deprioritized.
If an item is not applicable to you - please mark it as N/A
Describe the Bug:
We are currently experiencing problems when using the recommended OIDC auth flow (via Keycloak) for toolsets. The issue arises of the auth request is triggered by a tool call associated to a subagent (and not the root agent). This affects both the ADK Web UI as well as the ADK API server. For the former, the auth pop-up never shows up in such a case (instead, only a text box to enter a code manually is shown). By contrast, if the auth request is triggered by a tool call associated to the root agent, everything works as expected. Also, the issue arises with the current version 2.9.1 of ADK, but has also been observed with the earlier version 2.8.0.
Steps to Reproduce:
- Set up a root agent with a subagent, where the latter has a tool requiring auth with an OIDC flow
- Prompt the agent to make the subagent issue a tool call, triggering the auth request
- Observe that the auth is never resolved; in case of the ADK Web UI, the corresponding pop-up is never triggered but only shows a text box to enter a code
- The logs make absolutely no notice of this event
Expected Behavior:
Subagents should be treated in an equivalent manner as root agents when it comes to auth requests, resolving the auth flow as expected.
Observed Behavior:
In the case the auth request is triggered by a subagent, the auth flow gets stuck and is never resolved. In case of the ADK Web UI, the corresponding pop-up is never triggered.
Environment Details:
- ADK Library Version (pip show google-adk):
2.9.1 (but also observed with 2.8.0)
- Desktop OS:** Ubuntu 24.04.5 LTS inside WSL on Windows 11
- Python Version (python -V):
3.13.13
Model Information:
- Are you using LiteLLM: No
- Which model is being used:
gemini-3.7-flash via Vertex AI
🟡 Optional Information
Providing this information greatly speeds up the resolution process.
Regression:
Tested and confirmed with both 2.8.0 and 2.9.1, no information available about earlier versions.
Logs:
As mentioned above, the logs make absolutely no notice of the stuck auth flow. They are entirely inconclusive.
Screenshots / Video:
N/A
Additional Context:
N/A
Minimal Reproduction Code:
N/A
How often has this issue occurred?:
The problem is 100% reproducible with the described flow.
🔴 Required Information
Please ensure all items in this section are completed to allow for efficient
triaging. Requests without complete information may be rejected / deprioritized.
If an item is not applicable to you - please mark it as N/A
Describe the Bug:
We are currently experiencing problems when using the recommended OIDC auth flow (via Keycloak) for toolsets. The issue arises of the auth request is triggered by a tool call associated to a subagent (and not the root agent). This affects both the ADK Web UI as well as the ADK API server. For the former, the auth pop-up never shows up in such a case (instead, only a text box to enter a code manually is shown). By contrast, if the auth request is triggered by a tool call associated to the root agent, everything works as expected. Also, the issue arises with the current version
2.9.1of ADK, but has also been observed with the earlier version2.8.0.Steps to Reproduce:
Expected Behavior:
Subagents should be treated in an equivalent manner as root agents when it comes to auth requests, resolving the auth flow as expected.
Observed Behavior:
In the case the auth request is triggered by a subagent, the auth flow gets stuck and is never resolved. In case of the ADK Web UI, the corresponding pop-up is never triggered.
Environment Details:
2.9.1(but also observed with2.8.0)3.13.13Model Information:
gemini-3.7-flashvia Vertex AI🟡 Optional Information
Providing this information greatly speeds up the resolution process.
Regression:
Tested and confirmed with both
2.8.0and2.9.1, no information available about earlier versions.Logs:
As mentioned above, the logs make absolutely no notice of the stuck auth flow. They are entirely inconclusive.
Screenshots / Video:
N/A
Additional Context:
N/A
Minimal Reproduction Code:
N/A
How often has this issue occurred?:
The problem is 100% reproducible with the described flow.