Use custom MCP for Bitbucket auth in Pull Requests panel instead of T3CODE_BITBUCKET_*?

[NachoooLK]

Context

T3 Code's Bitbucket integration for the Source Control / Pull Requests panel currently requires server-side env vars:

• T3CODE_BITBUCKET_ACCESS_TOKEN, or
• T3CODE_BITBUCKET_EMAIL + T3CODE_BITBUCKET_API_TOKEN

Without those it shows 'Not authenticated' and operations like list fail (unauthenticated rate-limit errors against bitbucket.org).

Use case

I already have access to a custom internal MCP server that authenticates to Bitbucket on its own (OAuth via the MCP) and exposes PR/repository tools to the agent. The agent can list/get/diff/comment PRs through the MCP just fine.

But the native Pull Requests page / Source Control UI can't use it — it only understands the built-in token auth above.

Question / feature request

Is there any supported way to:

1. Plug a custom MCP (or its credentials) as the auth/backend for the native Bitbucket provider, so the Pull Requests panel uses it?
2. Or, alternatively, let the agent's MCP tools power that panel?

If not supported today, would you consider supporting custom auth providers for source control, or documenting a recommended workaround?

Thanks!

[juliusmarminge]

Thanks for the clear write-up. This is a real gap, but it is not supported today.

The native Source Control / Pull Requests UI and the agent’s MCP tools are separate stacks.

Native Bitbucket (PR panel, Settings → Source Control, clone/publish, Git actions) talks to Bitbucket Cloud over HTTP using only server env vars:

• T3CODE_BITBUCKET_ACCESS_TOKEN (Bearer), or
• T3CODE_BITBUCKET_EMAIL + T3CODE_BITBUCKET_API_TOKEN (Basic)

T3CODE_BITBUCKET_API_BASE_URL only changes the API host; it does not change how auth is obtained. There is no settings field, OAuth login, or “use this MCP” option. Bitbucket is the one host that is type: "api" (env + HTTP). GitHub / GitLab / Forgejo / Azure DevOps use their CLIs instead.

If those vars are unset, discovery still lists Bitbucket as available, probeAuth reports Not authenticated, and list/get still hit api.bitbucket.org without credentials (which is why you see unauthenticated rate-limit errors).

Agent MCP is the other direction. A custom MCP you attach to a session is available to the model as tools. It does not implement PullRequestProvider and is never consulted by the PR page. T3’s own MCP pull-request toolkit (link_pull_request, thread PR listing, etc.) is T3 → agent, and it also does not authenticate Bitbucket for the UI.

There is no custom source-control auth provider, no MCP-backed Bitbucket driver, and no way to reuse MCP OAuth tokens as T3CODE_BITBUCKET_*. GitHub sharing (use another environment’s gh creds) is GitHub-only and also not MCP.

Workaround for the native panel: set one of the credential pairs on the T3 Code server process and restart, then Rescan in Settings → Source Control. The token needs pull request, repository, and user read (read:user:bitbucket). If your MCP can mint or export a Bitbucket access token, that value in T3CODE_BITBUCKET_ACCESS_TOKEN is the only supported way to feed the panel. Desktop/WSL env delivery is a known pain (#5840, #7621) — the vars have to reach the running server, not only a shell profile.

Workaround without native UI: keep using the custom MCP from the agent for list/get/diff/comment. That path will not populate the Pull Requests page.

Treating this as an enhancement: a first-class custom auth backend (or an MCP-backed source-control provider) would be new architecture, not a small hook. Leaving it open for product to decide whether to take that on. Related Bitbucket issues (#5840, #7621, #8328) are env-delivery / API bugs, not this request.

[leo-mathurin]

Bitbucket Data Center please 🤠