Skip to content

[Feature]: Allow /v1/alpha/search to use a configured web-search backend without ChatGPT forward auth #2730

Closed
Closed
[Feature]: Allow /v1/alpha/search to use a configured web-search backend without ChatGPT forward auth#2730
Labels
account-poolOAuth, credentials, Codex pool, quota, failover, plansenhancementNew feature or requesttoolstool_calls, MCP, web-search / sidecar tools

Description

@canbetry
canbetry
opened on Aug 27, 2026

Area

Tools / MCP / web search

What are you trying to accomplish?

Use Codex App or Codex CLI built-in web search while model requests continue to use an OpenCodex routed or API-key provider. The main model route should not require a canonical ChatGPT forward provider solely to make built-in search work.

What prevents this today?

With OpenCodex 2.33.0 on Windows 11:

  1. Start OpenCodex on port 10100.

  2. Configure Codex with:

    openai_base_url = "http://127.0.0.1:10100/v1"
web_search = "live"

  3. Configure a routed/API-key model provider in OpenCodex, without a canonical ChatGPT forward provider.

  4. Trigger Codex built-in web search.

Codex sends POST /v1/alpha/search, and OpenCodex returns HTTP 400:

Built-in web search needs a ChatGPT forward provider, but none is configured in opencodex. Routed and OpenAI API-key providers cannot serve /v1/alpha/search.

The same limitation remains on main: handleSearch() calls listOpenAiForwardSidecarCandidates(config) and fails before considering any configured web-search sidecar or API-key route.

What should OpenCodex do?

Preserve the current verbatim relay when a canonical ChatGPT forward provider is available. When it is not, allow /v1/alpha/search to use a configured and active web-search backend, then adapt that backend's result to the response shape expected by the Codex built-in search client.

For an OpenAI API-key provider that supports hosted search, one possible fallback is to call the public Responses API with tools: [{ "type": "web_search" }] and adapt the answer and citations. Existing Anthropic, xAI, Gemini, or Exa sidecar executors could be alternative backends where configured.

If the selected backend cannot provide search, return a backend-specific diagnostic rather than requiring ChatGPT auth unconditionally.

Example usage or interface

# Codex continues to send model and built-in search traffic through OpenCodex.
openai_base_url = "http://127.0.0.1:10100/v1"
web_search = "live"

Expected flow:

Codex POST /v1/alpha/search
  -> OpenCodex configured web-search backend
  -> normalized alpha/search response with source citations

The routed/API-key provider remains the main model provider; adding ChatGPT OAuth should not be mandatory.

Alternatives or workarounds

  • Add a canonical ChatGPT OAuth forward provider only for search. This works but does not support an API-key-only deployment.
  • Use an external MCP search tool or direct HTTP fetching. These do not restore Codex's built-in web-search path.
  • Maintain a local patch to src/server/search.ts.

Additional context

Checks

  • I searched existing issues and documentation.
  • This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
  • I removed secrets and personal data.

