Remote-hub ocx connect always times out downloading a large catalog (hard-coded 5s, no override, ~18KB base_instructions per model) #3288

Environment

• opencodex 2.40.0 on both sides
• Hub: macOS, role=hub, catalog = 416 models ≈ 8.4 MB serialized (each entry carries a full base_instructions block of ~18KB)
• Client: macOS on another continent, direct tailnet link ~1.4 MB/s (healthy link, 18ms RTT, direct per tailscale status)

What happens

$ ocx connect <data-plane-url> --management-url <https-origin> --admin-token-stdin
Error: The operation timed out.

downloadClientCatalog() in src/client/connect.ts uses DEFAULT_TIMEOUT_MS = 5_000 (src/client/hub-client.ts) with no CLI flag or env override. The hub serves the same catalog locally in 0.15 s; over a ~1.4 MB/s link the 8.4 MB body needs ~6 s — past the cap, so connect deterministically fails and rolls back (clean rollback, to be fair).

Workaround we used

Shrank the catalog below the budget: disabled liveModels on two aggregator providers (416 → 90 models, 8.4 MB → 1.9 MB, ~1.4 s transfer) and connect succeeded immediately.

Suggestions

1. Expose the client fetch timeout (flag or env) so slow links / large catalogs can be accommodated.
2. Consider serving GET /v1/catalog gzipped — the JSON is highly compressible and this would also shrink the footprint for every client.
3. Consider documenting a catalog-size budget for remote clients, or warning on ocx sync when the persisted catalog exceeds it.

Related context: each routed model inheriting the full base_instructions template is what makes the per-entry cost ~18 KB; if that block were deduplicated or omitted for routed entries on the download path, catalogs would shrink by ~90%.