# Self-hosted Bitbucket \(Server/Data Center\) remotes are treated as Bitbucket Cloud → useless api.bitbucket.org traffic; request Bitbucket Server support · Issue \#14591 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/14591)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: completed

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/14591)

---

## Summary
Repos hosted on a self-hosted Bitbucket Server / Data Center instance (e.g. `https://bitbucket.example.com/scm/proj/repo.git`) are detected as `kind: "bitbucket"` ("Bitbucket Self-Hosted") because `isBitbucketHost()` matches any host. But `BitbucketApi` only speaks the Bitbucket Cloud API (`DEFAULT_API_BASE_URL = "https://api.bitbucket.org/2.0"`, `/2.0/repositories/{workspace}/{repo}/...`). As a result, the PR sync reactor keeps querying **api.bitbucket.org** for a repository that lives on a completely different server.

## Observed
- T3 Code Nightly `0.0.43-nightly.20260928`, Electron desktop app.
- Remote: `https://bitbucket.example.com/scm/<project>/<repo>.git` (Bitbucket Data Center).
- Across rotated `server.trace.ndjson` logs: spans to `https://api.bitbucket.org` (2,165 `Interrupted`, 136 `Failure`, 896 `Success`), from `PullRequestSyncReactor.syncGroup` / `PullRequestReadCache` / `PullRequestService.persistedRead`.
- Pointing `T3CODE_BITBUCKET_API_BASE_URL` at the self-hosted server does not help: Bitbucket Server exposes `/rest/api/1.0/projects/{KEY}/repos/{slug}/...`, while `/2.0/repositories/...` on that host returns 302 (login redirect).

## Possibly related: backend freeze → "<hostname> is reconnecting" forever
Twice in one day, the backend froze shortly after some of these api.bitbucket.org requests were `Interrupted`:
- Last log spans: `PullRequestSyncReactor` spans (`Interrupted`) → then silence. The UI showed "<hostname> is reconnecting" indefinitely.
- The frozen backend: 0% CPU; the port still accepts connections; main thread in wait reason `DelayExecution`.
- After the app window was closed, the backend process **could not be killed** (`Stop-Process -Force` / `taskkill /F` fail; 1 thread left, stuck in kernel). It keeps its port (3773, 3774...) until reboot, and each restart picks the next port.
- The machine runs corporate endpoint security (EDR + web/DLP filter + App Volumes), so the unkillable process is likely a kernel filter driver hang, not T3 Code itself. The trigger appears to be the high volume of cancelled outbound HTTPS requests to api.bitbucket.org. Orphaned, hung `git.exe` processes (`git config --null --type=path http.*` spawned by Git Credential Manager) were also present.
- Not ruled out: SQLite locking (tested: read and BEGIN IMMEDIATE on state.sqlite succeed instantly while frozen).
- Workaround: point `T3CODE_BITBUCKET_API_BASE_URL` at `127.0.0.1:9` (requests fail locally in ~80 ms, so there is no outbound traffic).

## Requests
1. **Don't call api.bitbucket.org for non-bitbucket.org hosts.** For `Bitbucket Self-Hosted`, either skip PR sync or require explicit configuration.
2. **Bitbucket Server / Data Center support** (REST API 1.0, HTTP access token auth, per-host base URL), similar to how GitLab self-hosted is handled.
3. **Add a setting to disable PR sync per project.**
4. (Nice to have) Make sure aborted PR-sync HTTP requests can't wedge the backend, and that the desktop app detects a frozen backend and restarts it instead of showing "reconnecting" forever.