# fix\(gitlab\): identify offline remotes from local config · PR \#19397 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/pull/19397)

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

Visibility: public

State: open

Source repository: Unavailable fork

Source branch: fix/gitlab-offline-remote-discovery

Target branch: main

Head commit: af44b6a4c86f00154dd9e77309d92016fd3750c8

[Discussion and reviews](https://git.cafe/pingdotgg/t3code/pull/19397)

[Commits](https://git.cafe/pingdotgg/t3code/pull/19397/commits?format=markdown)

[Files changed](https://git.cafe/pingdotgg/t3code/pull/19397/diffs?format=markdown)

## Description

---

Unknown self-hosted GitLab remotes were identified through a network-dependent authentication probe. When the host was offline or behind a disconnected VPN, provider discovery could wait for that probe even though glab already knew the host locally.

The GitLab adapter now first reads `glab config get api_host --host <remote-host>` during unknown-remote refinement. It preserves the remote host spelling for glab's case-sensitive configuration keys and accepts only matching normalized host/origin output, including the port. Failed config reads stay retryable. A successful lookup that does not match falls back to the existing host-scoped authentication probe, preserving token-based logins without api_host and separate API host/port configurations. Matching local configuration identifies the integration without validating its token. Ordinary authentication still uses `glab auth status`.

This retains [@Exotic209093’s original contribution](https://github.com/pingdotgg/t3code/pull/19397) and commits, with current main merged. The shared discovery hook is already on main, so its obsolete hunks and duplicate resolver tests were removed. Fixes [#17209](https://github.com/pingdotgg/t3code/issues/17209).

Verification on headless Linux, Node 24:

- **66 → 63 focused tests across 5 → 4 files**, all 63 passing on the revised implementation. The merged baseline had four stale-test failures against main's current callback, host casing and command shape. The PR-only core test file was removed; registry integration now covers actual routing, exact host keys, ports, rejected config and retry/cache behavior. Existing ordinary-authentication and Forgejo coverage remains. Token-login and separate API-endpoint regressions failed against the earlier candidates and pass with the compatibility fallback.
- Restoring main's production implementation makes the offline registry regression fail; restoring the fix makes it pass. Production bytes were restored exactly.
- Scoped GitLab/server typechecks, lint, formatting and diff checks passed. No repository-wide checks ran locally.
- A real Ubuntu glab **1.36.0** binary was extracted into temporary state and run in a network-disabled namespace with synthetic configuration. Syscall tracing showed:

| Command / configuration | Result | Connection/send attempts |
| --- | --- | ---: |
| Local config, exact mixed-case host and port | Matching host, exit 0 | 0 |
| Local config, wrong host casing | Empty output, exit 0 | 0 |
| Local config, unconfigured host | Empty output, exit 0 | 0 |
| Authentication probe control | Reported unreachable network | Greater than 0 |

The local per-host lookup follows the [glab config documentation](https://docs.gitlab.com/cli/config/get/). The isolated CLI experiment and production registry tests provide nonvisual proof; no client UI changed.

A second real-glab experiment used a synthetic token login without api_host and a loopback HTTP user fixture: the local config read was empty and the authentication fallback read the synthetic account. The production managed discovery service was also run with the real CLI: matching config selected GitLab after one local command; empty config and a separate API hostname/port both selected GitLab after the host-specific auth fallback against that fixture. This does not validate real credentials.

The original VPN/keyring-backed account, modern glab releases, macOS, Windows, iOS, Android and Electron desktop were not exercised here. Hosts without matching api_host retain main’s network-dependent authentication check. The offline improvement applies when the local value matches the remote host; it does not promise offline detection for separate API endpoints.

Review found token-login and separate-API-endpoint compatibility regressions. Both are fixed. Opus and Sol independently reviewed the full diff in three rounds; the final round found no code blockers and both reviewers passed all 63 tests. Reviewed/published head: [21e18ba60e](https://github.com/pingdotgg/t3code/commit/21e18ba60ebac6c60440b972ca35e4066eb73c2a). Latest-head CI is **blocked**: build/typecheck, lint, package tests and all eight server shards passed, but [CI attempt 2](https://github.com/pingdotgg/t3code/actions/runs/39227497361/attempts/2) repeats a failure in `WorkflowOpeningBlock.browser.test.tsx:103` (8047/8048 web tests pass). The unchanged web tree, shared client trees, lockfile and workflows match merged main exactly. A fresh test agent ran that browser suite alone: **3/3 passed**. Lazy highlighter/Suspense readiness exceeding the assertion’s one-second deadline is the likely cause; precise CI timing is unproven. No web code or checks were changed. This PR remains blocked until the web CI gate is resolved.

Models: GPT-6-Astra (tests), GPT-6.1-Sol (implementation), Claude Opus 5.5 and GPT-6-Sol (independent review). Harness: Codex and Claude through T3 Code.