[Bug]: Provider page stays on "Checking provider status" because server.getConfig blocks on editor discovery

[ignaciomontenegroc]

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. Start T3 Code Alpha 0.0.28 on Windows with the backend ready.
2. Use a normal Windows PATH containing multiple provider CLI and editor locations. My PATH had 53 entries.
3. Open the Providers page.
4. Observe that every provider remains on "Checking provider status" indefinitely, even after waiting for hours.
5. Inspect server.trace.ndjson and the provider cache files under %USERPROFILE%\.t3\caches.

Expected behavior

Provider statuses should render promptly and independently. Optional external-editor detection should not block server.getConfig. Failed or slow editor checks should be time-limited, cached, and returned as partial results without preventing provider cards from resolving.

Actual behavior

server.getConfig calls external editor discovery. In 0.0.28, approximately 20 possible editor commands are checked sequentially across the inherited PATH. On this machine the request took between roughly 15 and 99 seconds. The UI interrupted/cancelled the request after approximately 15 seconds, so the provider cards stayed in their loading state even though provider cache files were eventually updated.

This was isolated by locally changing the editor checks to run concurrently with a 3-second timeout per editor. After that change, the same server.getConfig RPC completed successfully in 3.158 seconds and the provider UI received completed statuses.

The completed provider cache states after the workaround were: Claude ready/authenticated (7 models), Codex ready/authenticated (6), OpenCode ready/authenticated (461), Cursor authenticated with a model-discovery warning (36), and Grok error due to the separately reported ACP issue.

Impact

Major degradation or frequent failure

Version or commit

T3 Code Alpha 0.0.28 (product version 0.0.28.0)

Environment

Windows 11 24H2 build 26100.8875, AMD64; T3 desktop 0.0.28 x64; Node.js 24.15.0; PowerShell 7.5.8; inherited PATH with 53 entries.

Logs or stack traces

Observed request path:
server.getConfig -> externalLauncher.resolveAvailableEditors() -> sequential editor command checks

Before local patch: approximately 15 to 99 seconds and frequently interrupted by the UI.
After concurrent checks with 3-second per-editor timeout: 3158.2986 ms, Exit Success.

Provider caches continued updating under:
%USERPROFILE%\.t3\caches

Relevant trace:
%USERPROFILE%\.t3\userdata\logs\server.trace.ndjson

Screenshots, recordings, or supporting files

No response

Workaround

I locally patched the unpacked 0.0.28 server bundle so editor checks run concurrently and each editor has a 3-second timeout. This made server.getConfig complete in about 3.16 seconds. This is not a suitable end-user workaround because an application update can overwrite the patched bundle.