Skip to content

Stack/gui dense workspaces - #804

Closed
batuchek68-ux wants to merge 138 commits into
lidge-jun:codex/260728-tls-altname-diagnosisfrom
batuchek68-ux:stack/gui-dense-workspaces
Closed

Stack/gui dense workspaces#804
batuchek68-ux wants to merge 138 commits into
lidge-jun:codex/260728-tls-altname-diagnosisfrom
batuchek68-ux:stack/gui-dense-workspaces

Conversation

@batuchek68-ux

Copy link
Copy Markdown

Summary

  • Explain the user-visible or maintainer-facing change.

Verification

  • List the commands or checks you ran.

Checklist

  • Scope stays focused and avoids unrelated cleanup.
  • Docs or release notes were updated when needed.
  • Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults.

Wibias and others added 30 commits July 27, 2026 17:37
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>
lidge-jun and others added 21 commits July 30, 2026 11:06
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.
@coderabbitai

coderabbitai Bot commented Jul 31, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

🗂️ Base branches to auto review (2)
  • ^dev$
  • ^preview$

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 9c188060-4e4a-4830-9b3e-2366a2ce87e6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Comment @coderabbitai help to get the list of available commands.

@lidge-jun

Copy link
Copy Markdown
Owner

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.

PR head SHA identical upstream branch
#798 eef9a86d codex/260728-tls-altname-diagnosis
#799 d0763bf7 codex/260729-security-md-reporting-path
#800 d380b1b0 codex/260731-pr-merge-round
#802 a64aa585 codex/app-server-restart
#803 b0434ea5 codex/pr533-update-recovery-hardening
#804 f0acc36a stack/gui-dense-workspaces

Every listed SHA resolves to the same commit on the upstream branch of the same name. The commit authors inside them are lidge-jun, Wibias, ahmetb, aljjang95, hanbinnoh and other existing contributors. The descriptions are the unmodified pull request template with every checklist item unchecked, and #798 additionally carries the maintainer's own commit message pasted in as if it were a summary. Several target main, which AGENTS.md reserves for maintainer-controlled promotion, and two are chained onto each other's heads in a cycle.

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.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

const payload = await upstreamResponse.arrayBuffer();

P2 Badge Stream image responses before enforcing the size cap

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".

Comment thread src/cli/opencode.ts
Comment on lines +653 to +656
const apiKey = opencodeApiKey(config);
let proxyModels: OpencodeProxyModelRow[];
try {
proxyModels = await fetchOpencodeProxyModels(live, apiKey);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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));

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge 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 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.