The 3 tests/boundary/*.live.test.ts files merged via #6786 hardcoded a real
Bearer API key, an auth_token JWT cookie, and a live instance URL. Replaced with
env reads (OMNIROUTE_TEST_BASE/BEARER/COOKIE), preserving the RUN_BOUNDARY_LIVE gate.
The leaked key/cookie must still be revoked/rotated on the affected instance and
purged from history separately (operator action).
* feat(proxy): relay repair + free-pool UX + relay awareness
* fix(proxy): preserve existing notes fields on relay repair; fix cpu limit /1000 across all 5 container providers
* feat(proxy): extract bulk-import and pool-modal hooks (#6625)
* fix: prevent relay type normalization to http on PATCH
Bug: updateProxyRegistrySchema inherited .default("http") from the base
schema, causing PATCH to silently overwrite relay types (vercel/deno/cloudflare)
with "http" when the client didn't send a type field.
- Move .default('http') from proxyRegistryFieldsSchema to
createProxyRegistrySchema (only applies to new proxies)
- Strip undefined keys from validated changes before passing to
updateProxy — .partial() leaves absent fields as undefined, which
the spread merge in updateProxyRow would propagate to the DB
- Add console.warn in extractRelayAuth when decrypt fails on a
known-encrypted relayAuthEnc blob
Closes#6905
* feat: replace Load More with page-number pagination in FreePoolTab
- Adds page-number pagination controls with prev/next buttons
- Shows per-page summary with total counts
- Resets to page 1 on filter change via wrapper setters
* fix(proxy): restore free-proxy sync-error tracking reverted by pagination commit
commit 2c8e79f13 (page-number pagination for FreePoolTab) accidentally
reverted the recordFreeProxySyncErrors/clearFreeProxySyncErrors/
getFreeProxySyncErrors functions and the search/sortBy list options that
an earlier commit (6f9ce75f3) in this same PR had added to
src/lib/db/freeProxies.ts and src/app/api/settings/free-proxies/route.ts.
localDb.ts still re-exported the three sync-error functions, so every
module that transitively imports it (which is most of the unit test
suite, plus the Next.js build used by dast-smoke) failed at load time
with "The requested module './db/freeProxies' does not provide an
export named 'clearFreeProxySyncErrors'".
Restores the reverted implementation (verbatim) and fixes the two new
"requires management auth" tests, which asserted 401 for an
unauthenticated request without configuring INITIAL_PASSWORD +
requireLogin first — on a fresh DB with no password configured,
isAuthRequired() treats a loopback request as the pre-setup bootstrap
path and allows it through, so the assertion needs the same
password/requireLogin setup already used by
tests/unit/api/settings-audit.test.ts.
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
* fix(proxy): trim unrelated scope from relay-repair/free-pool PR
Remove two subsystems that are unrelated to relay repair and the
free-pool UX and were never wired into the app:
- open-sse/services/combo/capabilityRequirements.ts and
CapabilityRequirementsEditor.tsx: a combo capability-filtering
feature never imported by combo.ts or combos/page.tsx, with no
test coverage.
- src/lib/skills/containerProvider.ts CPU-limit rescale: an
untested change to sandbox resource limits, unrelated to the
proxy/relay subsystem this PR targets. Restored to the
release baseline.
Also renumber the free_proxy_sync_errors migration 121 -> 122 to
avoid colliding with #6855, which independently claims 121 on the
same release branch.
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
---------
Co-authored-by: oyi77 <oyi77@users.noreply.github.com>
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
A Chat-Completions client can only express reasoning via the top-level
reasoning_effort hint and has no way to request a reasoning summary. When
that hint is promoted to the Responses API's reasoning.effort, the
upstream returns an empty summary and downstream chat clients see no
thinking stream (encrypted reasoning only).
Default reasoning.summary "auto" plus include ["reasoning.encrypted_content"]
on the effort-only path so the summary actually streams back to the chat
client, mirroring the Codex executor's ensureCodexReasoningSummary. An
explicit reasoning object from a Responses-shaped client is preserved
untouched, and reasoning_effort "none" is left without a summary.
Adds regression tests for the effort-only default, the none case, and
keeps the existing explicit-reasoning-object behavior unchanged.
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
Owner-approved /merge-prs tail freeze. localDb.ts is re-export-only (Hard Rule #2);
translator test grew from #6807's regression suite. Both frozen (shrink-only).
A structural engine (ccr / session-dedup) that finds nothing to compress
returns the body unchanged. That no-op was mishandled three ways — the
code-level root cause of the #6465–#6493 "0% savings, no reason" symptom class:
A. Inflation guard mislabelled a no-op as inflation. guardPipelineInflation
used `compressedTokens >= originalTokens`, so an unchanged body
(compressedTokens === originalTokens) tripped the guard, setting
fallbackApplied=true and emitting a misleading "did not shrink; reverted
to original" warning. Changed to strict `>` — only a strictly larger
output is inflation; equality is a no-op. Genuine inflation still reverts.
B. Disabled-engine skip was silent and asymmetric with the breaker skip. Both
stacked loops (sync + async) skipped a registry-disabled engine with a bare
`continue`, recording no validationWarning — while the sibling breaker-open
branch does. Both loops now add
`${engine}: skipped (engine disabled in registry)`, mirroring the breaker branch.
C. No-op engine lost its identity in engineBreakdown. mergeStackStep
early-returned on null stats, pushing no breakdown entry, so
ensureEngineBreakdown synthesized a generic "stacked" 0% node. It now records
a zero-savings entry keyed on the engine that actually ran, preserving identity.
Tests: tests/unit/compression-noop-guard.test.ts covers A (equal-token no-op not
inflated; strictly-larger still reverts), B (disabled skip surfaces a "disabled"
warning), and C (no-op engine keeps its own id in the breakdown). Updated the
existing inflation-guard test whose net-zero case encoded the old buggy behaviour,
and switched its wire test to object-form pipeline steps so the intended engine runs.
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
extractUsageFromResponse() and normalizeUsage() used Number(x)
coercion for cost_in_usd_ticks, which silently turned null/""
into 0 -- accepted downstream as a valid $0 exact cost instead of
falling back to the token-based estimate. Both call sites now
require typeof === "number" && Number.isFinite && >= 0.
Rebased onto current release/v3.8.47 tip (already carries #6711)
and trimmed to just the incremental validation fix + 2 regression
tests, replacing the stale-base diff that re-added the whole
already-merged feature.
Co-authored-by: KooshaPari <koosha@phenotype.io>
Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>
* fix(providers): scope nvidia NIM 404s to the single failing model (#6773)
The nvidia registry entry multiplexes 17 models from 9 different upstream
vendors (z-ai/, minimaxai/, deepseek-ai/, qwen/, mistralai/, stepfun-ai/,
moonshotai/, openai/, nvidia/) behind one connection, but was missing
passthroughModels: true — unlike 34 other multi-model registries
(modelscope, synthetic, kilo-gateway, etc). Without it, hasPerModelQuota
returns false for nvidia, so a 404 on a single stale/renamed model falls
through checkFallbackError's generic catch-all as a connection-wide
cooldown instead of being scoped to just that model, poisoning all 17
nvidia models for the cooldown window.
Add passthroughModels: true to the nvidia registry entry so 404/429s on
one model lock out only that model.
Regression test: tests/unit/nvidia-passthrough-models-6773.test.ts
* fix(quality): register nvidia passthrough test in stryker tap.testFiles
check-mutation-test-coverage.mjs --strict flagged
tests/unit/nvidia-passthrough-models-6773.test.ts as an unregistered
covering test for accountFallback.ts (Fast Quality Gates).
Co-authored-by: Diego Rodrigues de Sa e Souza <souzamiriamrodrigues790@gmail.com>
---------
Co-authored-by: Diego Rodrigues de Sa e Souza <souzamiriamrodrigues790@gmail.com>
* fix(responses): escape literal control chars in tool call JSON; emit status=failed on upstream error #6785
Two bugfixes in the Responses API translator:
1. escapeJsonStringValues() sanitizes tool call arguments containing
literal 0x0A/0x0D/0x09 bytes (emitted by Gemma4 models) into valid
JSON \n/\r/\t escapes, preventing SSE framing corruption. Only
escapes inside JSON string contexts — already-escaped sequences
and structural JSON pass through unchanged.
2. sendCompleted() checks state.upstreamError and emits status="failed"
with error.code + error.message instead of silently hardcoding
status="completed" + error=null, so mid-stream errors (e.g. Gemini
503 after partial content) are properly surfaced to the client.
3. stream.ts: calls translateResponse(null,...) before controller.error()
so the translator can emit close events (reasoning item done,
response.completed) before the stream is terminated.
* test(boundary): fix ESLint no-explicit-any warnings and quality gates
Green the PR against release/v3.8.47 quality gates without weakening tests:
- Replace @typescript-eslint/no-explicit-any in the new boundary/gemma4
tests with proper interfaces (ResponseBody, ToolDef, ToolArgs, SseEvent
item accessors) — fixes the "No new ESLint warnings" gate.
- Split tests/unit/translator-resp-openai-responses.test.ts (1079 LOC) by
extracting the round-trip suite into a sibling file so both stay under
the 800-line test cap — fixes check:file-size.
- Rename the 5 live boundary tests to *.live.test.ts, gate them behind
RUN_BOUNDARY_LIVE=1, add a test:boundary:live npm script and register the
glob in check-test-discovery COLLECTORS — fixes check:test-discovery
(they hit a live remote and must never run unopted in CI).
Co-authored-by: Markus Hartung <mail@hartmark.se>
---------
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
* fix(cli): ship head-response-guard.cjs in the standalone bundle
server-ws.mjs imports ./head-response-guard.cjs, but assembleStandalone had
no EXTRA_MODULE_ENTRIES entry for it, so every build:release bundle crashed
at boot with ERR_MODULE_NOT_FOUND (found deploying d1d75fdbf to the VPS on
2026-07-11). Adds the missing entry plus a regression test that derives the
required sidecar list from server-ws.mjs's own relative imports, guarding
the whole class of missing-sidecar bugs.
* docs(changelog): fragment for #6908
archiveLegacyRequestLogs() swept the entire DATA_DIR/logs directory as a
single "legacy" target and recursively deleted it after zipping. Since
PR #6234 moved the default app-log path to DATA_DIR/logs/application,
the migration was deleting the live file logger's own directory on
every boot until its marker file existed (#6799).
Separately, yazl's addFile() does an internal stat-then-stream read; if
a target file grows between those two steps (e.g. an actively-written
log), yazl emits "error" directly on the ZipFile instance. That event
had no listener, so Node re-threw it as an uncaughtException that
crashed the whole process at startup (#6401) — misdiagnosed upstream as
Turbopack/Windows chunk corruption because the stack trace pointed into
a bundled chunk.
Fix:
- listArchiveTargets() now enumerates DATA_DIR/logs entries individually
and skips the live app-logger directory (resolved via
logEnv.getAppLogFilePath()), so the shared parent directory is never
deleted wholesale.
- createLegacyArchive() wires a zipFile.on("error", ...) handler so a
stat/stream race rejects the promise (caught by the existing
try/catch) instead of escaping as an uncaughtException.
Regression test: tests/unit/usage-migrations-legacy-archive-safety.test.ts
(RED on unfixed code, GREEN after fix). Updated
tests/unit/request-log-migration.test.ts to the corrected contract —
DATA_DIR/logs itself now survives the archive sweep.
Gates run clean: file-size, complexity, cognitive-complexity,
changelog-integrity, typecheck:core, eslint (suppressions), and the
existing usage-migrations/request-log-migration unit suites.
* fix(sse): de-flake timing-sensitive combo cooldown/breaker tests (#6803)
Extracts 3 wall-clock-sensitive assertions (combo-quota-share cooldown
ceiling x2, circuit-breaker HALF_OPEN race) into tests/unit/serial/
(--test-concurrency=1, the repo's established remedy for this class of
test) and widens their margins, since a starved CI-runner event loop can
blow even a serialized test's timing window. Also adds an explicit 30s
vitest timeout to the MCP audit shutdown test, which had no override and
inherited vitest's 5000ms default.
Regression proof: reproduced RED locally under real devbox CPU
contention (2644ms/1796ms elapsed vs the old 1500ms ceiling, exactly the
reported failure mode); confirmed GREEN after the fix under the same
contention.
* fix(quality): register new serial timing tests + prune stale any-suppression count
- stryker.conf.json: add tests/unit/serial/combo-quota-share-cooldown-wait-timing.test.ts
and tests/unit/serial/combo-strategy-fallbacks-half-open-timing.test.ts to
tap.testFiles so their mutant kills count for accountFallback.ts and
circuitBreaker.ts (PR #6897 added these files but didn't register them).
- eslint-suppressions.json: combo-strategy-fallbacks.test.ts's no-explicit-any
suppression count was stale (35) after this PR trimmed 2 any-usages out of
the file when extracting the half-open timing test; corrected to 33.
Co-authored-by: Diego Rodrigues de Sa e Souza <souzamiriamrodrigues790@gmail.com>
---------
Co-authored-by: Diego Rodrigues de Sa e Souza <souzamiriamrodrigues790@gmail.com>
waitForServer() polled /api/monitoring/health but fell back to declaring
the server ready once the port had merely accepted TCP connections for
>= 3s, even if no HTTP response was ever received. On CPU-bound warmup
(e.g. small VPS running Next.js standalone), the OS-level listener
accepts TCP almost immediately while the request pipeline is still
compiling, so the fallback fired within ~3-7s and the CLI printed
'OmniRoute is running!' 30-60s before any route actually answered.
Classify each health poll into ready / fast-reject / hanging /
not-listening: only a fast HTTP rejection (fetch error that is not a
timeout, e.g. ECONNRESET before the route mounts) grants the original
#2460 Windows-cold-start grace window. A request that times out with
zero response (the reported #6800 symptom) resets the grace window
instead of accumulating toward it.
Regression tests: tests/unit/waitForServer-tcp-fallback-6800.test.mjs
(new RED-then-GREEN probe from the bug analysis) and
tests/unit/cli-waitForServer.test.mjs (existing suite realigned to the
corrected contract, plus a new case for the hanging-socket scenario).
* fix(providers): give v0-vercel-web its own alias so credentials are detected (#6343)
* test(6343): type casts to satisfy no-explicit-any gate
* test(6343): register v0-web + cliproxyapi tests in stryker tap.testFiles
The two unit tests added on this branch cover mutated modules
(src/sse/services/auth.ts, comboContextCache.ts) but were missing from
stryker.conf.json tap.testFiles, tripping check:mutation-test-coverage --strict.
Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
* fix(api): route error responses through sanitizeErrorMessage (Hard Rule #12)
9 API routes returned raw String(error)/error.message directly in HTTP 500
bodies, leaking SQLite paths, SQL text and internal messages. Route all through
sanitizeErrorMessage() per Hard Rule #12:
- settings/compression (GET+PUT), settings/compression/mcp-accessibility (GET+PUT)
- cache/entries (GET+POST), db/health (GET+POST), db-backups/exportAll
- assess, combos/test, settings/notion, settings/obsidian
Test: tests/unit/rule12-error-sanitization-sweep.test.ts asserts sanitized 500
bodies contain no absolute paths / stack tails.
* test(stryker): register rule12 error-sanitization sweep in tap.testFiles
The new tests/unit/rule12-error-sanitization-sweep.test.ts covers a mutated
module, so it must be listed in stryker.conf.json tap.testFiles for the
mutation-coverage gate (check-mutation-test-coverage.mjs --strict) to pass.
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
---------
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
* fix(ci): exclude check-test-masking.test.ts fixtures from self-referential tautology gate (#6634)
* fix(ci): extend test-masking self-fixture exclusion to sibling gate regression files (#6634)
The #6634 fix added isSelfTestFixtureFile()/scanBareTautologies() exclusions
that only matched check-test-masking.test.ts exactly. Its own new regression
file check-test-masking-selfref-6634.test.ts also embeds tautology-pattern
literals as fixtures/documentation, so the absolute-floor scanBareTautologies
gate self-tripped a HARD failure on the PR's own file. Generalize the
exclusion to the whole check-test-masking* self-test family and lock it with
two regression tests.
* fix(ci): publish electron-updater latest.yml manifests in release assets (#6766)
* fix(ci): register new mutation-covering test + realign stale codex-cli version fixture
- stryker.conf.json: add tests/unit/cliproxyapi-model-mapping-dispatch.test.ts to
tap.testFiles so it counts toward mutation coverage for the newly-added
comboContextCache.ts coverage (check:mutation-test-coverage --strict was failing).
- tests/unit/provider-models-route-codex.test.ts: DEFAULT_CODEX_CLIENT_VERSION was
bumped to 0.144.0 on release/v3.8.47 after this test's fixtures were written;
realign the hardcoded 0.142.0 expectations to the current constant.
* fix(oauth): embed Trae OAuth client_id via resolvePublicCred (Hard Rule #11)
* fix(quality): register tests/unit/trae-publiccred.test.ts in stryker tap.testFiles
The mutation test-coverage gate (check:mutation-test-coverage --strict) flags
new covering unit tests that mutate open-sse/utils/publicCreds.ts but aren't
listed in stryker.conf.json's tap.testFiles, so their mutant kills wouldn't
count. Register the new test file alphabetically.
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
---------
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
* fix(sse): stop combo path tripping whole-provider breaker on plain 429
The combo path recorded a whole-provider circuit-breaker failure for a
plain rate-limit 429, opening the breaker after N consecutive 429s and
blocking every account+model on that provider. This contradicts the
single-model path and the documented RESILIENCE_GUIDE policy.
- Single-model path uses PROVIDER_BREAKER_FAILURE_STATUSES =
Set([408, 500, 502, 503, 504]) (src/sse/handlers/chat.ts:206) — 429 excluded.
- Combo path gated shouldRecordProviderBreakerFailure on isProviderFailureCode
(accountFallback.ts), whose PROVIDER_FAILURE_ERROR_CODES INCLUDES 429 for
connection-cooldown scope — so a plain 429 wrongly tripped the whole-provider
breaker.
Fix scopes tightly: comboPredicates now tests a local
PROVIDER_BREAKER_FAILURE_STATUSES set mirroring the single-model constant
(429 excluded), instead of isProviderFailureCode. The shared
isProviderFailureCode / PROVIDER_FAILURE_ERROR_CODES are deliberately left
untouched — they drive connection-cooldown / model-lockout logic where 429
must still count. A genuine quota/token-limit terminal 429 is handled
elsewhere; only the whole-provider breaker-recording gate changes.
Adds tests/unit/combo-breaker-429.test.ts covering the 429 exclusion,
the 408/5xx inclusion, and the sameProviderNext / skipProviderBreaker
suppression paths.
* test(quality): register combo-breaker-429.test.ts in stryker tap.testFiles
Fast Quality Gates' mutation-coverage drift check flagged this PR's new
covering test for comboPredicates.ts as unregistered.
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
---------
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
* fix(electron): bump electron 42→43 + build better-sqlite3 from source (ABI 148) (#6605)
fix(electron): bump electron 42→43 + rebuild better-sqlite3 from source against the Electron ABI (148).
Electron 43 raises NODE_MODULE_VERSION to 148; better-sqlite3@12.11.1 has no electron-v148 prebuild, so the packaged app died with 'Nenhum driver SQLite disponível'. prepare-electron-standalone now compiles better-sqlite3 from source against the electron headers into build/Release (where 'bindings' resolves it). Validated by Electron Package Smoke (green) + local (node_register_module_v148).
Supersedes #6378. (--admin: the only reds are SonarQube/SonarCloud failing on a coverage-report artifact digest-mismatch — a GitHub Actions infra flake, not this diff; Sonar is green on main and the diff touches only the electron build.)
* deps: bump the development group across 1 directory with 6 updates (#6588)
deps: bump the development group (6 updates). Rebased onto current main; all checks green after the electron-smoke fix (#6605).
* fix(proxy): force CONNECT tunnel for HTTP proxied requests (undici 8.7) + production deps bump (#6620)
fix(proxy): force CONNECT tunnel for HTTP proxied requests (undici 8.7) + production deps bump.
undici 8.6+ changed ProxyAgent to forward plain-HTTP via request-proxy instead of CONNECT, breaking OAuth refresh through a connection proxy (501). proxyDispatcher now passes proxyTunnel:true. Validated: Unit Tests 3/8 (the OAuth-proxy test) green, new regression test green (fails without the fix on undici 8.7), SonarQube green.
Supersedes #6380. (--admin: the only red is Electron Package Smoke failing on a next-build artifact 'digest-mismatch' — a GitHub Actions infra flake corrupting the asar ('file data stream has unexpected number of bytes'); the better-sqlite3 rebuild itself succeeded (gyp ok) and the electron path is unchanged from #6605 which passed the smoke. Not this diff.)
* feat(proxy): add shorthand formats + protocol header mode for bulk import
Supports 6 new shorthand formats alongside the existing pipe-delimited
parser:
- ip:port
- ip:port:user:pass
- user:pass@ip:port
- user:pass:ip:port
- protocol://ip:port
- protocol://user:pass@ip:port
Protocol header mode: a bare protocol name (http/https/socks5) on its
own line sets the default type for subsequent protocol-less shorthand
lines. Explicit protocol:// prefix always takes precedence over the
header default.
Changes:
- Rewrite parseBulkProxyImport.ts with parseShorthandLine helper
- Use Record<string, true> for static lookup tables (VALID_PROXY_TYPES,
VALID_PROXY_STATUSES) per project convention
- Add looksLikeHost() heuristic to disambiguate 4-colon format
(ip:port:user:pass vs user:pass:ip:port)
- Update BULK_IMPORT_TEMPLATE in ProxyRegistryManager.tsx with full
documentation and examples for all formats
- Update en.json bulkImportDescription to list all supported formats
- Add 30 unit tests covering every format, edge cases, and regressions
for the existing pipe-delimited path
---------
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
* fix(sse): combo model lockout honors parsed upstream quota reset (#6863)
The combo failure path recorded model lockouts from checkFallbackError's
cooldownMs only, discarding quotaResetHintMs — the ungated channel that
carries a parsed upstream quota reset (e.g. Antigravity 429 "Resets in
92h27m28s"). With OAuth profiles defaulting useUpstreamRetryHints=false,
the lockout fell back to the base cooldown (seconds), so quota-dead
accounts were re-walked serially by every combo request for days
(measured 122s per request, 494s worst case in #6863).
Thread max(cooldownMs, quotaResetHintMs) into selectLockoutCooldownMs at
both combo lockout sites, mirroring the single-model path pattern in
src/sse/services/auth.ts (v3.8.43). All three resilience fences are
preserved: useUpstreamRetryHints still gates connection cooldowns, the
hint only affects model-scope lockouts, and combo 429s remain
non-persistent.
TDD: tests/unit/combo-lockout-quota-reset-6863.test.ts fails on base
(lockout 5000ms) and passes with the fix (~92.5h).
* test(sse): tighten #6863 lockout assertion to parsed-reset bounds; prettier pass
Assert remainingMs falls within (parsedResetMs - 5s, parsedResetMs] so a
hardcoded long cooldown cannot satisfy the regression test. Also apply
Prettier to both changed files (includes one pre-existing formatting fix
in handleRoundRobinCombo picked up by --write).
* fix(sse): align combo lockout hint selection with single-model path; register test in mutation gate
Adopt review feedback: replace Math.max(cooldownMs, quotaResetHintMs) with
the auth.ts pattern (usedUpstreamRetryHint ? cooldownMs : quotaResetHintMs)
so a parsed reset SHORTER than the fallback cooldown wins too — e.g. the
subscription-quota branch returns a 1h fallback while the body says
"resets in 45m"; max() would over-lock by 15 minutes.
Add a regression test for the short-reset case (fails against the max()
variant) and register the new test file in stryker.conf.json tap.testFiles
to satisfy check:mutation-test-coverage --strict.
* chore(quality): register cliproxyapi dispatch test in mutation gate
tests/unit/cliproxyapi-model-mapping-dispatch.test.ts landed on
release/v3.8.47 via #6903 without a tap.testFiles entry, so
check:mutation-test-coverage --strict fails on the branch tip and on
every PR merge ref. Register it so the gate is green again.
---------
Co-authored-by: judy459 <JUDYZHU459@outlook.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
* fix(electron): bump electron 42→43 + build better-sqlite3 from source (ABI 148) (#6605)
fix(electron): bump electron 42→43 + rebuild better-sqlite3 from source against the Electron ABI (148).
Electron 43 raises NODE_MODULE_VERSION to 148; better-sqlite3@12.11.1 has no electron-v148 prebuild, so the packaged app died with 'Nenhum driver SQLite disponível'. prepare-electron-standalone now compiles better-sqlite3 from source against the electron headers into build/Release (where 'bindings' resolves it). Validated by Electron Package Smoke (green) + local (node_register_module_v148).
Supersedes #6378. (--admin: the only reds are SonarQube/SonarCloud failing on a coverage-report artifact digest-mismatch — a GitHub Actions infra flake, not this diff; Sonar is green on main and the diff touches only the electron build.)
* deps: bump the development group across 1 directory with 6 updates (#6588)
deps: bump the development group (6 updates). Rebased onto current main; all checks green after the electron-smoke fix (#6605).
* fix(proxy): force CONNECT tunnel for HTTP proxied requests (undici 8.7) + production deps bump (#6620)
fix(proxy): force CONNECT tunnel for HTTP proxied requests (undici 8.7) + production deps bump.
undici 8.6+ changed ProxyAgent to forward plain-HTTP via request-proxy instead of CONNECT, breaking OAuth refresh through a connection proxy (501). proxyDispatcher now passes proxyTunnel:true. Validated: Unit Tests 3/8 (the OAuth-proxy test) green, new regression test green (fails without the fix on undici 8.7), SonarQube green.
Supersedes #6380. (--admin: the only red is Electron Package Smoke failing on a next-build artifact 'digest-mismatch' — a GitHub Actions infra flake corrupting the asar ('file data stream has unexpected number of bytes'); the better-sqlite3 rebuild itself succeeded (gyp ok) and the electron path is unchanged from #6605 which passed the smoke. Not this diff.)
* feat(provider): add OpenVecta AI inference gateway
OpenVecta (https://openvecta.com/) is an OpenAI-compatible AI inference
gateway hosting LLMs (GLM, Claude, DeepSeek, GPT OSS, Llama, Kimi,
Nemotron...) plus text-embedding-* models behind a single Bearer key.
Wiring (7 integration points):
- src/shared/constants/providers/apikey/inference-hosts.ts: catalog entry
- open-sse/config/providers/registry/openvecta/index.ts: registry w/ 9 seed LLMs
- open-sse/config/providers/index.ts: wire into REGISTRY
- src/app/api/providers/[id]/models/discovery/providerModelsConfig.ts: live /v1/models URL
- src/app/api/providers/[id]/models/discovery/providerSets.ts: NAMED_OPENAI_STYLE_PROVIDERS
- public/providers/openvecta.svg: brand icon
- tests/unit/openvecta-provider-registration.test.ts: regression guard (6 tests, all pass)
No executor needed — buildOpenAiCompatibleRegistryEntry wires
format=openai / executor=default / authType=apikey / authHeader=bearer.
Live catalog discovery uses the existing NAMED_OPENAI_STYLE_PROVIDERS
path (live /v1/models fetch + registry seed as offline fallback).
Validation:
- npm run typecheck:core clean
- npm run typecheck:noimplicit:core 4 errors in unchanged files (combo.ts, cliRuntime.ts); 0 in new code
- npm run lint clean
- node --import tsx/esm --test tests/unit/openvecta-provider-registration.test.ts 6/6 pass
- sibling tests/unit/openai-style-providers-4239-4155-3841.test.ts 18/18 pass (no regression)
* chore(merge): drop unrelated main-drift from PR fork + fix count/golden drift
The fork branch predated main's electron 42→43 bump (#6605) and several other
package.json/lockfile churn; those files are unrelated to the OpenVecta
provider addition and were reintroducing an older/stale state (version
3.8.46, electron 42, older bun/eslint-config-next) that broke the Electron
Package Smoke check. Restored package.json, package-lock.json,
electron/package.json, electron/package-lock.json, and
scripts/build/prepare-electron-standalone.mjs to match
origin/release/v3.8.47.
Also updates the two provider-count assertions (166->167) and regenerates
the translate-path golden snapshot to account for the new openvecta entry.
Co-authored-by: hajilok <120608486+hajilok@users.noreply.github.com>
---------
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: diegosouzapw <diegosouzapw@users.noreply.github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <diegosouza.pw@gmail.com>
* fix(electron): bump electron 42→43 + build better-sqlite3 from source (ABI 148) (#6605)
fix(electron): bump electron 42→43 + rebuild better-sqlite3 from source against the Electron ABI (148).
Electron 43 raises NODE_MODULE_VERSION to 148; better-sqlite3@12.11.1 has no electron-v148 prebuild, so the packaged app died with 'Nenhum driver SQLite disponível'. prepare-electron-standalone now compiles better-sqlite3 from source against the electron headers into build/Release (where 'bindings' resolves it). Validated by Electron Package Smoke (green) + local (node_register_module_v148).
Supersedes #6378. (--admin: the only reds are SonarQube/SonarCloud failing on a coverage-report artifact digest-mismatch — a GitHub Actions infra flake, not this diff; Sonar is green on main and the diff touches only the electron build.)
* deps: bump the development group across 1 directory with 6 updates (#6588)
deps: bump the development group (6 updates). Rebased onto current main; all checks green after the electron-smoke fix (#6605).
* fix(proxy): force CONNECT tunnel for HTTP proxied requests (undici 8.7) + production deps bump (#6620)
fix(proxy): force CONNECT tunnel for HTTP proxied requests (undici 8.7) + production deps bump.
undici 8.6+ changed ProxyAgent to forward plain-HTTP via request-proxy instead of CONNECT, breaking OAuth refresh through a connection proxy (501). proxyDispatcher now passes proxyTunnel:true. Validated: Unit Tests 3/8 (the OAuth-proxy test) green, new regression test green (fails without the fix on undici 8.7), SonarQube green.
Supersedes #6380. (--admin: the only red is Electron Package Smoke failing on a next-build artifact 'digest-mismatch' — a GitHub Actions infra flake corrupting the asar ('file data stream has unexpected number of bytes'); the better-sqlite3 rebuild itself succeeded (gyp ok) and the electron path is unchanged from #6605 which passed the smoke. Not this diff.)
* chore(deps): bump github/codeql-action/init from 4.36.3 to 4.37.0
Bumps [github/codeql-action/init](https://github.com/github/codeql-action) from 4.36.3 to 4.37.0.
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](54f647b7e1...99df26d4f1)
---
updated-dependencies:
- dependency-name: github/codeql-action/init
dependency-version: 4.37.0
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* fix(electron): bump electron 42→43 + build better-sqlite3 from source (ABI 148) (#6605)
fix(electron): bump electron 42→43 + rebuild better-sqlite3 from source against the Electron ABI (148).
Electron 43 raises NODE_MODULE_VERSION to 148; better-sqlite3@12.11.1 has no electron-v148 prebuild, so the packaged app died with 'Nenhum driver SQLite disponível'. prepare-electron-standalone now compiles better-sqlite3 from source against the electron headers into build/Release (where 'bindings' resolves it). Validated by Electron Package Smoke (green) + local (node_register_module_v148).
Supersedes #6378. (--admin: the only reds are SonarQube/SonarCloud failing on a coverage-report artifact digest-mismatch — a GitHub Actions infra flake, not this diff; Sonar is green on main and the diff touches only the electron build.)
* deps: bump the development group across 1 directory with 6 updates (#6588)
deps: bump the development group (6 updates). Rebased onto current main; all checks green after the electron-smoke fix (#6605).
* fix(proxy): force CONNECT tunnel for HTTP proxied requests (undici 8.7) + production deps bump (#6620)
fix(proxy): force CONNECT tunnel for HTTP proxied requests (undici 8.7) + production deps bump.
undici 8.6+ changed ProxyAgent to forward plain-HTTP via request-proxy instead of CONNECT, breaking OAuth refresh through a connection proxy (501). proxyDispatcher now passes proxyTunnel:true. Validated: Unit Tests 3/8 (the OAuth-proxy test) green, new regression test green (fails without the fix on undici 8.7), SonarQube green.
Supersedes #6380. (--admin: the only red is Electron Package Smoke failing on a next-build artifact 'digest-mismatch' — a GitHub Actions infra flake corrupting the asar ('file data stream has unexpected number of bytes'); the better-sqlite3 rebuild itself succeeded (gyp ok) and the electron path is unchanged from #6605 which passed the smoke. Not this diff.)
* chore(deps): bump github/codeql-action/analyze from 4.36.3 to 4.37.0
Bumps [github/codeql-action/analyze](https://github.com/github/codeql-action) from 4.36.3 to 4.37.0.
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](54f647b7e1...99df26d4f1)
---
updated-dependencies:
- dependency-name: github/codeql-action/analyze
dependency-version: 4.37.0
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Owner-approved merge-burst reconciliation. cognitive-complexity does not run on
PR->release fast-gates, so incidental growth across the 23-PR merge-ready batch
accrued unmeasured (measured 890 on the combined merge-train tip vs 885 pristine).
When no explicit judgeModel is configured, the judge defaulted to panel[0]
before fan-out and was never reassigned. If panel[0] failed fan-out (timeout /
rate-limit / dropped straggler → it lands in `failures`, not `answers`), the
multi-answer synthesis path still dispatched the judge to that dead panel[0],
erroring the whole fusion request even though a quorum of other panel members
succeeded — exactly the failure fusion exists to tolerate.
Resolve the effective synthesis judge from a survivor when no explicit judge is
set: prefer panel[0] only when it survived, otherwise the first surviving
answer. An explicitly configured judge is still honored unchanged (operator
intent), and the answers.length===0 (503) and single-survivor branches keep
their existing semantics.
Co-authored-by: Chirag Singhal <chirag127@users.noreply.github.com>
LogsPage recomputed initialId from window.location on every render, but the
App Router syncs window.location only after the navigation commits. Closing
the detail modal re-rendered the page while the URL still carried ?id=X, so
initialSelectedId flipped null -> X and the child's one-shot deep-link effect
(guard still unarmed after the open-click render, where location was stale in
the other direction) reopened the modal. Only the second close worked.
Read the id once via lazy useState so the prop stays stable for the page's
lifetime; deep links still open the modal on mount.
Regression test reproduces the App Router ordering with a router.replace mock
that re-renders the page before committing the URL.
getExplicitModelOutputCap() (the clamp ceiling used by
resolveReasoningBufferedMaxTokens) only ever read the unvalidated synced
limit_output / registry / static-spec chain — it ignored the operator-settable
max_token capability override that getResolvedModelCapabilities() already
consulted. When a provider's synced catalog row reports a wrong limit_output
(e.g. ollama-cloud/deepseek-v4-flash: limit_output=1048576, same as
limit_context, while the real upstream cap is 65536), the reasoning-buffer
clamp trusted the bad number and inflated max_tokens 64000 -> 96000, which
upstream rejected with "exceeds model's maximum output tokens (65536)".
The override table (model_capability_overrides, "max_token" key,
/api/model-capability-overrides) is the existing, already-shipped remediation
path for exactly this class of bad catalog data, but reasoningTokenBuffer.ts
had no way to benefit from it. Extracted the override lookup into a shared
getMaxTokenCapabilityOverride() helper and made getExplicitModelOutputCap()
consult it first, so both read paths now agree.
TOTAL_MCP_TOOL_COUNT in open-sse/mcp-server/server.ts summed collection sizes
additively, double-counting tools registered in more than one collection.
The agent-skills trio (omniroute_agent_skills_list/get/coverage) is
intentionally defined in both MCP_TOOLS (schemas/tools.ts) and
agentSkillTools (tools/agentSkillTools.ts), inflating the reported count
from 96 unique tools to 99.
Replace the additive sum with countUniqueMcpTools() (new
open-sse/mcp-server/toolCount.ts), which unions all collection tool
names into a Set before counting, so any future overlap self-corrects
instead of double-counting.
Regression test: tests/unit/mcp-tool-count-dedup-6854.test.ts
Two related root causes in the stacked compression pipeline:
- #6479/#6491: a dispatched step whose engine legitimately finds nothing
eligible (session-dedup with no repeated blocks, ccr below its min-chars
threshold) returns `{ stats: null }`. `mergeStackStep()` silently dropped
that step from `engineBreakdown` with zero trace — no warning, no error.
Now records a `"<engine>: skipped (no eligible content)"` validation
warning for any null-stats step, covering every engine that follows this
convention (session-dedup, ccr, headroom, relevance, llm, llmlingua,
ionizer, readLifecycle), not just the two reported.
- #6480: `finalizeStackedResult` ran the aggregate `guardPipelineInflation`
check unconditionally, even when the loop-level `compressed` flag stayed
false (no step ever advanced `currentBody`). Since tokens are trivially
equal when nothing ran, the guard mislabeled a genuine no-op as
`fallbackApplied: true` with a misleading "reverted to original" warning.
Extracted the guard into `applyStackedInflationGuard()` in
`pipelineGuards.ts` (keeps `strategySelector.ts` under its frozen line
budget) and gated it on `compressed === true`.
Also fixes `compression-pipeline-inflation-guard.test.ts`'s wire test,
which passed a bare engine-id string to the pipeline; `normalizePipelineStep()`
only recognizes a fixed set of built-in string aliases and silently
downgrades any other string to `{ engine: "caveman" }`, so the test's
custom inflating engine was never actually exercised. Passing a step object
restores the test's original intent.
New regression tests: tests/unit/compression/repro-6479-6491-null-stats-silent-drop.test.ts,
tests/unit/compression/repro-6480-noop-guard-misfire.test.ts.
resolveOmniRoutePluginOptions() auto-prefixes providerId with "opencode-"
(commit 75b52e286) so OpenCode 1.17.8+'s native-adapter gate accepts it as a
registered provider id. That prefixed value was being reused for the
OmniRoute-server-facing identifiers too: mapRawModelToModelV2's id/providerID,
mapComboToModelV2's providerID, and the dynamic provider hook's combo catalog
keys. OmniRoute's server has no "opencode-<x>" provider alias, so every
dispatched model failed credential lookup with "No credentials for
opencode-omniroute" / "No active credentials for provider:
opencode-omniroute".
Add a second, unprefixed omnirouteProviderId field and thread it through the
four dynamic-hook call sites that emit server-facing identifiers, while
leaving the OC-gate-prefixed providerId in place for AuthHook.provider,
provider registration (hook.id), and the static-catalog path (which OC
strips before dispatch, per the existing static-block comments).
- preInitSqlJs() now memoizes an in-flight Promise (not just the resolved
adapter) per filePath, so concurrent BATCH/STARTUP/HealthCheck/
ProviderLimitsSync callers at boot share one full-file read+WASM decode
instead of each independently reloading the whole database — the
thundering-herd amplifier of the OOM condition #6632 already partly
fixed, left un-implemented by the reporter's own proposed fix (#6628).
- sqljsAdapter's run/get/all now unwrap a lone named-parameter object
(e.g. .all({ isActive: 1 }) for "WHERE is_active = @isActive", the same
call shape getProviderConnections() already uses against better-sqlite3)
before calling sql.js's stmt.bind(), expanding it to the @/:/$ sigil
variants sql.js's own named-bind path requires. Previously the object
was wrapped into an array and sql.js took the positional-bind path,
throwing "Wrong API use : tried to bind a value of an unknown type
([object Object])." whenever the sql.js WASM fallback driver was active
— exactly the error #6802 reported (misattributed to better-sqlite3).
Regression tests added to tests/unit/db-adapters/driverFactory.test.ts and
tests/unit/db-adapters/sqljsAdapter.test.ts, both proven RED against the
prior code and GREEN after the fix.
Enterprise-tier Claude accounts (default_raven_enterprise) don't get
five_hour/seven_day utilization windows from Anthropic's OAuth usage
endpoint — only an extra_usage credit-billing block. parseClaude()
only read data.quotas, so quotas stayed {} and the dashboard showed
"No quota data" even when extraUsage showed the account 100%
exhausted. parseClaude() now folds an enabled extraUsage block into a
credits-style quota row (mirroring parseCodex's bankedResetCredits
pattern), both when quotas is empty and when it's already populated.
No-auth providers (mimocode, opencode, ...) are always dispatched with a single
hardcoded connectionId ("noauth" — SYNTHETIC_NOAUTH_CONNECTION_ID in
src/sse/services/auth.ts). No provider_connections row ever has id="noauth", so
resolveProxyForConnection() in src/lib/db/settings.ts could never populate
connectionRecord for them, and its provider-level proxy lookup (Steps 6/8) only
runs when connectionRecord is present. A proxy assigned via Settings -> Providers
-> mimocode was therefore silently ignored, reproducing the reporter's "same
thing happen when i set the proxy directly in the provider menu" symptom.
Adds a best-effort fallback (src/lib/db/settings/noAuthProxyFallback.ts): when
connectionRecord could not be resolved, scan the known no-auth provider ids for a
configured provider-level proxy (registry first, then legacy) before falling
through to the global/direct steps.
Regression test: tests/unit/proxy-noauth-provider-6272.test.ts (RED on unfixed
code — resolved to level=direct/proxy=null; GREEN after the fix).
combo.ts's isContextOverflow400() guard required the literal word
'context' in the 400 error body before letting a combo fall through to
the next target. Kimi's exact wording ('Your request exceeded model
token limit: 262144 (requested: 308458)') never says 'context', so the
guard misclassified it as a body-specific error and halted the whole
combo instead of trying the next (larger-context) target.
accountFallback.ts's CONTEXT_OVERFLOW_PATTERNS already recognized this
wording one layer below (via checkFallbackError -> shouldFallback), so
the two independently-maintained classifiers disagreed and the
stricter one won. Export CONTEXT_OVERFLOW_PATTERNS from
accountFallback.ts and reuse it inside combo.ts's
isContextOverflow400() so both layers share a single source of truth.
Regression test: tests/unit/repro-6637-kimi-token-limit.test.ts
(RED on unfixed code -> GREEN after the fix). Existing #4519 guard
tests (tests/unit/combo-param-validation-fallback-4519.test.ts) still
pass, including the negative case that a genuinely body-specific 400
is NOT misclassified as overflow.
Collapse duplicate CI spend while keeping each gate's existence reason:
- quality.yml: TIA __RUN_ALL__ defers full unit to fast-unit 4-shard (#6781);
path filters via classify-pr-changes; docs-gates split; draft skip
- ci.yml: wire docs/i18n/code path filters; ESLint JSON artifact for quality-gate;
drop advisory typecheck:noimplicit; float actions/cache@v6
- TIA parity: memory/usage/combo/serial; **/*.test.mjs any depth; electron/bin
no longer force unit __RUN_ALL__
- check:complexity-ratchets: one ESLint walk, ruleId-isolated baselines + cache
- check:api-docs-refs + lib/apiRoutes: shared API route inventory
- husky pre-push: intentionally light (gates live in pre-commit); CLAUDE.md +
QUALITY_GATES.md docs synced
- collect-metrics / lint:json: path.resolve cache path; Windows-safe eslint bin
- env-doc allowlist for ESLINT_RESULTS_JSON / COMPLEXITY_ESLINT_REPORT
- release-green --full-ci expects check:api-docs-refs (not docs-symbols alone)
Tests: select-impacted, classify-pr-changes, api-routes lib, complexity-rule-count,
validate-release-green.
Reconciled after #6781 (fast-unit 2→4 shards) per maintainer request on #6716.
Co-authored-by: Diego Rodrigues de Sa e Souza <8016841+diegosouzapw@users.noreply.github.com>
* feat(providers): add Z.ai Web free web-cookie provider (#4056)
New zai-web web-session provider drives the free chat.z.ai consumer
chat UI via a pasted browser cookie, distinct from the existing
API-key zai/glm/glm-cn/glmt providers (api.z.ai). ZaiWebExecutor posts
to chat.z.ai/api/chat/completions with the cookie forwarded both as
Cookie and Authorization: Bearer <token>, and normalizes both z.ai's
internal delta_content/phase SSE envelope and a pass-through
OpenAI-shaped choices[].delta frame into standard chat-completion
chunks.
Registered in WEB_COOKIE_PROVIDERS, WEB_SESSION_CREDENTIAL_REQUIREMENTS,
the provider registry (GLM-4.6/4.5/4.5V models), the executor factory,
and tokenExtractionConfig.ts for in-app cookie capture.
* fix(providers): regenerate translate-path golden for zai-web + reduce cognitive complexity
* fix(providers): rename ZaiWebExecutor.buildHeaders to avoid incompatible BaseExecutor override
* chore(merge): re-sync with release/v3.8.47; move changelog bullet to changelog.d fragment (merge-storm proof)
* feat(usage): surface Antigravity weekly quota alongside the 5-hour window (#4017)
Antigravity enforces both a 5-hour and a weekly usage limit, but the agy/antigravity
quota widget only exposed the 5-hour window. The weekly limit isn't in the per-model
retrieveUserQuota response already fetched — it lives in a separate, undocumented
retrieveUserQuotaSummary RPC that groups models into families (Gemini Models, Claude
and GPT models) with one weekly bucket per family.
Adds a self-contained usage/antigravityWeeklyQuota.ts leaf: a cached, best-effort
fetch of that RPC + a pure parser that extracts the weekly-labeled bucket per group
(window inferred from bucketId/displayName text, matching the reverse-engineered
shape documented by third-party Antigravity clients) into gemini_weekly/
claude_gpt_weekly quota entries, merged into the existing quotas map the widget
already renders generically. A failed/unavailable RPC never affects the existing
per-model quotas.
Live VPS validation attempt (192.168.0.15, real antigravity account): both
retrieveUserQuota and retrieveUserQuotaSummary currently return 429
RESOURCE_EXHAUSTED for that account, so the live response shape could not be
captured directly. The parser was instead validated via TDD against the bucket
shape documented by CodexBar (steipete/CodexBar), a third-party Antigravity client
that reverse-engineered the same RPC, and is defensive against both response
envelopes it has observed (top-level groups[] and nested quotaSummary.groups[]).
* chore(merge): re-sync with release/v3.8.47 (restore CHANGELOG, keep own bullet)
* chore(merge): re-sync with release/v3.8.47; move changelog bullet to changelog.d fragment (merge-storm proof)
* feat(codex): echo requested effort-suffixed model id in Responses payloads (#3697)
Codex CLI compatibility shim: the Responses API response.created/
response.in_progress/response.completed payloads now carry a `model`
field (previously absent), and for Codex-CLI-originated requests it
echoes the client-requested effort-suffixed model id (e.g.
gpt-5.5-xhigh) instead of the bare upstream id (gpt-5.5), so the Codex
CLI status line/model button shows the active reasoning effort.
- openai-responses.ts translator threads the upstream model into the
Responses event objects (additive, omitted when unknown).
- New isCodexOriginatedHeaders() (codexIdentity.ts) reuses PR #3481's
originator/User-Agent detection, header-based so it still fires when
a combo routes codex/gpt-5.5-xhigh to a non-codex upstream.
- chatCore's existing opt-in #1311 echoModel pipeline now also fires
automatically for Codex clients on the Responses API, regardless of
the echoRequestedModelName setting.
- responseModelEcho.ts now also rewrites the nested response.model
field the Responses API uses (previously only top-level model).
- /v1/models keeps returning models: [] for Codex (unchanged, #3481).
Regression guard: tests/unit/codex-effort-model-echo-3697.test.ts.
Closes#3697
* chore(merge): re-sync with release/v3.8.47 (restore CHANGELOG, keep own bullet)
* chore(merge): re-sync with release/v3.8.47; move changelog bullet to changelog.d fragment (merge-storm proof)
