Skip to content

Bug: model aliases are not reflected in Codex picker display names #2959

Description

@terrytan95

Client or integration

Codex App

Area

Catalog / models

Summary

Provider and model aliases added by #2463 / PR #2610 resolve requests correctly, but the Codex model picker still shows each routed model's full canonical provider/model id. The original feature explicitly expected the picker to show the provider-qualified alias.

The catalog path never consumes effectiveModelAliases(): routed rows reach catalog generation without CatalogModel.displayName, so display_name falls back to the canonical slug. /v1/models.alias_of does not fix this because Codex App reads the shared catalog / app-server model/list display metadata.

Expected: the picker displays the qualified effective alias (for example google-antigravity/gemini-3.7 or cursor/grok) while the canonical slug, upstream model id, routing target, usage keys, and persisted selectors remain unchanged.

Image Image Image

Reproduction

  1. Configure a static routed model and a model alias:

    {
      "providers": {
        "google-antigravity": {
          "adapter": "google",
          "liveModels": false,
          "models": ["gemini-3.7-flash"],
          "modelAliases": { "gemini-3.7-flash": "gemini-3.7" }
        }
      }
    }
  2. Sync/restart OpenCodex so it converges the Codex catalog.

  3. Open the Codex App model picker.

  4. Observe google-antigravity/gemini-3.7-flash instead of google-antigravity/gemini-3.7.

A deterministic current-dev reproduction also calls gatherRoutedModels() followed by buildCatalogEntries() and observes:

actual display_name:   google-antigravity/gemini-3.7-flash
expected display_name: google-antigravity/gemini-3.7

The routing slug remains google-antigravity/gemini-3.7-flash in both cases.

Version

2.35.0 and current dev commit 47b8d164366b9db9e4331b2bb8b542db22766910

Operating system

macOS 27.0 (26A5421a)

Provider and model

google-antigravity / gemini-3.7-flash; the same gap affects explicit and built-in aliases on other routed providers.

Logs or error output

No runtime error. Alias routing succeeds; only the Codex catalog display_name is wrong.

Screenshots and supporting files

The Codex picker shows native Luna/Sol marketing labels but full canonical ids for routed providers. Luna/Sol are not evidence that aliases work: those native rows already carry upstream display_name metadata.

Redacted configuration

