[WRONG BRANCH] Promote dev to main: Wave 5 campaign (107 commits) - #1963
Merged
Conversation
Keep the existing -tiered mapping by default while allowing AI Studio providers that still serve bare Gemini Flash ids to opt out. Cover both Flash generations and document the provider setting.
…-out - identifyRoutedModel now names parsed.modelId so a -tiered wire rename never leaks into the system prompt identity (CodeRabbit finding) - document that directGeminiWireRenames affects only AI Studio direct requests; Vertex and Cloud Code Assist are unchanged - add adapter tests for explicit true and Cloud Code Assist opt-out
…ctor Phase A0 of the FastWire umbrella (#1886): characterization suites only, zero production changes. Locks the three-state fastMode contract, the unclassified passthrough matrix, exact-model foreign-tier forwarding, the mixed requestedServiceTier logging semantics, routing/fingerprint projections, catalog tier-field byte goldens, and two known bugs (native chat ignores exact-model false; chat-to-responses conversion drops service_tier) as current behavior. Full suite at this commit: 12746 pass / 10 skip / 0 fail. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…udge Routed providers were told the valid names were exactly the flat top-level catalog. In Codex code mode, deferred helpers such as tools.codex_app__list_threads stay callable inside exec even when they are omitted from the listed names and from exec description. Discover them from the isolate global ALL_TOOLS, not tools.ALL_TOOLS.
…tch callable CodeRabbit on #1895: use the transformed exec wire name in the shared catalog nudge, and do not forbid apply_patch at the top level when that tool is separately advertised in code mode.
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Count createPlanRequestQuery text as assistant output before clean EOF, reject non-loopback http discovery URLs before sending the Bearer token, and return the live model count as structured data on the Cursor probe.
CodeRabbit asked to throw on incomplete tools at Connect EOF. That would hide the existing fail-closed error event as a generic transport failure.
….5.5 decompilation - Align token sequence in antigravityUserAgent to match decompiled Go Language Server setHeaders (0x1018fbe00): os_type -> arch -> aidev_client -> auth_method=oauth. - Result: antigravity/ide/2.5.5 (os_type=windows; arch=amd64; aidev_client; auth_method=oauth). - Update unit and wire tests to assert exact decompiled token sequence.
…erride regression tests - Use antigravityUserAgent() for ANTIGRAVITY_REQUEST_UA to ensure trimmed override handling. - Add focused regression tests for GOOGLE_ANTIGRAVITY_USER_AGENT and PI_AI_ANTIGRAVITY_USER_AGENT (trimming, precedence, whitespace fallback).
… env var - Allow optional authMethod parameter on antigravityUserAgent (defaults to oauth). - Drop undocumented PI_AI_ANTIGRAVITY_USER_AGENT override to keep changes minimal.
Onboarding was filling metadata.ide_version with antigravityUserAgent(), which returns the entire header - antigravity/ide/2.5.5 (aidev_client; os_type=...; arch=...) - where the real client sends 2.5.5. Nothing failed, and that is the point. The request still succeeds; it just does not look like Antigravity. A fingerprint is only worth having if it matches, and this one had a parenthesized UA string sitting in a version field on every onboarding call. ANTIGRAVITY_IDE_VERSION already existed one import away. The regression pins the field and asserts the shape it must not have, so the next person reaching for the UA helper here gets a failure instead of a silently wrong fingerprint. Driven red: restoring antigravityUserAgent() fails the new test.
…ompted Two record errors. #1889 has two distinct failing checks, not four - four was the count of failing check runs across re-runs. And the audit's finding that #1891 sits 62 commits behind dev is itself stale: the live head 8123680 is 0 behind, so ticking alone is now sufficient. Keeping that as a lesson rather than deleting it, because the mechanism it named is real and would have made my advice wrong on a different day. The audit also asked whether anything here could be landed rather than held, and one thing could: metadata.ide_version was set to antigravityUserAgent(), the whole header, where the real client sends a bare version. Live on dev, independent of both PRs, and invisible because the request still succeeds. Fixed in #1955. That distinction is worth stating. I hold #1889 because reviewing someone else's auth change is the maintainer act the sponsorship label records - but a one-line auth fix I wrote and verified myself is precisely the case where a maintainer sponsors their own work.
Two corrections from the promotion audit. The closed table listed #1894, #1843 and #1899 as issues. #1899 is a pull request, so two issues closed this campaign, not three - the original phrasing overstated the run. And PR #1921's merge commit carries a failing hosted run. The failure is a wall-clock assertion in request-pacing, the classic flake shape on a loaded macOS runner, and every subsequent run on dev is green including the current head. Not a blocker, but it landed red and the record did not say so. A campaign record that omits the one merge that went in red is not one you can trust later. Also supersedes the no-green-run statement: run 32090176020 on 9eb3a10 is completed/success with every job green.
…ersion fix(antigravity): send a bare ide_version, not the whole User-Agent
fix(antigravity): align User-Agent token order and auth_method with 2.5.5 decompilation
fix(antigravity): send a bare ide_version + Wave 5 closeout record
#1891's hold expired four minutes after I wrote it - the author rebased and ticked all four boxes at 02:10:50Z - so it merged as 5c66ad2. Wave 5D is now down to #1889 alone, blocked on maintainer sponsorship. The full suite on the merged tree is 12805 pass, 10 skip, 1 fail. The failure is the Unix shim autostart test failing with status 126, permission denied on exec, and it is environmental rather than a regression: it reproduces solo, it fails identically at the pre-campaign baseline 1208bd2, and all four test shards passed in dev CI for 9eb3a10. The test writes a shim to a temp dir and spawnSyncs it; this sandbox blocks execution from that path. Recorded rather than skipped - the fix is an environment note, not a test change.
The autostart shim test deleted OCX_SHIM_ACTIVE_PID from the child environment but inherited OCX_SHIM_ACTIVE_DEPTH from the parent. A developer running the suite from a shell that was itself launched through an installed Codex shim carries DEPTH=1, so the outer shim started at depth 1 rather than 0, the child re-entry landed on depth 2, and the guard exited 126 with its launcher-loop message. The shim was behaving exactly as designed; the test was starting from a slate it believed was clean. CI never sees this because CI has no shimmed ancestor, which is precisely what made it look like a machine quirk. I had recorded the cause as the sandbox blocking execution from a temp path. That was wrong - a chmod 755 script in mktemp -d runs fine here and /var/folders is not mounted noexec - and a reviewer traced the real mechanism. The devlog now carries the correction, because a plausible-sounding wrong explanation in a durable record is worse than no explanation.
fix(test): sanitize both shim recursion-guard variables
The previous fix deleted both guard variables at one spawn site. A reviewer pointed out the class of bug survives: the nearby re-entry tests assert status 126, so an inherited depth offset leaves them passing for entirely the wrong reason, and the next test to spawn a shim starts the cycle again. shimChildEnv strips PID, DEPTH and PROBE_ACTIVE in one place, mirroring what probeUnixShimInstall already does before spawning its probe. The second spawn site at line 291 had the same gap - it deleted only the pid - so it was quietly depth-sensitive too. What this buys is that a green run means what it says. Before, these tests measured whatever shim ancestry the developer's shell happened to carry, and were green in CI only because CI has no shimmed ancestor.
test(codex): centralize shim recursion-guard sanitization
Contributor
|
✅ Deterministic PR hygiene checks passed. |
Contributor
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (64)
📝 WalkthroughWalkthroughWave 5 adds execution records and updates provider routing, model discovery, replay scoping, Cursor transport, Windows discovery, tool handling, FastWire characterization, and documentation. The changes include focused regression coverage across these areas. ChangesWave 5 execution records
Provider routing and discovery
Compatibility and replay
Cursor and tool flows
Codex and FastWire validation
Documentation
Estimated code review effort: 5 (Critical) | ~120 minutes ✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
changed the title
Contributor
⏳ DRAFT
What to do
Its title has been prefixed with |
This was referenced Aug 18, 2026
Owner
Author
|
Disclosure that belongs on this PR and landed on the wrong one. I opened #1958/#1959 as promotion PRs and put a detailed disclosure in their descriptions. This A campaign PR introduced a high-severity CodeQL alert, and it is now on
Severity in context: the input is a configured const trimmed = baseUrl.trim().replace(/(?<=[^/])\/+$/, "");Note it changes behaviour for an all-slashes input, and the same commit added a second Separately: |
4 tasks
Owner
Author
|
Disclosure that belongs in this PR body and was not there when it merged. This promotion carried a high-severity CodeQL alert the campaign itself introduced: #87, Fixed in #1966 and promoted to Root cause: CodeQL does not run on |
lidge-jun
added a commit
that referenced
this pull request
Aug 18, 2026
…e's fault My second explanation was also wrong. Dev is not scanned on push - its last analysis is from 8/15, default setup runs weekly, and 0be660a is not an ancestor of that commit, so the code was never in a dev scan. Dev's 84 alerts are stale rather than current, which is the opposite of what I said they showed. The real answer: github-advanced-security posted the finding as an inline review comment on #1959 at 02:38:08Z, and #1963 promoted at 02:55:04Z. It sat in the review thread of a promotion PR for seventeen minutes - while I was editing that same PR's description. Not a coverage gap. I did not read the review comments on a PR I was actively rewriting. Three explanations for one mistake. The first two blamed infrastructure; the third is true and the least comfortable, which is roughly how that tends to go.
lilinxiong
pushed a commit
to lilinxiong/opencodex
that referenced
this pull request
Aug 18, 2026
…rong PRs Dev reached preview and main through lidge-jun#1962 and lidge-jun#1963, not through the lidge-jun#1958 and lidge-jun#1959 I opened and left for a maintainer - those flipped to merged seconds later once their heads became reachable. So the disclosure I spent three audit rounds getting right sat on the two PRs that moved no code, and the two that actually promoted carried none of it. Fixed by commenting it onto lidge-jun#1962 and lidge-jun#1963 after the fact, which is later than it should have been. Worth naming the failure mode rather than just the fix: I attached the warning to the artifact I controlled rather than to the artifact that would carry the change. js/polynomial-redos is on main now. What I did not do and stand by: I never approved a promotion PR.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Promotion of the Wave 5 campaign from
dev. 107 commits.What landed, by wave:
Issues closed: #1894, #1843, #1899.
A few of these are worth naming because they were not in the original plan — they came out of
adversarial review of the plan itself:
execas Codex codemode, so a structured
exec, or anexecbeside a shell bridge, was told it takes JavaScript.Now decided from
freeformmetadata. fix(adapters): restore the un-namespaced requirement on the shell-bridge check #1953 then restored the!tool.namespaceguard my ownfix had dropped, which had let a namespaced MCP
exec_commandsilently suppress code-modeguidance.
metadata.ide_versionwas sending the entire User-Agent string where the realAntigravity client sends
2.5.5. Live ondev, invisible because the request still succeeds.OCX_SHIM_ACTIVE_DEPTHfrom the parentshell, so the recursion guard fired at 126 for anyone running the suite under an installed
shim. Green in CI only because CI has no shimmed ancestor.
Verification
On
devat87f7f970b:bun test --isolate tests— 12807 pass, 10 skip, 0 fail, 159387 expect() calls across 826 files (462s).bun run typecheck— passed.bun run privacy:scan— passed.Still open, deliberately
src/oauth/; the label records a security review, so not one an agent should apply.devlog/_plan/260817_wave5_execution/.Checklist
Summary by CodeRabbit
New Features
Bug Fixes
Documentation