What happened?
Cursor's provider health check consistently takes 11.6-12 s, occasionally stretching past 16 s, even though the Cursor CLI itself answers in under a second. When the second phase crosses its 15 s cap, the check degrades to warnings/errors like "Cursor ACP model discovery failed".
This happens with the correct binary resolved via an absolute path, so it is not the PATH collision from #3478. It looks like the same ACP layer struggling with recent Cursor CLI builds, consistent with #6533 hitting ACP trouble on the exact same build.
Environment
OS: Linux x86_64
T3 Code: 0.0.33 alpha (AppImage)
Cursor CLI: cursor-agent 2026.08.11-e8db854
binaryPath: absolute path to ~/.local/share/cursor-agent/versions/<v>/cursor-agent
Health check interval: default (300 s)
Manual comparison, run outside T3 Code:
$ time cursor-agent about ...
real 0m0.9s (exit 0, authenticated)
Timing distribution
Across dozens of distinct checkCursorProviderStatus traceIds in server.trace.ndjson, durations cluster tightly:
~11,580-11,900 ms (mode, most samples)
up to ~15,980 ms (occasional)
A fixed ceiling being approached repeatedly points at phase 2 of the check, not jitter.
What the code does
checkCursorProviderStatus runs two phases (apps/server/src/provider/Layers/CursorProvider.ts):
<binaryPath> about --format json with plain-about fallback, capped by ABOUT_TIMEOUT_MS = 8_000 (:580). Fast.- Full ACP session: spawn
<binaryPath> acp (:411-419), handshake, then acp.request("cursor/list_available_models", {}) (:561-562), capped by CURSOR_ACP_MODEL_DISCOVERY_TIMEOUT_MS = 15_000 (:62). This is where the ~10 s goes.
So each 5-minute cycle pays a fresh subprocess spawn plus JSON-RPC handshake just to re-read a model list that rarely changes. Observed ~11.7 s total = sub-second about probe plus ~10 s ACP round trip.
Expected behavior
Model discovery should not cost ~10 s per cycle against a CLI that responds in under a second standalone, and should not intermittently cross the cap into failure states.
Possible directions
- Cache the model list between cycles and refresh it less often than auth status.
- Keep one long-lived ACP session alive instead of spawning per check, the way the Codex provider keeps its
app-server process.
- If neither fits, at least raise the cap or log the per-phase split so users can tell which half timed out.
Related
What happened?
Cursor's provider health check consistently takes 11.6-12 s, occasionally stretching past 16 s, even though the Cursor CLI itself answers in under a second. When the second phase crosses its 15 s cap, the check degrades to warnings/errors like "Cursor ACP model discovery failed".
This happens with the correct binary resolved via an absolute path, so it is not the PATH collision from #3478. It looks like the same ACP layer struggling with recent Cursor CLI builds, consistent with #6533 hitting ACP trouble on the exact same build.
Environment
Manual comparison, run outside T3 Code:
Timing distribution
Across dozens of distinct
checkCursorProviderStatustraceIds in server.trace.ndjson, durations cluster tightly:A fixed ceiling being approached repeatedly points at phase 2 of the check, not jitter.
What the code does
checkCursorProviderStatusruns two phases (apps/server/src/provider/Layers/CursorProvider.ts):<binaryPath> about --format jsonwith plain-aboutfallback, capped byABOUT_TIMEOUT_MS = 8_000(:580). Fast.<binaryPath> acp(:411-419), handshake, thenacp.request("cursor/list_available_models", {})(:561-562), capped byCURSOR_ACP_MODEL_DISCOVERY_TIMEOUT_MS = 15_000(:62). This is where the ~10 s goes.So each 5-minute cycle pays a fresh subprocess spawn plus JSON-RPC handshake just to re-read a model list that rarely changes. Observed ~11.7 s total = sub-second about probe plus ~10 s ACP round trip.
Expected behavior
Model discovery should not cost ~10 s per cycle against a CLI that responds in under a second standalone, and should not intermittently cross the cap into failure states.
Possible directions
app-serverprocess.Related
agentPATH name (closed). Different root cause, same ACP error surface.