Repository navigation
[Bug] Windows: Codex model discovery times out / empty models (cold start >10s) #2261
Description
Summary
On Windows, Codex model discovery via buzz-acp models (spawn adapter → ACP initialize → session/new) often takes ~15–25s cold. Shipped MODELS_TIMEOUT is 10s, so discovery fails or returns empty models even though the adapter eventually succeeds.
This breaks / degrades onboarding and agent config model pickers for Codex after a successful install.
Environment
- OS: Windows 11
- Runtime:
@agentclientprotocol/codex-acp(Node shim under nvm, e.g.~\.nvm\versions\node\...\bin\codex-acp.cmd) - Observed: full probe ~20s with absolute path under a longer timeout; times out at 10s with product timeout
Reproduction
- Install Codex /
codex-acpso discovery finds the runtime. - Open first-run onboarding (or agent defaults / model picker that calls
discover_agent_models/buzz-acp models). - Observe empty models, silent failure, or timeout-shaped errors while Codex is still cold-starting.
Direct probe (illustrative):
buzz-acp models --json --agent <path-to-codex-acp.cmd>
# cold: often ~20s on Windows; product budget is 10s
Expected
- Discovery waits long enough for a cold Codex ACP boot, or
- UI shows clear loading for a slow probe, then a clear timeout error with an easy Retry
- Prefer caching models after first success so every UI open is not a full cold spawn
Actual
- 10s timeout kills the probe mid-boot
- Models list empty / no useful error in some onboarding paths
- Re-probe always cold-starts Node + Codex App Server (no warm cache)
Root cause (split)
| Layer | Responsibility |
|---|---|
Upstream @agentclientprotocol/codex-acp + Codex App Server |
Real cold-start cost (stdio adapter boots Codex app server) |
Buzz MODELS_TIMEOUT (10s) + desktop discovery UX |
Timeout too short for Windows cold start; weak loading/error/retry |
Git Bash is not on the models spawn path (Command::new / absolute .cmd → node). Related but separate: Windows install/PATH (#2238).
Suggested Buzz fixes
- Raise
MODELS_TIMEOUT(e.g. 30–45s) or make it adaptive for slower adapters - UI: longer loading copy for Codex, clear timeout message, one-click Retry
- Cache successful model catalogs by runtime command + version
- Ensure Windows resolves
codex-acp.cmd/ nvm bin on child PATH (bare name often “program not found” when nvm4w ≠.nvm)
Related
- fix(desktop): surface model discovery failures in agent config UI #2246 — Surface model discovery failures in agent config UI (partial UX)
- Upstream adapter: https://github.com/agentclientprotocol/codex-acp (starts Codex App Server per process)
Activity
NedMalki-Chief commentedon Aug 9, 2026
Confirming this on Windows 11 with fresh measurements, and adding a data point that widens the scope: Claude Code is affected too, and worse than Codex.
Timing the real
buzz-acp models --jsonbinary, cold:codex-acp1.1.7codex-acp1.1.14claude-agent-acp0.66.0Two things that took a while to pin down and may save someone else the time:
It reads as intermittent because it is cache-dependent, not load-dependent. I saw
codex-acp1.1.7 return in 9s, then fail at 11-12s consistently after annpm installre-cold the file cache — same version, same machine, idle. Reducing machine load did not recover it. So "works sometimes" here is the 10s line being straddled, not a flaky adapter.Upgrading the adapter can make it worse. 1.1.7 → 1.1.14 moved Codex from marginally-passing to consistently-failing on this machine. Anyone debugging this by updating adapters may conclude the update broke things; it just pushed an already-marginal probe over the edge.
Also worth noting for the
models --jsonpath specifically: on Windows, npm installs an extensionless POSIX shell script next tocodex-acp.cmd, andCreateProcessmatches the extensionless file first, failing withprogram not found. Buzz's own resolver finds the.cmd, so this only bites paths that pass a bare name — but it produces a completely different error than the timeout and muddies diagnosis.I've opened #5379 implementing recommendation 1: default 10s → 45s plus a
BUZZ_ACP_MODELS_TIMEOUToverride following the existingBUZZ_ACP_IDLE_TIMEOUTconvention, with a fallback so a malformed override can't be a harder failure than no override. Verified both adapters now return their catalogs (14-19s and 29-31s respectively). Recommendations 2 and 3 from this issue (retry affordance, caching successful catalogs) are untouched and still worth doing separately.