Decide login strategy by options or runtime

[erwinkramer]

When attempting to use the logintool somewhere hosted remote, I get:

2026-01-06T21:00:48.0082663Z warn: MCPify.Tools.LoginTool[0]
2026-01-06T21:00:48.0082895Z       Failed to open browser automatically.
2026-01-06T21:00:48.0082935Z       System.ComponentModel.Win32Exception (2): An error occurred trying to start process 'xdg-open' with working directory '/home/site/wwwroot'. No such file or directory

It then takes about 2 minutes until i get a timeout:

2026-01-06T21:02:48.8722965Z info: MCPify.Tools.LoginTool[0]
2026-01-06T21:02:48.8723278Z       Login timed out or was cancelled for session 195e01704e564fc6a0b370337fd41186

...which makes sense, since it's hosted somewhere it cannot possibly open a browser for the client. But for the end user, this also means waiting 2 minutes. After that, the LLM does understand that it just has to give the client the URL so he/she can copy that into the browser to finalize the auth flow.

This library should either:

1. have a configurable option to specify to not attempt this browser opening proces, or,
2. recognize it cannot attempt it in the first place, by checking the capabilities of the runtime.

[abdebek]

@erwinkramer,

First, as always, thank you so much. I agree that the current browser-opening behavior is problematic, especially in hosted environments.

I've implemented a temporary fix by adding the LoginBrowserBehavior configuration option. You can now disable automatic browser launching by setting it to "Never" in your configuration. This should eliminate the 2-minute timeout in your scenario.

Actually, I'm against the LoginTool's overall design because it's always been just a necessary compromise rather than a proper solution. Moving forward, I believe we should standardize on conventional OAuth flows that don't require any non-standard browser automation. This would make the library more predictable and suitable for a wider range of deployment scenarios.

I'll keep this issue open to keep our discussion go on until we reach a sound conclusion.

[erwinkramer]

I'm against the LoginTool's overall design because it's always been just a necessary compromise rather than a proper solution. Moving forward, I believe we should standardize on conventional OAuth flows that don't require any non-standard browser automation.

That's what I'm thinking too. Please look at this diagram: https://modelcontextprotocol.io/specification/draft/basic/authorization#authorization-server-discovery-sequence-diagram - this is what clients are implementing, and I've seen this working fine with the GitHub MCP server via GitHub Copilot inside of VS Code where VS Code is directly behaving as the client (and challenging the auth).