[Bug]: Azure DevOps shown as "Not available on this server" on Windows even though `az` + `azure-devops` extension are installed

[johanndev]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. On Windows, install the Azure CLI and az extension add --name azure-devops.

2. Confirm az --version works from a terminal (exit code 0).

3. Open T3 Code -> Settings -> Source Control.

4. Observe the Azure DevOps card showing:

   Not available on this server: Install the Azure command-line tools (az), then enable Azure DevOps support with az extension add --name azure-devops.

Expected behavior

Azure DevOps is detected as available (and can report auth state via az account show), because az and the extension are installed.

Actual behavior

The provider is reported as missing, with the install hint, because the discovery version probe times out.

Root cause

apps/server/src/sourceControl/SourceControlProviderDiscovery.ts runs the version probe with a fixed 5-second timeout:

• apps/server/src/sourceControl/SourceControlProviderDiscovery.ts:170 — timeoutMs: 5_000 in probeCli (runs az --version)
• apps/server/src/sourceControl/AzureDevOpsSourceControlProvider.ts:45-50 — the Azure spec uses executable: "az", versionArgs: ["--version"], and the install hint shown above

When the probe errors (including ProcessTimeoutError), probeCli's Effect.catch at SourceControlProviderDiscovery.ts:189-199 marks the provider status: "missing", and the UI renders the install hint.

Measured on the reporter's machine (and reproducible):

command	elapsed
az --version (cold start)	~5.96s
az --version (warm)	~6.78s
gh --version (comparison)	~0.30s

The Azure CLI on Windows starts a fresh Python interpreter every invocation (plus telemetry/update checks), which reliably exceeds the 5s probe window. Other CLI providers (gh, glab) start in well under a second, so they are unaffected and the bug is specific to az on Windows. Note the same 5s timeout also applies to the auth probe (SourceControlProviderDiscovery.ts:247), so az account show is at risk of the same issue.

Suggested fix

• Increase the discovery probe timeout for az (or make it per-spec / longer, e.g. 15-30s), and/or
• Treat a timeout of the version probe differently from "command not found" — e.g. distinguish a spawn failure (binary genuinely missing) from a timeout (binary exists but is slow), and don't render the install hint on timeout.

Impact

Major degradation or frequent failure

Version or commit

0.0.32-nightly.20260804.999

Environment

Windows 11

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[kummerer94]

Can confirm this is happening on Windows. The reason is that Azure CLI is a Python project and initially loading the modules (especially if you have multiple additional azure cli modules installed) takes some time.

Timeout should be 10s or more.