[Bug][Windows] Slow live model discovery blocks proxy readiness and makes service start time out

[0disoft]

Client or integration

Codex App

Area

Service lifecycle

Summary

On Windows with the Task Scheduler service backend, slow or unavailable live provider-model discovery can block proxy readiness long enough for ocx service start to time out.

In this incident, both deepseek and google-antigravity had live model discovery enabled. Repeated service starts registered the scheduled job, but no process answered on port 10100 within the CLI's 20-second readiness window:

Service started, but no proxy answered on port 10100 within 20s.
The manager registered the job; that is not the same as serving.

The service log showed wrapper starts at 12:42:25 and 12:44:51 without a subsequent proxy running line. A third wrapper start at 12:47:50 eventually reached proxy running. Nearby starts logged model-discovery timeouts for both providers.

This looks like an optional catalog-refresh operation sitting on, or otherwise delaying, the critical startup/readiness path. A slow provider catalog should degrade to the configured or stale model list without making the entire local proxy unavailable.

The workaround was to disable live discovery for the two affected providers:

ocx provider edit deepseek --live-models off
ocx provider edit google-antigravity --live-models off

After that change, a full service stop/start reached serving state within the built-in startup deadline. The static configured catalogs remained available, /healthz was stable, and real Codex text and tool-call requests completed successfully through the proxy.

Expected behavior: OpenCodex should bind and become ready independently of optional provider model discovery. Discovery should run asynchronously or under a bounded per-provider timeout, with immediate fallback to cached/configured models.

Actual behavior: delayed provider discovery can keep the proxy unavailable past the service manager's 20-second readiness deadline, making Codex requests fail even though the scheduled service job was registered.

Reproduction

1. On Windows, install the Task Scheduler service backend and configure providers with live discovery enabled. In this case:

   • deepseek using the official API
   • google-antigravity using OAuth / Cloud Code Assist

2. Make the provider model-discovery endpoints slow or unreachable, or encounter a transient provider timeout.

3. Ensure the proxy is stopped.

4. Run:

   ocx service start

5. Observe that the command waits 20 seconds and reports:

   Service started, but no proxy answered on port 10100 within 20s.
   

6. Run ocx status; /healthz is unreachable and the service is registered but not serving.

7. Inspect ~/.opencodex/service.log. In the captured incident, multiple wrapper starts occurred before any proxy running line, with provider model-discovery timeout messages nearby.

8. Disable live discovery for the slow providers:

   ocx provider edit deepseek --live-models off
   ocx provider edit google-antigravity --live-models off

9. Stop and start the service again. Observe that it reaches serving state within the startup deadline.

10. Verify:

    ocx status
    curl http://127.0.0.1:10100/healthz

    The proxy is healthy, the configured static models remain present, and Codex requests route successfully.

This is not a request to remove live discovery. The desired behavior is failure isolation: provider catalog refresh should not gate local proxy availability.

Suggested regression coverage:

• A provider /models endpoint that never responds must not prevent /healthz from becoming available.
• Multiple slow live-discovery providers must not extend startup beyond the service readiness deadline.
• Startup should publish configured or stale models immediately, then refresh the catalog in the background.
• A discovery failure should be visible in diagnostics without classifying the whole service as not serving.

Version

@bitkyc08/opencodex 2.11.1

Operating system

Microsoft Windows 10.0.26200.8875, Task Scheduler service backend

Provider and model

Provider catalog discovery rather than inference-model specific: official DeepSeek API and Google Antigravity OAuth

Logs or error output

# CLI
$ ocx service start
Service started, but no proxy answered on port 10100 within 20s.
The manager registered the job; that is not the same as serving.

# status during the incident
Proxy: not running
Health: http://127.0.0.1:10100/healthz unreachable
Service: installed, Task Scheduler enabled — registered but NOT serving

# relevant service-log sequence
[2026-08-10 12:42:25.88] opencodex service wrapper start
bun_source="override"
# no "proxy running" line

[2026-08-10 12:44:51.49] opencodex service wrapper start
bun_source="override"
# no "proxy running" line

[2026-08-10 12:47:50.42] opencodex service wrapper start
bun_source="override"
🚀 opencodex proxy running on http://localhost:10100

# nearby provider-discovery failures from prior starts
[opencodex] Provider model discovery for "deepseek" threw TimeoutError [urlClass=provider-models, fallback=configured].
[opencodex] Provider model discovery for "google-antigravity" threw TimeoutError [urlClass=provider-models, fallback=configured].

# after disabling live discovery and performing a cold service restart
✅ opencodex service started and serving on port 10100.
{"status":"ok","service":"opencodex","version":"2.11.1","pid":31284,"port":10100,"restartCapability":"v1"}

# end-to-end Codex probes after recovery
ROUTE_OK
TOOL_ROUTE_OK

Screenshots and supporting files

No attachment. The relevant redacted timeline and command output are included above.

Redacted configuration

{
  "port": 10100,
  "defaultProvider": "openai",
  "providers": {
    "openai": {
      "adapter": "openai-responses",
      "authMode": "forward"
    },
    "deepseek": {
      "adapter": "openai-chat",
      "authMode": "key",
      "models": ["deepseek-chat", "deepseek-reasoner", "deepseek-v4-pro", "deepseek-v4-flash"],
      "liveModels": true
    },
    "google-antigravity": {
      "adapter": "google",
      "authMode": "oauth",
      "googleMode": "cloud-code-assist",
      "models": ["<configured static model ids>"],
      "liveModels": true
    }
  }
}

The verified workaround changes the final two liveModels values to false.

Checks

• I searched existing issues and documentation. The completed Feature: Provider model discovery control and empty provider visibility #310 covers exposing the liveModels control and empty-provider visibility, but not live discovery blocking service readiness.
• I removed secrets, tokens, account details, request credentials, and personal data.

Note: This report was prepared with AI assistance. The startup failures, service-log timeline, configuration workaround, cold restart, stable health checks, and end-to-end Codex text/tool probes were reproduced on the reporter's host.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}

[Ingwannu]

Thanks for the detailed timeline. The outage evidence is credible, but current dev does not yet support the proposed discovery cause.

startServer() binds the listener and prints proxy running before scheduleCatalogPrewarm() can start the asynchronous catalog gather. /healthz is intentionally live while the later Codex catalog sync is pending, and provider discovery itself has an 8-second per-request abort with stale/configured fallback. A wrapper start with no subsequent proxy running line therefore points to a boundary before the background discovery flight, or to a synchronous startup failure, rather than proving that /models discovery blocked readiness.

Disabling liveModels may still have changed timing, but it is not enough to identify the owner of the delay. Please provide one contiguous redacted service.log slice from a failed wrapper-start line through at least 30 seconds later, plus:

• whether the scheduled Bun process still existed during the 20-second probe;
• ocx status and the Task Scheduler last-result value from that same attempt;
• the result of one foreground ocx start with the same provider configuration;
• whether current 2.12.0 reproduces the same no-listener state.

Please keep timestamps and all startup diagnostics, while continuing to redact credentials and local account paths. I am marking this needs-info and leaving it open; if the process reaches proxy running but /healthz still cannot answer, that is a different and directly testable event-loop boundary.