Stack/gui dense workspaces - #804
Conversation
Persist a default-OFF archived cleanup policy, evaluate it on startup/schedule/manual runs via Phase 2 helpers, and surface controls on the Storage page.
Keep live config synced after background policy runs, execute exact reduceToBytes candidate sets, preserve nextRun on unchanged schedules, and harden the Storage policy UI against invalid drafts and raw errors.
Reject cleared thresholds, fail closed on malformed targets, tear down scheduler on shutdown, and defer startup policy off the microtask queue.
Move archive scan/FS/SQLite cleanup into a Bun Worker behind a single-flight job controller so POST /run returns immediately and /healthz stays responsive.
Replace the 100-file FS fixture with synthetic over-select math plus a small exact-path check, and raise timeouts on concurrent satellite restore cases that measure multi-second on Windows runners.
…tion Reload persisted policy before saving lastRun/nextRun so concurrent PUTs during a long worker run are not silently reverted.
Abort/reset now cancel the active worker promise and generation-guard late completions; GUI distinguishes already_running, aborts poll on unmount, and test-stream returns 404 when disabled.
…-policy feat(storage): opt-in auto-cleanup policy (phase 3, lidge-jun#42)
…idge-jun#491) * fix(oauth): stop OAuth login from deleting a stored provider API key `upsertOAuthProvider` replaced the provider entry with the bare preset on every OAuth login. For providers that can be billed either way (`allowKeyAuthOverride`: xai, github-copilot) this deleted `apiKey` and `apiKeyPool` from config.json and silently flipped an explicit `authMode: "key"` billing choice back to the subscription — the key was gone and had to be pasted again. Carry the key fields over and keep an explicitly chosen `authMode: "key"`, so logging in never changes which credential bills the request. OAuth-only providers and fresh logins still get the untouched preset. * fix(oauth): restore OAuth mode after final key removal * fix(oauth): promote safe pool key and keep key mode when authMode is omitted Address review follow-ups so OAuth login preserves key billing when a usable key remains, including pool promotion and shared API-key sanitization. * fix(oauth): sync active key into pool and gate key mode on resolved env Keep list/switch/remove aligned with routing after OAuth upsert, and only restore authMode key when resolveEnvValue yields a usable secret. * fix(oauth): push merged provider config to running proxy after CLI login Avoid POST /api/providers with the bare OAuth preset, which dropped preserved apiKey/authMode and wrote that stripped state back to disk. * fix(oauth): persist key intent without CLI env and route env keys at runtime Stop upsertOAuthProvider from gating authMode on resolveEnvValue in the login CLI; router falls back to OAuth when the proxy cannot resolve an env-backed active key without rewriting stored mode. --------- Co-authored-by: wonsh42 <wonsh42@users.noreply.github.com> Co-authored-by: wonsh42 <300028278+wonsh42@users.noreply.github.com> Co-authored-by: Wibias <37517432+Wibias@users.noreply.github.com>
The .codexclaw/ goalplans and ledgers are per-machine agent state. They were committed with 'git add -f' despite the ignore rule, and once tracked the rule stopped applying, so they rode along into main and preview. Untrack them (files stay on disk), drop two .DS_Store files that got in the same way, and add tests/repo-hygiene.test.ts so a forced add fails CI instead of landing silently. Also drop a registry.ts comment pointing at a .codexclaw evidence file that was never committed and cannot be resolved by any reader.
* feat(cli): add `ocx opencode` launcher
opencode reads providers from a JSON config rather than env slots, so the
`ocx claude` env-injection pattern does not transfer. This adds a launcher that
generates a provider block from the proxy's visible catalog and points
OPENCODE_CONFIG at it.
The user's own opencode.json is never written to. Their effective config is read
(explicit OPENCODE_CONFIG first, then the XDG global path), merged forward into
a generated copy under the opencodex config dir, and only the `opencodex`
provider key is overwritten. Carrying the base config forward keeps the command
correct whether opencode merges the OPENCODE_CONFIG layer or replaces it, and
leaves plain `opencode` completely unchanged.
Credential handling: the generated file is written to disk and outlives the
child, so it carries opencode's documented `{env:VAR}` reference instead of the
admission key, and the real value is passed only through the child environment.
The key resolves OPENCODEX_API_AUTH_TOKEN before config.apiKeys, matching
fetchClaudeContextWindows — a non-loopback bind requires the env token and may
have no apiKeys at all, where a placeholder would 401 every request.
Model limits: limit.context is emitted only from an authoritative context
window, including native slugs via nativeOpenAiContextWindow. opencode's schema
rejects a limit block carrying context without output and CatalogModel has no
authoritative output field, so a documented budget rides along, clamped to the
context window so a small-context model is never emitted with output > context.
Robustness: opencode.json is parsed as JSONC (strict JSON first, tolerant only
on failure) because opencode documents that syntax and a commented config would
otherwise be rejected as malformed; the generated file is written atomically so
a concurrent launch cannot read a torn file; the detached proxy-start child gets
an error listener so a failed spawn reports through the health poll instead of
throwing; and a project-level opencode.json defining provider.opencodex is
detected and warned about, since opencode loads that layer last and it outranks
the generated block.
Verified against a live proxy: 76 models registered, 47 carrying authoritative
limits with no output > context violations, `opencode models opencodex` lists
all of them, and an end-to-end run through opencodex/kiro/claude-haiku-4.5
returns a completion.
* fix(cli): harden ocx opencode launcher review follow-ups
Merge inherited OPENCODE_CONFIG_CONTENT instead of replacing it, probe the
live proxy hostname for baseURL, resolve admission from env/service token/
config keys, add x-opencodex-api-key on non-loopback binds, omit native slugs
in Codex Direct mode, and widen global override detection. Stabilize the
Windows storage-policy concurrency test timing.
* fix(cli): pass service token file to ocx opencode auto-start
When ocx opencode spawns a detached ocx start and OPENCODEX_API_AUTH_TOKEN
is absent, propagate OCX_API_TOKEN_FILE (or the default hardened path) so
handleStart can load the service token before a non-loopback bind.
* fix(cli): address CodeRabbit opencode review follow-ups
Use a deterministic loopback default config in provider-block helpers instead
of loadConfig(), send proxy admission via apiKey on loopback and only
x-opencodex-api-key on non-loopback binds, and split the docs/help examples
accordingly.
* fix(cli): build ocx opencode catalog from proxy /api/models
Fetch the live model list from the running proxy instead of calling fetchAllModels in the CLI process, so env-backed provider keys resolve in the proxy environment and namespaced selectors carry display metadata.
* fix(cli): bound ocx opencode /api/models fetch deadline
Abort stalled proxy catalog requests after 8s so ocx opencode fails fast instead of hanging before OpenCode launches.
---------
Co-authored-by: mihneaptu <223163739+mihneaptu@users.noreply.github.com>
…dge-jun#42) (lidge-jun#558) * feat(storage): restore quarantined archived sessions (phase 2.1 of lidge-jun#42) Add trash list/restore APIs, Storage GUI quarantine panel, and round-trip tests so default cleanup can be undone without Phase 3 purge. * fix(storage): address PR lidge-jun#558 restore review and GUI loading races Keep satellite backups for quarantine restore, snapshot full thread rows and state dependents, remap satellite DB paths, and make satellite failures retryable. Drop duplicate trash probing so Storage abort/generation ownership stays correct. * fix(storage): harden restore moves and Windows lock-test timeouts Use link+unlink no-replace for trash restore so a raced dest cannot be overwritten, and raise timeouts for multi-satellite cleanup tests that overrun 5s on Windows CI. * fix(storage): atomic trash parse and legacy thread restore Reject malformed manifests wholesale, gate stage deletion on restore completeness, and reconstruct production thread rows from rollout session_meta when satellite snapshots are missing. * fix(storage): release memories lock before post-image backup write Holding BEGIN IMMEDIATE across writeFileSync let Windows CI disk/AV latency stall the watermark concurrent-restore test past bun's 5s default. Persist consolidatePostImage after COMMIT and raise the two concurrent restore test budgets to match the other multi-satellite cases. * fix(storage): compensate restore metadata on late failure Restage files then delete rows this restore committed so satellite/leftover failures leave a clean retryable trash entry. * fix(storage): enforce restore compensation success and preserve pre-existing rows Track exact conflict-ignored inserts, require compensating DB txs to commit before restaging, and leave accurate partial counts when compensation is busy. * fix(storage): resume incomplete restore instead of non-atomic compensation Late failures after file moves now persist restore-pending.json and keep restored files in place, so retries accept destinations and finish only missing metadata without deleting rows before a guaranteed restage. * fix(storage): write restore-pending atomically before file moves Persist the resume marker with stage-local temp+fsync+rename before any rollout leaves quarantine, distinguish missing/valid/invalid markers, and fail closed when a resume still owes satellite work but satellite-backup.json is gone. * fix(storage): keep placed dests on mid-move restore failure Once restore-pending is durable, a later rename failure must not reverse successful moves or drop the planned acceptedDestRels marker so resume can finish staged files. * fix(storage): close PR lidge-jun#558 restore blockers (fail-closed resume, tombstone finalize, worker job) Fail closed per owed satellite section on resume, finalize successful restores via non-listable tombstone rename, and run restoreTrashEntry in a serialized Bun Worker so the event loop stays responsive. * fix(storage): serialize cleanup and restore via shared mutation gate Route manual cleanup and trash restore through one per-CODEX_HOME coordinator that returns 409 storage_mutation_busy instead of queuing. Stub runPolicyStorageMutation for Phase 3 policy worker integration. * fix(storage): export policy overlap guard for pending restore * fix(storage): surface restore worker failures and gate test-stream route Map worker rejections to distinct restore error codes end-to-end (API, GUI, i18n) instead of generic restore_failed, and register the restore test-stream endpoint only when OPENCODEX_CLEANUP_TEST_HOOKS=1. * fix(storage): drop broken pending-overlap hooks from cleanup preview Keep only restore worker error types in cleanup.ts; remove calls to undefined pending-restore guard helpers introduced in the prior commit. * fix(storage): guard cleanup against pending restore overlap Reject cleanup when selected archives overlap acceptedDestRels from valid restore-pending markers, fail closed on unfinished satellite sections, and address tip CodeRabbit nits (healthz flake, preview status). * fix(tests): stabilize Windows CI storage policy and rollback cases Raise injected satellite rollback test timeout for slow Windows SQLite reconcile, and delay concurrent policy PUT until the worker has loaded the enabled snapshot inside holdAfterLoadMs. * fix(storage): hold policy mutation slot in parent and backfill pending-safe selection Acquire the shared CODEX_HOME mutation slot in the policy job controller before spawning the worker and release it on success, failure, timeout, and abort. Pending-restore destinations no longer consume percent or reduceToBytes selection budget; cleanup backfills with the next oldest safe archives. Adds API regressions for policy, restore, and manual cleanup contention in both orderings. * fix(storage): clear policy-job inflight after busy-path settle The request handler assignment overwrote executeJob's inflight=null on mutation-busy returns, leaving a settled Promise latched forever. Clear inflight in a finally on the assigned job promise instead.
Based on the original report and patch from @Aciredy. Removes Cursor user/developer prompt mutation for shell-alias hints (guidance stays in the system note) and rejects empty/invalid shell_command and exec_command payloads before they reach the bridge. Co-authored-by: Aciredy <254986922+Aciredy@users.noreply.github.com>
isLoopbackRequestHost() required the Host header's port to equal the proxy's own port, so a proxy reached through `ssh -L 20100:localhost:10100` arrived as `Host: localhost:20100` and was refused. That gate sits in front of the whole data plane — /v1/models, /v1/responses, /v1/messages, /v1/chat/completions, /v1/live and the Responses WebSocket upgrade — not just CORS, and it fires with no Origin header at all, so Codex CLI, Claude Code and curl all saw a proxy that looked completely dead rather than one with a CORS problem. Loopback is a trust boundary by hostname, not by port. The sibling isLoopbackOriginValue() dropped its own port check for exactly this reason in e4e0612. Port equality was never the rebinding defense either: a rebinding browser connects to the real port and sends it verbatim, so the hostname check is what rejected it before and still does. Verified against 40 Host forms — localhost.attacker.com, 127.0.0.1.nip.io, localtest.me, 0.0.0.0, 127.0.0.2, [::ffff:127.0.0.1] and a Cyrillic homograph all stay refused. Also accepts the FQDN form `localhost.`, which curl sends verbatim and which was refused for the same class of reason. The predicate had no test coverage at all. The new file pins both directions, including a characterization test for the pre-existing fail-open on an unparseable Host so tightening it later needs a deliberate failing test. Docs: forwarding is now documented, with the caveats that a forwarded loopback is unauthenticated (ssh -g / container publishing expose it), that the client base URL must be set by hand, and that provider OAuth login needs its own forward.
…store (lidge-jun#571) * fix(storage): harden lidge-jun#558 satellite backup writes and zst restore Make every satellite-backup.json update crash-safe (tmp + fsync + rename + best-effort dir fsync) so a failed post-memories rewrite cannot truncate the last valid snapshot. Restore legacy compressed-only quarantine entries by decompressing a lone .jsonl.zst in memory and reconstructing the thread row. * fix(storage): harden satellite-backup write retries for lidge-jun#558 follow-up Loop short writes to completion and rename via renameAtomicFile so Windows sharing violations cannot replace a durable temp with a truncated backup.
) * test(storage): cover restore test-stream route gate cases Address CodeRabbit on lidge-jun#571: assert JSON 404 when the stream hook is null under OPENCODEX_CLEANUP_TEST_HOOKS=1, and that the enabled stream path returns the text/plain chunked response. * test(storage): isolate restore test-stream route env and hooks Reset OPENCODEX_CLEANUP_TEST_HOOKS and restore-job hooks in a nested finally so enableTestStream cannot leak across cases in the responsive suite.
…idge-jun#493) Anthropic OAuth usage is per credential: probe each logged-in account for 5h/weekly bars, use canonical fiveHour fields, and refresh overview quotas after active-account switches. Maintainer takeover on latest dev with CodeRabbit/Codex/Wibias review harden (unavailable+TTL, local-cli fail-closed, health rebuild, probe sharing, GUI/docs, cache/inflight/login invalidation, async account-list load). Credit: @wonsh42 (original feature). Co-authored-by: wonsh42 <wonsh42@users.noreply.github.com>
Co-authored-by: wonsh42 <wonsh42@users.noreply.github.com>
Make Kiro Add-account run a transactional kiro-cli browser login with durable session recovery, account-scoped routing metadata, and generation-safe refresh. Co-authored-by: coseung2 <120152615+coseung2@users.noreply.github.com>
Gemini chat image models emit authenticated opaque artifact URLs via responseModalities, with CCA Images fallback hardening and focused regressions. Maintainer takeover on latest dev with CodeRabbit/Codex/Wibias review harden (admission bearer CCA path, n=1 + RECITATION, base64/magic validation, explicit allowlists, artifact HTTP route, size caps). Credit: @tizerluo (original feature). Co-authored-by: tizerluo <192086140+tizerluo@users.noreply.github.com>
lidge-jun#577) Credit: @tizerluo for the original feature on lidge-jun#424. Folds stacked lidge-jun#528 hardening and maintainer review/security follow-ups. Reconciled with lidge-jun#355 artifact helpers on latest dev. Closes lidge-jun#424 Closes lidge-jun#528
…dge-jun#578) * feat(anthropic): opt-in Claude OAuth account pool (lidge-jun#294) Add experimental, default-off routing across stored Anthropic OAuth accounts: sticky session affinity, 429 cooldown failover, and new-session lowest 5h-usage pick. Includes GUI toggle with an explicit not-battle-tested warning, management API, docs, and focused regressions. * fix(anthropic): address pool review feedback for lidge-jun#294 Return 429 when all accounts are cooling, bound per-request failover, skip unsafe local-cli refresh, and keep affinity/GUI/docs aligned with the reliability contract.
…#579) * fix(release): baseline preview notes on last prior release Preview generate-notes was channel-isolated (preview to preview only), so cutting 2.7.43-preview after a stable 2.7.42 with no matching preview restated the stable changelog. Preview baselines now use the newest prior stable or preview tag; stable still baselines prior stable and carries matching preview notes. * fix(release): SemVer-order prior tags for notes baseline Exclude tags newer than the target and rank stable after matching previews so generate-notes does not pick the wrong previous release.
…back-gate fix(server): treat forwarded loopback ports as loopback
…dge-jun#563) (lidge-jun#580) * feat(dashboard): drain-and-restart from memory observability card Expose a longer 60s informed recycle on the memory card (POST /api/system/restart) that reuses drainAndShutdown and respawns via ensure/service without Codex teardown (lidge-jun#563). * fix(dashboard): harden drain-and-restart respawn and exit cleanup Address Codex review: use failure-exit for supervised service children, spawn start with the live port (not ensure), suppress injection teardown on recycle, and clear the GUI draining state on pid change. * fix(dashboard): arm drain immediately and harden reconnect polling Set draining before the 200ms flush delay, bound reconnect /healthz polls, announce restart status to assistive tech, and clarify docs around active-turn drain timeout abort.
…un#584) (lidge-jun#585) * fix(codex): same-request pool failover on pre-stream 429/402 Retry exhausted primary accounts once on an eligible alternate within the same turn, and rebind over-threshold sticky threads immediately so Codex CLI does not stall when a secondary still has quota (lidge-jun#584). * fix(codex): attribute pool-retry transport failures to alternate account Also classify HTTP 402 as quota so same-request failover cools the depleted account consistently with 429. * fix(codex): keep subagent quota health scoped to the retried account After a successful same-request pool failover, update subagentFallbackAccountId so streamed terminal 429s attribute health to the account that actually served.
… follow-up) (lidge-jun#594) * fix(server): exit cleanly when drain-and-restart spawn fails Follow-up to lidge-jun#580: wait for detached start spawn success, and on sync throw or pre-start error exit(1) without markRecycling so we never leave a drained process latched or exit(0) with no replacement. * fix(server): sanitize restart spawn errors and restore fences Address Codex review on lidge-jun#594: log only errno codes (no pathful messages), and clear inherited OCX_SERVICE on spawn failure so ensure/tray daemons still run syncCleanup restore.
* chore(gui): restore React Doctor 100 and gate CI on findings Clear the post-cleanup regressions, pin react-doctor 0.9.2, and fail CI/prepush on any doctor finding so the score cannot silently drift again. * fix(gui): address CI/Codex follow-ups for React Doctor gate Keep Response-like test doubles working, preserve Grok/message error text, honor reconnect deadlines on non-OK healthz, and soft-skip offline npx/registry failures without letting real findings through. * fix(gui): address CodeRabbit follow-ups on doctor gate PR Extract boundedSignal, serialize Claude Desktop status polls, keep storage percent as a draft string, map trash list errors through i18n, and tighten React Doctor workflow assertions to active YAML. * fix(gui): tighten doctor offline classifier and Grok apply errors Make apply failures keep server message text, cover the fetch-json fallback path, and only soft-skip prepush on concrete registry/network signatures so findings with words like network still gate. * fix(gui): bound polls and harden doctor prepush gate Restore manual timeout fallbacks via shared createBoundedFetch, raise doctor maxBuffer and fail on ENOBUFS, recognize ECONNRESET registry failures, and tighten action SHA pinning assertions. * fix(gui): match nonterminal npm ERR! soft-skip signatures Give npm ERR! its own alternative so trailing whitespace after the bang still counts as an offline/registry failure instead of gating the push. * fix(gui): treat stdio maxBuffer overflows as doctor gate failures Also recognize Node's ERR_CHILD_PROCESS_STDIO_MAXBUFFER so oversized doctor output cannot soft-skip the prepush findings gate. * fix(gui): run React Doctor via spawnSync with explicit maxBuffer Replace execFileSync so prepush classification uses spawnSync status/error channels and cannot soft-skip oversized doctor output. * test(gui): cover bounded fetch and doctor maxBuffer hard-fail Add regression tests CodeRabbit asked for, and check AbortSignal helpers with typeof so the manual timeout fallback actually runs when any/timeout are missing.
…idge-jun#600) Stop accepting bug reports that only fill Summary — empty or ellipsis-only Reproduction must fail the issue-quality gate (lidge-jun#598).
…idge-jun#597) * feat(kimi): forward prompt_cache_key on the Kimi Coding Plan presets Kimi's Chat Completions API documents prompt_cache_key as required for Kimi Code Plan cache hits (a stable session/task id, unchanged across exit and resume). Opt the canonical `kimi` OAuth and `kimi-code` API-key presets into the existing openai-chat forwarding flag so the caller-supplied key reaches https://api.kimi.com/coding/v1. The adapter never invents a key: it forwards what the internal request already carries (Codex's session key on /v1/responses, or the session-scoped key the Claude /v1/messages inbound derives), an absent field stays absent, and an explicit provider-level `promptCacheKey: false` still opts out. All other OpenAI-compatible presets remain deny-by-default because strict backends reject the OpenAI-specific field. Also persist the flag through providerConfigSeed / enrichProviderFromRegistry like the sibling scalars (parallelToolCalls, modelSuffixBracketStrip): key-pool 429 rotation rebuilds the provider from the persisted config rather than the routed one, so without seeding the retried request would silently drop the key on exactly the quota-sensitive turns that need affinity most. Evidence: https://platform.kimi.com/docs/api/chat Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Preserve Kimi prompt cache key on failover * fix(server): inherit routed provider config across 429 key rotation Generalize the promptCacheKey preservation from the previous commit: the narrow registry backfill in rotateProviderTransportOn429 covered only that one scalar, while every OTHER registry backfill routedProviderConfig merges at request time was still lost when the four 429-failover sites in src/server/responses/core.ts assigned the persisted-config snapshot to route.provider wholesale. Concretely: kimi-code's noTemperatureModels / modelReasoningEfforts / modelSuffixBracketStrip merges, NVIDIA NIM's parallelToolCalls: false, and a registry-pinned baseUrl all silently reverted on the rotated retry and later continuations in the turn. rotateProviderTransportOn429 now takes the request's routed provider and swaps ONLY the API key onto it before re-applying transport metadata, mirroring the OAuth-401 replay path (which already spreads route.provider). The registry lookup becomes unnecessary and is removed. Other failover paths were audited and are sound: Codex multi-account retry strips runtime fields off route.provider, and the Anthropic account pool spreads route.provider directly. Regression coverage: the existing Kimi unit test keeps asserting the wire body on both attempts; a new unit test proves arbitrary registry-backfilled fields survive rotation; a new e2e test on the kimi-code preset asserts prompt_cache_key is present on BOTH the initial attempt and the post-rotation retry (verified to fail against the pre-fix behavior). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
MiniMax-M3 accepts video, and the jawcode source now says so (jawcode 762549f),
so widen the generator's input-modality type and the type it emits from
("text" | "image")[] to ("text" | "image" | "video")[].
Type-only. RawModel.input is consumed via input.join(","), the row field is
string | null, and rowToMetadata casts unchecked — so tsc passes either way.
This keeps the declared type honest rather than fixing a compile error.
src/generated/jawcode-model-metadata.ts is deliberately NOT regenerated here.
That file is already 95 models / 63 price rows out of sync with its source, so a
regeneration would sweep unrelated price changes into cost accounting alongside
one modality fix. The resync is its own unit of work, with the delta reviewed on
its own merits and a drift guard added; the M3 video row lands there as a clean
one-row delta.
Reported as lidge-jun#706, which proposed the same type widening but hand-edited the
generated file and also swapped MiniMax's discounted rates for list prices.
…rift guard The committed generated file had drifted 95 models from its source — 148 price fields, 45 maxTokens, 36 context windows, 36 new models — because nothing ever checked it. That made any regeneration a blind bulk change, so this lands the resync with each class of delta accounted for. Price movements, classified rather than trusted: - x1.1 exactly on the amazon-bedrock `eu.*` rows — the AWS EU regional premium (1 -> 1.1, 5 -> 5.5, 25 -> 27.5), plus one row moving the other way. - ~x1.0-1.3 across ~40 openrouter rows; that bundle tracks live marketplace pricing, so drift there is the expected steady state. - The two outliers are aliases, not repricing: `gemini-flash-latest` (x5) and `gemini-flash-lite-latest` (x2.5) were repointed from 2.5-flash to 3.5-flash. Confirmed the new values are byte-identical to the `gemini-3.5-flash` row, which is what a `-latest` alias is supposed to do. MiniMax-M3 picks up `video` here as the clean one-row delta it was always meant to be (jawcode `762549f`), with its cost row untouched. **`hy3-preview` is re-blocked, and this is the important part.** Upstream re-added `tencent/hy3-preview`, so the regeneration resurrected `opencode-go/hy3-preview` — the model from lidge-jun#82 that returns `Provider error 400 … model_not_supported` because it is not on the Zen Go lite list. lidge-jun#82 was only ever "fixed" by upstream absence; there was no filter. There is one now (`EXCLUDED_MODELS`), so a future re-add cannot hand users that 400 again. `hy3` itself stays selectable. Two stale expectations updated with their reasons: - `claude-opus-5` now has a real `anthropic` jawcode row at the *same* 5/25/0.5/6.25 the maintainer derived, so its provenance moved `expected/verified-derived` -> `jawcode/verified` for that provider only. cursor and kiro still resolve through the overlay, so the overlay stays. - `opencode-go` contexts follow upstream: `qwen3.5-plus` to 1M, `minimax-m3` down to the 512K tier that matches MiniMax's own ≤512K band. The new guard regenerates into a temp file and byte-compares, so it cannot clobber the committed output. It skips when the jawcode checkout is absent — the generator throws without it, so asserting unconditionally would redden every contributor and CI run, and drift can only be introduced by someone who has the source anyway. Verified both directions: passes in sync, fails on a one-field perturbation. (`JAWCODE_METADATA_OUT` exists to make that safe.) Gates: tsc clean; sync-guard + codex-catalog + usage-cost + parity + slug-codec + minimax-reasoning-split 203 pass / 1 skip / 0 fail; privacy scan passed.
…e-jun#732) seedHome() writes real files and a sqlite fixture per case. On a slow windows-latest runner those cases take 6-8s against bun's 5s default and fail deterministically (run 30507689929 failed the same five twice, the second time after a --failed rerun) while a faster runner passes the identical code — locally the file is 22 pass in ~100ms. The sibling storage-cleanup suite already carries { timeout: 20_000 } / { timeout: 30_000 } on its seeding-heavy cases with a comment naming the same cause. This file had no budget at all, so one file-level setDefaultTimeout(30_000) covers all fifteen seedHome sites. setDefaultTimeout is the existing convention here (grok-management-api, codex-history-provider, claude-management-api, server-combo-failover-e2e, subagent-fallback-handle-responses all use 30_000). Test-harness only: no src/storage change, since nothing indicates the selection logic is wrong. Closes lidge-jun#727
The full suite failed a different number of tests on each run of an
identical tree — 9 one run, 2 the next — with server-auth's pool-retry
cases the most frequent victims. Pushing was the real casualty: prepush
runs the whole suite, so a random subset of pushes was rejected.
server-auth.test.ts and management-provider-validation.test.ts both
declared TEST_DIR as join(import.meta.dir, .tmp-server-auth-test) — the
same literal — and both delete and recreate it while pointing
OPENCODEX_HOME there. The 665b65643 split copied the path when it moved
those cases into their own file.
bun test v1.3.14 (0d9b296a)
🚀 opencodex proxy running on http://localhost:64074
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64078
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64083
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64085
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64139
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64142
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64188
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64192
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64196
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64200
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64204
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64208
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
[opencodex] OAuth refresh started provider=kimi account=account-…5fda
[opencodex] OAuth refresh joined existing operation provider=kimi account=account-…5fda
[opencodex] OAuth refresh joined existing operation provider=kimi account=account-…5fda
[opencodex] OAuth refresh joined existing operation provider=kimi account=account-…5fda
[opencodex] OAuth refresh joined existing operation provider=kimi account=account-…5fda
[opencodex] OAuth refresh joined existing operation provider=kimi account=account-…5fda
[opencodex] OAuth refresh joined existing operation provider=kimi account=account-…5fda
[opencodex] OAuth refresh joined existing operation provider=kimi account=account-…5fda
[opencodex] OAuth refresh joined existing operation provider=kimi account=account-…5fda
[opencodex] OAuth refresh joined existing operation provider=kimi account=account-…5fda
[opencodex] OAuth credentials rotated and persisted provider=kimi account=account-…5fda
[opencodex] OAuth refresh started provider=kimi account=account-…5fda
[opencodex] OAuth refresh started provider=kimi account=account-…5fda
[opencodex] OAuth credentials rotated and persisted provider=kimi account=account-…5fda
[opencodex] OAuth refresh started provider=kimi account=account-…5fda
[opencodex] OAuth refresh started provider=kimi account=account-…5fda
[opencodex] OAuth refresh started provider=kimi account=account-…5fda
[opencodex] OAuth refresh started provider=kimi account=account-…5fda
[opencodex] OAuth refresh started provider=kimi account=account-…5fda
[opencodex] OAuth refresh joined existing operation provider=kimi account=account-…5fda
🚀 opencodex proxy running on http://localhost:64289
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64293
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
[storage-policy] skip under_threshold
[storage-policy] ok mode=quarantine removed=1 freedBytes=100
[storage-policy] ok mode=permanent removed=1 freedBytes=100
[storage-policy] defer codex_busy
[storage-policy] ok mode=quarantine removed=1 freedBytes=100
[storage-policy] ok mode=quarantine removed=2 freedBytes=200
[storage-policy] ok mode=quarantine removed=1 freedBytes=100
🚀 opencodex proxy running on http://localhost:64348
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64350
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64352
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64356
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64358
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64360
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64362
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64364
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64366
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64367
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64369
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64371
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64373
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64375
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64377
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64383
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64440
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64443
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64445
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64448
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64450
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64452
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64454
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
[opencodex] OAuth refresh started provider=kimi account=account-…7da3
[opencodex] OAuth credentials rotated and persisted provider=kimi account=account-…7da3
[opencodex] OAuth refresh started provider=kimi account=account-…7da3
🚀 opencodex proxy running on http://localhost:64527
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64529
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64531
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64533
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64535
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64537
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64539
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64541
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64546
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64548
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64614
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64616
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64618
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64620
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64628
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64630
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64632
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64641
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64646
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64655
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64659
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64661
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64664
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64669
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64674
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64678
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64680
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64683
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64763
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64774
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
[opencodex] combo default effort omitted {
provider: "a",
model: "m1",
requestedEffort: "high",
capability: "unsupported",
}
[opencodex] combo default effort omitted {
provider: "b",
model: "m2",
requestedEffort: "high",
capability: "unsupported",
}
🚀 opencodex proxy running on http://localhost:64914
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64916
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
[opencodex] OAuth refresh started provider=kiro account=account-…1fb5
[opencodex] OAuth credentials rotated and persisted provider=kiro account=account-…1fb5
🚀 opencodex proxy running on http://localhost:64918
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64920
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
[opencodex] OAuth refresh started provider=kiro account=account-…1fb5
[opencodex] OAuth credentials rotated and persisted provider=kiro account=account-…1fb5
🚀 opencodex proxy running on http://localhost:64922
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
[opencodex] OAuth refresh started provider=kiro account=account-…1fb5
[opencodex] OAuth credentials rotated and persisted provider=kiro account=account-…1fb5
[opencodex] multi-agent guidance excluded: hidden-model:picker_hidden, v1-model:surface_incompatible, missing-model:missing_catalog_entry, displaced-model:outside_display_limit
🚀 opencodex proxy running on http://localhost:64927
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64932
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64938
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64993
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64996
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:64998
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65000
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65002
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65004
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65019
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65021
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65023
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65025
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65027
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65029
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65031
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65033
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65035
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65038
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65042
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65045
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65048
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65053
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65059
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65062
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65065
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65068
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65071
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65073
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65076
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65079
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65082
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65084
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65087
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65093
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65099
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65105
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65110
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65115
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65120
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65125
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65130
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65135
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65140
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65145
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65150
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65155
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65160
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65165
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65231
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65236
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65241
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65246
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65251
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65256
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65261
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65266
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65271
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65276
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65281
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65286
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65291
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65296
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65301
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65306
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65311
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65316
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65321
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65326
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65331
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65333
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65337
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65341
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65346
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65350
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65353
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65358
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65363
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65368
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65373
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65378
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65383
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65389
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65395
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65401
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65403
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65405
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65408
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65413
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65418
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65423
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65427
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65429
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65431
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65433
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65435
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65437
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65439
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65441
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65443
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65445
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65447
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65449
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65479
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65481
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65483
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65485
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:65487
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
mock/test-model 모델을 haiku 그룹으로 옮겼습니다.
[opencodex] OAuth refresh started provider=kiro account=account-…fce5
[opencodex] OAuth refresh joined existing operation provider=kiro account=account-…fce5
[opencodex] OAuth credentials rotated and persisted provider=kiro account=account-…fce5
[opencodex] OAuth refresh started provider=kiro account=account-…fce5
[opencodex] OAuth credentials rotated and persisted provider=kiro account=account-…fce5
[opencodex] OAuth refresh started provider=kiro account=account-…84db
[opencodex] OAuth credentials rotated and persisted provider=kiro account=account-…84db
[opencodex] OAuth refresh started provider=kiro account=account-…fce5
[opencodex] OAuth refresh started provider=kiro account=account-…2d3c
[opencodex] OAuth refresh started provider=kiro account=account-…653b
[opencodex] OAuth refresh started provider=kiro account=account-…e03b
[opencodex] OAuth credentials rotated and persisted provider=kiro account=account-…e03b
[opencodex] OAuth refresh started provider=kiro account=account-…fce5
[opencodex] OAuth credentials rotated and persisted provider=kiro account=account-…fce5
[opencodex] OAuth refresh joined existing operation provider=xai account=account-…89e4
🚀 opencodex proxy running on http://localhost:49234
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49236
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49297
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49302
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49304
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49306
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49308
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49310
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49312
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49317
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49319
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49322
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49325
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49327
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49329
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49331
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49333
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49335
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49337
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49389
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49391
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49393
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49395
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49397
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49399
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
[opencodex] OAuth refresh started provider=kimi account=account-…49e4
[opencodex] OAuth credentials rotated and persisted provider=kimi account=account-…49e4
🚀 opencodex proxy running on http://localhost:49406
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49408
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49410
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49412
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49414
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49416
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49418
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
🚀 opencodex proxy running on http://localhost:49420
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management API
GET / → GUI dashboard
[opencodex] gpt-5.4: multi-agent guidance injected (surface=collab, 128 chars)
[opencodex] gpt-5.4: effort cap applied (ultra -> high, main turn)
🚀 opencodex proxy running on http://localhost:49422
POST /v1/responses → provider translation
POST /v1/chat/completions → OpenAI-compatible clients
GET /healthz → health check
GET /api/* → management A…
Picks up the server-auth fixture-home flake RCA. Already on the internal remote, so the gitlink resolves.
Share one live discovery per provider-set key (Map), prewarm after bind, and encode OpenRouter-style model ids with ~ so Claude Available models stay readable.
Encode / as ~s and literal ~ as ~t so legacy bare-~ aliases keep resolving. Hash catalog-affecting config into the gather flight key and return flight-local combo omissions so concurrent keys cannot cross-contaminate.
…tegy polls Keep auto-switch / rotation controls from overwriting server state before /active settles, and drop shared /active reads that started before a PUT.
Split slow dashboard peers, cache non-secret page seeds, and keep Startup chrome stable while diagnostics settle.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review (2)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
|
Closing. This pull request contains no work by its author. The head commit here is byte-identical to a branch that already exists in this repository and was authored by the maintainer. All six of these pull requests have the same shape: fork the repository, push the upstream branches back unchanged, and open them as incoming contributions.
Every listed SHA resolves to the same commit on the upstream branch of the same name. The commit authors inside them are This is not a rebase, a resubmission of stalled work, or a fork that drifted. It burns maintainer review time and CI minutes on a diff that is already in the tree, and it presents other people's commits under a new author's pull request. Repository access is being revoked for this account. |
There was a problem hiding this comment.
💡 Codex Review
opencodex/src/server/images.ts
Line 446 in f0acc36
When a keyed or ChatGPT-forward image upstream returns an oversized body, this buffers the entire response with arrayBuffer() before checking IMAGES_RESPONSE_MAX_BYTES, so the intended 100 MiB cap is applied only after heap allocation and a malicious or misconfigured provider can exhaust memory instead of receiving the 502 path. Read the body incrementally and cancel once the cap is crossed, as the CCA branch already does.
AGENTS.md reference: src/AGENTS.md:L17-L17
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const apiKey = opencodeApiKey(config); | ||
| let proxyModels: OpencodeProxyModelRow[]; | ||
| try { | ||
| proxyModels = await fetchOpencodeProxyModels(live, apiKey); |
There was a problem hiding this comment.
Use the management token for the opencode catalog fetch
With the new management-auth split, /api/models is a management endpoint and rejects data-plane tokens, but cmdOpencode passes opencodeApiKey(config) here, which resolves to OPENCODEX_API_AUTH_TOKEN, the service-api-token file, config.apiKeys[0], or the fallback ocx. On a normal loopback install the proxy has generated an independent admin-api-token, so this request gets 401 and ocx opencode exits before launching even though the proxy is healthy; use the admin token/runningProxyUpdateHeaders for the catalog fetch while keeping the data-plane key for the child provider config.
Useful? React with 👍 / 👎.
| export function defaultCollapsedFamilies(counts: Readonly<Record<string, number>>): Set<string> { | ||
| return new Set(Object.keys(counts).filter(family => counts[family] === 0)); | ||
| return new Set(Object.keys(counts)); |
There was a problem hiding this comment.
Keep populated Claude families expanded by default
When a family has available models, this now still returns that family as collapsed, so a fresh Claude Desktop page with Opus models hides every model row behind an extra click instead of leaving the populated family open as the surrounding contract and regression test expect. Keep the data-driven filter so only empty families are folded by default.
Useful? React with 👍 / 👎.
Summary
Verification
Checklist