Windsurf: URL redirect after scope verification fails with 500 Server Error

[jlrivera81]

Problem
We have our own gitguardian instance. When configuring GitGuardian MCP, I get a 500 server error during redirect after successful authentication and scope validation.

{
  "mcpServers": {
    "GitGuardianDeveloper": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/GitGuardian/gg-mcp.git", "developer-mcp-server"],
      "env": {
        "GITGUARDIAN_URL": "https://gitguardian.mydomain"
      }
    }
  }
}

Tshooting

1. I manually ran uvx command with verbose to get details

uvx -v --from git+https://github.com/GitGuardian/gg-mcp.git developer-mcp-server

2025-10-22 10:05:20,619 - gg_api_core.oauth - INFO - Started callback server on http://localhost:8000
===========================================================
                 GITGUARDIAN OAUTH LOGIN                
===========================================================

The server will open a browser window to https://gitguardian.mydomain for authentication.
You'll need to log in and authorize the application.
After authorization, you'll be redirected to http://localhost:8000

2025-10-22 10:05:20,619 - gg_api_core.oauth - INFO - Opening browser for authorization: https://gitguardian.mydomain/auth/login?response_type=code&client_id=ggshield_oauth&redirect_uri=http%3A%2F%2Flocalhost%3A8000&scope=scan+incidents%3Aread+sources%3Aread&state=%7B%22token_name%22%3A+%22MCP+Token%22%2C+%22random%22%3A+%22A6Ei7OWx%22%7D&code_challenge=MYafgtX06RL5zXbji7GiYw6wxgrxBtTkxCTcf6E7d8I&code_challenge_method=S256&auth_mode=ggshield_login&name=MCP+Token&token_name=MCP+Token&utm_source=cli&utm_medium=login&utm_campaign=ggshield
2025-10-22 10:05:20,709 - gg_api_core.oauth - DEBUG - Browser window opened successfully for 'MCP Token'
2025-10-22 10:10:20,757 - gg_api_core.oauth - ERROR - OAuth authentication failed: Timeout waiting for OAuth callback
2025-10-22 10:10:20,758 - gg_api_core.client - ERROR - OAuth authentication failed: Timeout waiting for OAuth callback
2025-10-22 10:10:20,758 - gg_api_core.mcp_server - WARNING - Error fetching token scopes from /api_tokens/self endpoint: Timeout waiting for OAuth callback

the /auth/login performs the authentication after which I am redirected to scope verification. As with opening the windsurf ide, I am again met with the bad redirect URL and receive 500 server error. Eventually Oauth auth times out.
I'm not sure if this redirect URL is something our server sends or is it the client that creates it ?
Here is the bad redirect URL:
https://gitguardian.mydomain/api/v1/auth/ggshield/authorize?client_id=ggshield_oauth&response_type=code&scope=scan incidents:read sources:read&redirect_uri=http://localhost:8000&code_challenge=MYafgtX06RL5zXbji7GiYw6wxgrxBtTkxCTcf6E7d8I&name=MCP Token&state={"token_name": "MCP Token", "random": "A6Ei7OWx"}&account_id=1

2. I performed a web-auth with GGSheild which appears to simulate the same login flow as gitguardian mcp

ggshield auth login --instance https://gitguardian.mydomain --method web
Complete the login process at:
  https://gitguardian.mydomain/auth/login?response_type=code&client_id=ggshield_oauth&redirect_uri=http%3A%2F%2Flocalhost%3A29170&scope=scan&state=%257B%2522token_name%2522%253A%2520%2522ggshield%2520token%25202025-10-22%2522%252C%2520%2522lifetime%2522%253A%2520null%257D&code_challenge=v4CD7P98DyQEoGqY6tXxUzxEnCc57H_Vno06GD5budo&code_challenge_method=S256&auth_mode=ggshield_login&utm_source=cli&utm_medium=login&utm_campaign=ggshield.
Opening your web browser now...
Success! You are now authenticated.
The personal access token has been created and stored in your ggshield config.

When performing this ggshield web auth method, the redirect url I am sent to after scope validation looks nearly identical to what is seen during GG-MCP uvx failure. the only noticeable differences are the scope and redirect_uri port
https://gitguardian.mydomain/api/v1/auth/ggshield/authorize?client_id=ggshield_oauth&response_type=code&scope=scan&redirect_uri=http://localhost:29170&code_challenge=v4CD7P98DyQEoGqY6tXxUzxEnCc57H_Vno06GD5budo&state={"token_name": "ggshield token 2025-10-22", "lifetime": null}&account_id=1
When inspecting browser, I saw that the redirect to localhost:29170 was successful

I can see that both start the login flow with same auth/login endpoint. I have to verify scope for both. The redirect URIs after scope validation are nearly the same, but MCP results in 500 while ggshield does not.

I dont think the scopes are the problem b/c I am able to accept the scopes. When attempting to create a PAT via UI with extra scopes, it failed for me. So I assume that b/c it I was able to manually create PATs with same scopes that there isnt a problem with redirect uri containing those scopes.
As for the redirect_uri ports being different, I did read that oauth providers might sometimes expect registered redirect_uris. So I'm not sure if it's problematic to use localhost:8000 when the ggshield_oauth client ID might be expected to use localhost:29170 (as noticed in working scenario) ?

[timothedelion]

Hello @jlrivera81 , and thanks for reaching out and for the detailed explanation.

To answer your questions :

• yes the redirect URI is decided by the client that initiate the OAuth process. This client actually creates a local server listening at the given localhost:port
• there is no communication between the self-hosted instance and the client. Everything works with 302 redirects on the browser, that plays as the "intermediary" : the GitGuardian instance responds with a 302, the browser interprets it and make a call to the redirect_uri with some query params attached.
• the port is not supposed to have an impact as GitGuardian OAuth provider accept all localhost:port redirect URIs.

The way we implement this local server differs between ggshield and ggmcp. It's my main lead for now. Still investigating.

(Note we've just renamed the repo : gg-mcp -> ggmcp. GitHub maintains a redirection for a while but will stop at some point. You can already refer to git+https://github.com/GitGuardian/ggmcp.git to have it done)

[timothedelion]

Do you know if the error 500 comes from the GitGuardian self-hosted instance or from the local server that listens behind localhost:8000 ?
If it's from the GitGuardian instance, could you get related logs ?

[jlrivera81]

Do you know if the error 500 comes from the GitGuardian self-hosted instance or from the local server that listens behind localhost:8000 ? If it's from the GitGuardian instance, could you get related logs ?

I'm pretty confident that the 500 is from our server based on browser inspection. As nothing is seen in CLI that would suggest that local server handled any response. It's just sitting there waiting for response to authentication.
Unfortunately, this is hosted by our security team and I haven't heard from them yet and am not really sure what level of support they will provide :)

I was trying to run the MCP server locally though. However, i'm haviing difficulty with setup uising my pyenv environment
I'm thinking that UV and PYenv dont play nicely together though.

[timothedelion]

I've merged this #31

Can you try again :

GITGUARDIAN_URL="https://gitguardian.mydomain" uvx -v --from git+https://github.com/GitGuardian/gg-mcp.git developer-mcp-server ?

[jlrivera81]

I've merged this #31

Can you try again :

GITGUARDIAN_URL="https://gitguardian.mydomain" uvx -v --from git+https://github.com/GitGuardian/gg-mcp.git developer-mcp-server ?

Good news and bad news.
Prior to testing this, I was able to get server spun up locally and tested thoroughly.
Similar to your changes, I hard-coded the correct port, but initially still noticed failure. So I started playing with scopes to see if there was a problem:
Findings

• When hard-coding proper ports and setting developer scopes to anything that does not include "sources:read", it is successful
• when i include sources:read, it failed with 500

So when i tested your changes, I found that even though callback server properly starts on port 29170, i'm still getting 500 response.
To further verify that it is my server having scoping issue, I set scope via env to simulate my local successful testing:
GITGUARDIAN_URL="https://gitguardian.mydomain" GITGUARDIAN_SCOPES="scan,incidents:read" uvx -v --from git+https://github.com/GitGuardian/gg-mcp.git developer-mcp-server

So with your changes and excluding "sources:read" from scope, it works.
This is definitely strange considering I can manually go into git guardian server and create PAT with this scope and others. So I'm not sure if there is a limitation on setting PATs with this scope via API or if its something specific to my server.

[jlrivera81]

I noticed in this old commit: https://github.com/GitGuardian/ggmcp/pull/7/files#diff-729ff0af3f79b233c6ad039dac8a05070dfa74032484d4f077a5a238323367c4

that the "sources:read" was previously commented out suggesting potential "API reliability issues". could that be issue now, specifically for hoste instances ?

[timothedelion]

I noticed in this old commit: https://github.com/GitGuardian/ggmcp/pull/7/files#diff-729ff0af3f79b233c6ad039dac8a05070dfa74032484d4f077a5a238323367c4

that the "sources:read" was previously commented out suggesting potential "API reliability issues". could that be issue now, specifically for hosted instances ?

I've looped with the team in charge of the OAuth provider : a fix for this issue with "sources:read" has been released in the 2025.8 release. Can you check which version you run (X-App-Version header on any HTTP request on the instance. You can use Chrome Dev Tools > Network > Fetch/XHR > Headers ) ?

[jlrivera81]

I've looped with the team in charge of the OAuth provider : a fix for this issue with "sources:read" has been released in the 2025.8 release. Can you check which version you run (X-App-Version header on any HTTP request on the instance. You can use Chrome Dev Tools > Network > Fetch/XHR > Headers ) ?

Looks like: x-app-version 2025.4.1

[rjouhann]

👋 @jlrivera81, I work with @timothedelion at GitGuardian! Could you share what company you're with? I'd be happy to check when the next upgrade is planned for you. Feel free to reach out directly at romain.jouhannet@gitguardian.com.

[jlrivera81]

👋 @jlrivera81, I work with @timothedelion at GitGuardian! Could you share what company you're with? I'd be happy to check when the next upgrade is planned for you. Feel free to reach out directly at romain.jouhannet@gitguardian.com.

@rjouhann
Thanks!! Email sent.