fix(responses): capability-gate external_web_access in the canonical-only table - #2262
Merged
Conversation
…only table The #2258 series unconditional strip collided with the #2238 capability contract: official OpenAI API-key traffic lost external_web_access (lidge full suite 1/14025 fail). The table row is now capabilityGated, active only when supportsOpenAiWebSearchToolFields === false; defer_loading stays unconditional. 387/0 across six suites.
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 (2)
📝 WalkthroughWalkthroughThe request sanitizer now preserves ChangesTool field sanitization
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: ✨ Finishing Touches📝 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 |
This was referenced Aug 21, 2026
Merged
olddonkey
pushed a commit
to olddonkey/opencodex
that referenced
this pull request
Aug 21, 2026
…der config Routed Grok turns on the Responses lane died with `400 Argument not supported: external_web_access` before inference. routedProviderConfig() backfills every other registry-only scalar (supportsServiceTier, preserveResponsesReasoningContent, fastWire) but not supportsOpenAiWebSearchToolFields. enrichProviderFromRegistry() does fill it, and the request path never calls that function -- so a saved xai row reached the Responses adapter with the flag undefined. The lidge-jun#2262 capability gate reads undefined as "unclassified upstream, keep the fields", so Codex's OpenAI-only web_search config went to the wire and xAI rejected the whole request. Live probe against the OAuth Grok endpoint (2026-08-21) isolates the cause: bare {type:"web_search"} returns 200, +external_web_access returns 400, and +search_context_size returns 400 -- individually, before inference. Verified end-to-end on a remote macOS host running this dev head: with the GUI Responses opt-in on and NO hand-written capability in config.json, a multi-step codex exec tool-use turn now completes over adapter "openai-responses" with status 200, where the same turn 400'd before. The existing tests could not catch this: they hand-build a provider with the flag already set, or call enrichProviderFromRegistry() directly, so both start downstream of the break. The new tests assert on routedProviderConfig() output and were driven red against the unfixed router.
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
1 participant
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
Post-merge reconciliation between #2238 and #2258: the consolidated series' unconditional CANONICAL_ONLY_TOOL_FIELDS strip removed
external_web_accessfrom official OpenAI API-key traffic, breaking #2238's capability contract (caught by the lidge full-suite lagging gate: 1 fail / 14025).external_web_accessin the declarative table is nowcapabilityGated: true: stripped only when the provider declaressupportsOpenAiWebSearchToolFields: false(the xAI registry entry does), matchingstripOpenAiOnlyWebSearchFieldsownership.defer_loadingstays unconditional (private on any tool for every noncanonical gateway).Verification
Checklist
Summary by CodeRabbit