{
  "defaultModelAliases": true,
  "providers": {
    "google-antigravity": {
      "defaultAliases": false,
      "modelAliases": {
        "gemini-3.7-flash": "gemini-3.7"
      }
    },
    "fireworks": {
      "modelAliases": {
        "accounts/fireworks/models/glm-5p3-flash": "GLM-5.3-Flash"
      }
    }
  }
}

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
    catalogModel catalog, slugs, visibility, routed entries
    on Aug 30, 2026
  2. lidge-jun commented on Aug 30, 2026

    @lidge-jun
    Owner

    리뷰 · 우선순위 65 / 80

    설명

    이 이슈는 별칭(alias)으로 요청은 잘 가는데, Codex 앱 모델 고르는 화면에는 짧은 별칭이 안 나오고 긴 정식 아이디가 나온다는 말입니다. 예시는 google-antigravity의 gemini-3.7-flash를 gemini-3.7로 줄여 둔 설정입니다. 요청은 gemini-3.7로 잘 붙는데, 피커에는 google-antigravity/gemini-3.7-flash가 보입니다. 기대한 글자는 google-antigravity/gemini-3.7입니다. 정식 슬러그, 업스트림 모델 아이디, 라우팅, 사용량 키는 그대로 두고, 화면에 보이는 이름만 별칭이기를 원합니다.

    지금 dev HEAD는 b95dc5d42입니다. 방금 올라온 것은 테스트 락을 사용자 런타임으로 좁힌 #2962이고, 카탈로그 표시 경로는 그대로입니다. 별칭 계산은 src/providers/default-aliases.ts의 effectiveModelAliases가 합니다. 사용자가 modelAliases에 적은 값이 먼저 들어가고, defaultModelAliases / defaultAliases가 켜져 있으면 내장 규칙(gemini-3-flash → g3f, grok-4 → grok 같은 것)도 붙습니다. 요청이 들어올 때 이 맵으로 별칭을 정식 아이디로 바꿉니다. 그 부분은 #2463 / #2610 이후 HEAD에서 동작합니다.

    그런데 Codex 앱이 읽는 쪽은 그 맵이 아닙니다. 열린 호환 목록 /v1/models(src/server/index.ts)는 별칭이 있으면 alias_of 칸에 프로바이더별칭/모델별칭을 넣습니다. 이슈가 말한 대로 Codex 앱 피커는 이 칸을 안 봅니다. 피커는 카탈로그 동기화와 앱 서버 model/list의 display_name을 봅니다. 그 display_name을 채우는 곳은 src/codex/catalog/effort.ts의 applyCatalogModelMetadata입니다. CatalogModel.displayName이 있을 때만 슬러그 대신 그 글자를 넣습니다. 주석도 분명히 말합니다. 이 칸은 화면용이고, 라우팅 슬러그는 안 바꿉니다. 네이티브 행(Luna/Sol 마케팅 이름)은 CatalogModel이 없는 업스트림 스냅샷 길이라, 별칭이 먹힌 증거가 아닙니다.

    지금 gatherRoutedModelsUncached(src/codex/catalog/provider-fetch.ts)는 라우티드 행을 모을 때 effectiveModelAliases를 안 부릅니다. displayName이 붙는 경우는 커스텀 모델이 직접 이름을 준 때, 또는 네이티브 능력 별칭이 Daybreak Blue를 넣는 때뿐입니다. 그래서 이슈의 재현(gatherRoutedModels 다음 buildCatalogEntries)에서 display_name이 정식 슬러그로 남는 것은 HEAD에서 재현됩니다. 회귀가 아니라, 별칭 기능이 요청 경로만 완성되고 카탈로그 표시는 빠져 있는 상태입니다.

    같은 작성자의 드래프트 #2960이 이 구멍을 displayName에 별칭을 넣는 쪽으로 메우려 합니다. types.ts/config.ts 대분할과 겹치는 수정이 아니고, 미리보기 배포도 필요 없습니다. 패키지 버전은 2.36.0 그대로입니다.

    src/codex/catalog/provider-fetch.ts gatherRoutedModelsUncached - 라우티드 모델을 모은 뒤 effectiveModelAliases를 CatalogModel.displayName에 안 넣습니다. 피커 display_name이 정식 슬러그로 떨어집니다.

    src/codex/catalog/effort.ts applyCatalogModelMetadata - 화면용 덮어쓰기 칸은 이미 있습니다. 별칭 맵이 여기로 안 흘러 와서, 칸만 있고 값이 없습니다.

    src/server/index.ts /v1/models alias_of - 열린 호환 목록에는 별칭이 있습니다. Codex 앱 피커가 읽는 카탈로그 display_name과는 다른 문입니다.

    src/codex/catalog/parsing.ts CatalogModel.displayName - 네이티브 마케팅 이름과 라우티드 별칭은 길이 다릅니다. Luna/Sol이 예쁘게 보이는 것은 별칭 기능이 피커까지 온 증거가 아닙니다.

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

    • 피커에는 별칭만 보여주고 라우팅 아이디는 정식 슬러그로 둘지(이슈·#2960의 방향).
    • 사용자가 적은 별칭만 보여줄지, 내장 기본 별칭(cursor/grok 같은 것)도 같이 보여줄지.
    • #2960이 드래프트를 벗고 테스트를 닫을 때까지 기다릴지, 메인테이너 캐리로 먼저 넣을지.

    너의 추천

    이슈를 열어 두세요. HEAD에서 재현되는 표시 구멍이고, 닫을 중복이 아닙니다. 고침은 #2960이 올바른 자리(gatherRoutedModels → displayName → display_name)를 건드리고 있으니, 그 PR이 준비되면 거기로 닫으면 됩니다. 지금 드래프트라 이슈만 먼저 닫지 마세요.

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

  3. lidge-jun commented on Aug 31, 2026

    @lidge-jun
    Owner

    Landed via #2960 at 0892b99

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 workingcatalogModel catalog, slugs, visibility, routed entries

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions