Skip to content

Loopback listener rejects standalone image routes before the relay #3428

Description

@fwkyle

Client or integration

Codex App

Area

Proxy and routing

Summary

Codex App's built-in image_gen sends standalone image requests to the injected openai_base_url. When OpenCodex uses its managed unauthenticated loopback listener, POST /v1/images/generations and POST /v1/images/edits return OpenCodex's JSON 404 before reaching the existing image relay. I expected both exact POST routes to reach the relay, while other methods and image subpaths remain denied.

This is a follow-up to #83 / #87: the image relay exists, but the newer default-deny loopback allowlist does not include its two client-side routes. It is the same listener-boundary failure mode fixed for native web search in #3192 / #3205.

Reproduction

  1. Install OpenCodex 2.41.0 and run it as a service with the managed loopback listener on port 10101.

  2. Confirm Codex is injected with openai_base_url = "http://127.0.0.1:10101/v1".

  3. Run:

    curl -X POST -H 'content-type: application/json' --data '{}' http://127.0.0.1:10101/v1/images/edits

  4. Observe OpenCodex's own 404 Unknown endpoint response.

  5. As a control, GET /v1/models on the same listener returns 200, and after 2.41.0 POST /v1/alpha/search passes the allowlist and reaches its handler.

Source inspection confirms that src/server/index.ts registers the exact POST Images handlers after the listener gate, while loopbackRouteAllowed omits both paths.

Version

2.41.0

Operating system

macOS 26.5.2 (25F84), Apple Silicon

Provider and model

ChatGPT forward provider; provider/model independent because the request is rejected before routing.

Logs or error output

{"error":{"message":"Unknown endpoint: POST /v1/images/edits","type":"not_found","code":"not_found"}}
HTTP 404

Screenshots and supporting files

None.

Redacted configuration

{
  "unauthenticatedLoopbackListener": {
    "enabled": true,
    "port": 10101
  }
}

Codex root configuration contains the redacted route only:

openai_base_url = "http://127.0.0.1:10101/v1"

Checks

  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.

Activity

  1. added
    bugSomething isn't working
    proxyHTTP proxy, routing, reverse-proxy / management auth
    toolstool_calls, MCP, web-search / sidecar tools
    on Sep 4, 2026
  2. lidge-jun commented on Sep 4, 2026

    @lidge-jun
    Owner

    리뷰 · 우선순위 71 / 80

    설명

    이 이슈는 Codex App의 내장 image_gen이 OpenCodex가 주입한 openai_base_url(보통 루프백 10101)으로 POST /v1/images/generations·POST /v1/images/edits를 보낼 때, 관리형 비인증 루프백 리스너가 요청을 이미지 릴레이까지 보내지 못하고 자체 JSON 404를 내는 버그입니다. 재현이 짧고 명확합니다. curl로 edits를 치면 Unknown endpoint: POST /v1/images/edits가 나오고, 같은 리스너에서 GET /v1/models는 200, 2.41.0 이후 POST /v1/alpha/search는 핸들러까지 갑니다.

    현재 dev(072df52eb)를 보면 원인 진단이 맞습니다. src/server/index.ts의 loopbackRouteAllowed는 default-deny 허용 목록이고, 이미지 POST 두 경로가 빠져 있습니다. 그런데 같은 파일의 공개 요청 경로는 이미 그 pathname으로 이미지 핸들러를 태웁니다. 즉 “릴레이는 있는데 루프백 문이 잠겨 있다”는 #83/#87 이후의 후속 구멍이고, #3192/#3205의 웹검색과 같은 실패 모드입니다. 설정 예시도 unauthenticatedLoopbackListener.enabled + 주입된 base URL이라 실제 Codex App 경로와 맞습니다.

    이미 수정 PR이 있습니다. #3430(fix(server): allow image routes on loopback listener)이 정확히 이 두 POST만 허용하고, 통합 테스트로 루프백은 핸들러까지·공개는 401을 검증합니다. 이슈 본문의 기대(“정확한 POST만 통과, 다른 메서드·하위 경로는 거부”)와도 한 줄로 맞습니다. 그래서 이 이슈의 다음 단계는 새 패치를 또 받는 것이 아니라 #3430 머지입니다.

    우선순위 71은 제품에서 Codex App 이미지 도구가 바로 깨지는 실제 버그이고, 수정 범위도 이미 좁게 잡혔다는 뜻입니다. 조사만 남는 상태의 아닙니다.

    경로 src/server/index.ts loopbackRouteAllowed - HEAD에 이미지 POST가 없습니다. 이슈 진단과 일치합니다.
    경로 #3430 - 이 이슈를 Closes로 묶은 수정 PR입니다. 중복 패치 PR을 열지 마세요.
    경로 #3192 / #3205 - 같은 리스너 허용 목록 선례입니다. 새 설계가 아니라 빠진 항목 추가입니다.
    경로 공개 리스너 API 키 - 이 이슈는 루프백만 말합니다. 공개 쪽까지 풀라는 요청이 아닙니다.

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

    • #3430을 바로 머지할지, gates 전체 초록만 더 기다릴지
    • 2.41.x 핫픽스 노트에 이 회귀를 명시할지

    너의 추천
    새 코드 PR을 받지 말고 #3430을 머지해 이 이슈를 닫으세요. 진단·재현·수정 PR이 이미 한 줄로 연결돼 있습니다.

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

  3. lidge-jun commented on Sep 4, 2026

    @lidge-jun
    Owner

    Fixed by #3430, squash-merged into dev as 4b53e10.

    The loopback allowlist now admits POST /v1/images/generations and POST /v1/images/edits as exact paths, so the Codex App image tools reach the relay instead of the listener's own 404. The public listener stays credential-gated and other methods and sub-paths remain denied; tests/loopback-listener-integration.test.ts covers both routes, the public-listener 401, and the rejected methods.

    Closing manually: these pull requests target dev, and GitHub only auto-closes linked issues when a PR merges into the default branch.

    Thanks @ChickenBreast-ky.

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

    bugSomething isn't workingproxyHTTP proxy, routing, reverse-proxy / management authtoolstool_calls, MCP, web-search / sidecar tools

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions