[Bug]: Repeated browser auth prompts with `externalbrowser` on macOS when running via `uvx`

[jennaallen]

What happened?

When using the dbt MCP server with Snowflake externalbrowser authentication on macOS, every dbt CLI command triggers a separate browser SSO authentication window. A single dbt build on one model with 2 tests results in 3 browser popups, making the MCP server unusable for real workflows.

Two issues combine to create this problem:

1. uvx creates ephemeral virtualenvs with unique Python binary paths per session. Each session spawns a new path like ~/.cache/uv/archive-v0/<random-hash>/bin/python. macOS Keychain grants access per binary path, so the Snowflake connector's cached SSO token (stored via the keyring library) is never readable by the next session's Python binary. Even clicking "Always Allow" on the Keychain popup doesn't persist because the binary path changes.

2. Each dbt CLI tool spawns a new subprocess. Since dbt-mcp runs each command via subprocess.Popen, every build/run/test/show call creates a new dbt process that opens a new Snowflake connection. Within a single session where Keychain access fails, this means a browser auth popup per query rather than per session.

PYTHON_KEYRING_BACKEND=keyring.backends.null.Keyring eliminates Keychain popups but still triggers browser SSO per query (no cached token)

Steps to Reproduce

1. Configure dbt MCP server via uvx dbt-mcp@latest (the default recommended setup)
2. Configure Snowflake with authenticator: externalbrowser in profiles.yml
3. Run any dbt CLI tool through the MCP server (e.g., dbt build on a model with tests)
4. Observe a separate browser SSO window for each query (1 for the model + 1 per test)

Deployment

Local MCP server

Environment

• dbt-mcp v1.15.0 (installed via uvx dbt-mcp@latest)
• macOS
• Snowflake authenticator: externalbrowser
• allow_id_token = true at the Snowflake account level
• snowflake-connector-python[secure-local-storage] installed
• Claude Code (MCP client)

Relevant log output

Could not retrieve ID_TOKEN from secure storage : Can't get password from keychain: (-128, 'Keychain Access Denied')
Initiating login request with your identity provider. Press CTRL+C to abort and try again...
Going to open: https://[redacted]/sso/saml?SAMLRequest=...
Could not store id_token to keyring, Can't store password on keychain: (-25244, 'Unknown Error')

[jairus-m]

Hi @jennaallen ! Thanks for the detailed issue. I also saw your thread in dbt Community Slack.

With the same setup you mentioned above, I tried my best to reproduce the bug. I used dbt-core w/ the snowflake adapter and only enabled the local CLI tools. I also ran uvx with dbt-mcp@latest (tho simply running uvx dbt-mcp would have the same result). Then ran a dbt build via MCP on a model that also had 2 tests. I wasn't able to reproduce the error with this setup alone!

However, after trying many things, was finally able to reproduce similar-ish behavior and learned that the snowflake-connector-python[secure-local-storage] keychain ACL is related to Python process that runs dbt, not dbt-mcp. So these general findings lead me to believe that this may actually not be a dbt-mcp bug, but a macos <> keychain access issue (tho am not 100% sure).

The way I was able to reproduce the multiple SSO browser popups AND get the -128 and -25244 errors you shared was by:

1. Writing a stale keychain token owned by a different Python process
2. Clicking Deny when macOS showed the keychain permission dialog during dbt build

So for me, the multi SSO popups for every dbt build step came up:

• When a snowflake keychain token does exist but owned by something else (maybe stale token)
• That existing snowflake keychain token denies other non-owner processes from trying to access it

I'm still unsure how this exactly maps to your situation tho as I dont know a ton about macos <> keychain access <> python processes interaction(s) and what your full config/setup is on your end (i can certainly learn more ofc haha).

However do have a question for you:

• Do you know the state of your snowflake keychain access tokens in your system? ie if the token is set to "always allows" for access or is it set to "deny" for all ? or if you may have a stale keychain access token ?

You can find more info about your access tokens in the Keychain Access MacOs app and look for "snowflake" just to see what's there (left click on keychain token --> Get Info --> Access Control)

[jennaallen]

@jairus-m I really appreciate you looking into this. I think I had something funky going on with the snowflake cli and the dbt mcp. I had deleted the token and retried things many times with no luck. However, now things seem to be working. I deleted the keychain token. I ran the dbt mcp. The token was created and python3.10 was in the "always allow accesses by these apps" section. I then ran the snowflake cli, I got the keychain popup, typed in my password, hit "always allow", then python.app was in the "always allow accesses by these apps". I then ran the snowflake cli and the dbt mcp in a new claude session and got no popups or external browser windows for authentication. So, they seem to be playing nice at the moment.

[jairus-m]

@jennaallen great to hear it's since been resolved. We can keep this up for future reference. If at any point they stop playing nice, let us know and we can document some more here. 🙌