Repository navigation
Bug: model aliases are not reflected in Codex picker display names #2959
Description
Activity
- addedbugSomething isn't workingSomething isn't workingcatalogModel catalog, slugs, visibility, routed entriesModel catalog, slugs, visibility, routed entries
on Aug 30, 2026 리뷰 · 우선순위 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입니다. 정식 슬러그, 업스트림 모델 아이디, 라우팅, 사용량 키는 그대로 두고, 화면에 보이는 이름만 별칭이기를 원합니다.지금
devHEAD는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/modelsalias_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이 작성했습니다
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/modelid. The original feature explicitly expected the picker to show the provider-qualified alias.The catalog path never consumes
effectiveModelAliases(): routed rows reach catalog generation withoutCatalogModel.displayName, sodisplay_namefalls back to the canonical slug./v1/models.alias_ofdoes not fix this because Codex App reads the shared catalog / app-servermodel/listdisplay metadata.Expected: the picker displays the qualified effective alias (for example
google-antigravity/gemini-3.7orcursor/grok) while the canonical slug, upstream model id, routing target, usage keys, and persisted selectors remain unchanged.Reproduction
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" } } } }Sync/restart OpenCodex so it converges the Codex catalog.
Open the Codex App model picker.
Observe
google-antigravity/gemini-3.7-flashinstead ofgoogle-antigravity/gemini-3.7.A deterministic current-
devreproduction also callsgatherRoutedModels()followed bybuildCatalogEntries()and observes:The routing slug remains
google-antigravity/gemini-3.7-flashin both cases.Version
2.35.0 and current
devcommit47b8d164366b9db9e4331b2bb8b542db22766910Operating 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_namemetadata.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