Some applications will work with a browser-based OAuth 2.0 flow that breaks because they run inside the container without access to a browser. For example, the Azure DevOps MCP server works this way. The scenario is like this:
- The agent invokes a tool on the Azure DevOps MCP server
- The MCP server has no access token, so it triggers a browser-based OAuth flow through the XDG-based standard approach
- Nothing happens, because there's no receiver to handle the URL open request.
I think we can solve this if we have something inside the container that receives the URL open request and forwards it to a process running on the host, in this case: huddle. We can for example create a huddle bridge that provides the receiver. And then, the receiver can open the url on your host machine after approval.
Right now, this is stopping me from using the Azure DevOps MCP server inside the container :(
Some applications will work with a browser-based OAuth 2.0 flow that breaks because they run inside the container without access to a browser. For example, the Azure DevOps MCP server works this way. The scenario is like this:
I think we can solve this if we have something inside the container that receives the URL open request and forwards it to a process running on the host, in this case: huddle. We can for example create a
huddle bridgethat provides the receiver. And then, the receiver can open the url on your host machine after approval.Right now, this is stopping me from using the Azure DevOps MCP server inside the container :(