Activity

  1. github-actions
    added
    enhancementNew feature or request
    account-poolOAuth, credentials, Codex pool, quota, failover, plans
    toolstool_calls, MCP, web-search / sidecar tools
    on Aug 27, 2026

  2. lidge-jun commented on Aug 27, 2026

    @lidge-jun
    lidge-jun
    on Aug 27, 2026
    Owner

    리뷰 · 우선순위 48 / 80

    지금 dev HEAD는 7547c8937이다. src/server/search.ts handleSearch 라인 96-103은 이슈가 말한 그대로다. listOpenAiForwardSidecarCandidates(config)가 비면 바로 400을 낸다. 메시지 문장도 이슈 본문과 같다. "라우트된 제공자와 OpenAI API 키 제공자는 /v1/alpha/search를 켤 수 없다." 파일 맨 위 라인 1-9 주석도 ChatGPT 포워드만 그대로 중계한다고 못 박는다. Codex가 web_search = "live"이고 openai_base_url이 이 프록시인데, ChatGPT 포워드 제공자가 없으면 내장 검색은 현재 dev에서 반드시 그 400으로 죽는다.

    이슈가 적은 OpenCodex 2.33.0은 이 체크아웃의 package.json 버전 2.32.1-preview.20260825와 다르다. 동작은 search.ts가 같으면 버전 숫자와 상관없이 같다. 관련으로 적은 #2188은 이미 닫혔다. 그 이슈는 모델 턴의 웹검색/비전 사이드카를 고르는 규칙을 묶은 것이다. /v1/alpha/search를 ChatGPT가 아닌 백엔드로 바꿔 주는 일이 아니다. 그래서 #2188을 이 이슈의 구현으로 보면 안 된다.

    원하는 일은 새 계약이다. Codex 클라이언트가 POST /v1/alpha/search로 기대하는 JSON 모양과, 공개 Responses tools: [{type:"web_search"}] 결과와, Anthropic/xAI/Gemini/Exa 사이드카 결과는 서로 다르다. ChatGPT 포워드가 있을 때는 지금처럼 그대로 중계해야 한다. 없을 때 어떤 백엔드를 어떤 순서로 쓰고, 인용을 어떻게 맞추고, 백엔드가 검색을 못 하면 어떤 에러를 줄지는 설계가 먼저다. API 키만 있는 배포에서 내장 검색이 죽고 ChatGPT 로그인을 강요하는 것은 운영자 고통이 맞다. 하지만 "그냥 Responses web_search를 부르면 된다"는 패치로 지금 search.ts만 열 일이 아니다.

    types.ts/config.ts 분할 캠페인 때문에 이 이슈를 닫을 이유는 없다. search.ts는 그 분할의 핵심 파일이 아니다. 미리보기 배포는 이 계획에 없다. 중복으로 보이는 열린 이슈는 이 번호대에서 찾지 못했다.

    라인 단위로 보면 현재 dev와 비교해서 이런 점이 남는다.

    라인 search.ts 96-103 - ChatGPT 포워드 후보가 없으면 설정된 웹검색 백엔드를 보지 않고 바로 400이다. 이슈가 고치길 원하는 가드 그 자체다.

    라인 search.ts 144 - 업스트림 URL이 항상 baseUrl + "/alpha/search"다. Responses /v1/responses나 다른 사이드카 실행기로 가는 분기가 없다.

    라인 search.ts 56-60 - 검색 요청도 포워드 입장 자격 검사를 먼저 한다. 백엔드를 바꿔도 이 입장 규칙을 같이 다시 정해야 한다.

    경로 #2188 - 닫힌 사이드카 고르기 이슈다. 이 이슈의 대체 구현이 아니다. 본문이 관련 작업으로 적었을 뿐이다.

    메인테이너의 판단이 필요한 지점

    • ChatGPT 포워드가 없을 때 내장 검색을 살릴 가치가 있는지. API 키만 있는 배포를 공식 지원할지의 제품 결정이다.
    • 살릴 때 백엔드 순서. OpenAI API 키 hosted web_search인지, 이미 있는 사이드카인지, 설정 키를 새로 둘지.
    • Codex alpha/search 응답 모양을 우리가 흉내 내는 것이 허용되는지. 사설 엔드포인트라서 깨지기 쉽다.
    • 지금 구현을 받을지, 설계 이슈로 열어 둘지.

    너의 추천
    이 이슈는 열어 둔다. 지금 search.ts를 고치는 PR은 받지 않는다. 먼저 짧은 설계가 필요하다. ChatGPT 포워드가 있으면 지금 중계를 유지한다. 없을 때만 설정된 웹검색 백엔드를 쓰고, 그 백엔드가 검색을 못하면 ChatGPT 로그인 강요가 아닌 백엔드 이름과 이유를 400/502로 돌린다. 응답 모양은 Codex 클라이언트가 깨지지 않게 최소 필드만 맞춘다. 미리보기 배포와 버전 태그는 하지 않는다.

    이 댓글은 grok-bot이 작성했습니다

  3. lidge-jun commented on Sep 14, 2026

    @lidge-jun
    lidge-jun
    on Sep 14, 2026
    Owner

    Fixed on dev by 2e6a031.

    /v1/alpha/search now has a fallback path: when there is no ChatGPT forward candidate, the request is served by an explicitly configured webSearchSidecar backend using that backend's own credential, so the endpoint works without ChatGPT forward auth.

    It fails closed rather than open, which was the part worth getting right. An unset backend, a disabled sidecar, a backend of openai, or a missing credential all refuse instead of silently reaching for something else, and there is an explicit test that the ChatGPT relay path is untouched whenever a forward candidate does exist. Secrets are redacted from the diagnostics.

    One caveat recorded honestly: the response envelope is a best-effort match to an alpha shape that is not published, so acceptance by a live Codex client has not been verified end to end. If you hit a rejection from the client side, please reopen with the error and it can be shaped against the real envelope.

  4. lidge-jun
    closed this as completedon Sep 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    account-poolOAuth, credentials, Codex pool, quota, failover, plansenhancementNew feature or requesttoolstool_calls, MCP, web-search / sidecar tools

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions