Repository navigation
[Bug]: ocx models/provider live subcommands print management API unavailable then exit 0 #2697
Description
Client or integration
Codex App / OpenCodex CLI
Area
CLI
Summary
On a loopback install whose management plane is 503 (management API unavailable, #2696), several live subcommands print the error and then exit 0. Scripts and agents treat them as success.
ocx account list, ocx grok status, ocx agent status, ocx combo list, ocx observe memory, ocx system status, ocx access endpoints, ocx export, and ocx integration * correctly exit 1 on the same 503.
This is a CLI dispatch bug, not the token-collision fail-close. #2696 is the trigger; this ticket remains after that 503 exists (and after it is fixed, any other management 503 would still be swallowed).
Reproduction
macOS launchd proxy on 127.0.0.1:10100, management plane 503 as in #2696.
ocx models selected xai; echo EXIT:$?
ocx models live --provider xai --json; echo EXIT:$?
ocx models context status; echo EXIT:$?
ocx provider selected xai --json; echo EXIT:$?
ocx account list; echo EXIT:$?Observed (2.33.0):
Error: management API unavailable
EXIT:0
...
Error: management API unavailable
EXIT:1 # account list
Version
2.33.0 (@bitkyc08/opencodex)
Operating system
macOS 15.7.4
Logs or error output
dispatch.ts always returns 0 for models/provider after awaiting the handler:
provider: async deps => {
await handleProviderCommand(deps.args.slice(1));
return 0;
},
models: async deps => {
await handleModels(deps.args.slice(1));
return 0;
},account correctly returns cmdAccount's code. runCliAction already returns 1 for RuntimeApiError; models/provider dispatch throws that away.
Checks
- I searched existing issues and documentation.
- I removed secrets, tokens, account details, request credentials, and personal data.
Related: #2696 (management plane fail-closed; do not fold this into it).
Activity
lidge-jun commentedon Aug 26, 2026
리뷰 · 우선순위 76 / 80
설명
이 이슈는 관리면이 503 일 때
ocx models selected/ocx models live/ocx provider selected같은 live 하위 명령이 에러를 출력한 뒤에도 프로세스 종료 코드 0 으로 끝나는 버그를 보고합니다.ocx account list등은 같은 503 에서 exit 1 입니다. 트리거는 #2696 의 management 503 이지만, 이 티켓은 503 이 고쳐진 뒤에도 다른 관리면 실패를 성공으로 삼키는 CLI 디스패치 버그로 남습니다.current
devHEADee182a1e0을 보면 원인은 두 겹입니다.src/cli/models-runtime.ts의handleModelsRuntimeCommand는runCliAction을 통해RuntimeApiError때 1 을 반환하고,src/cli/models.ts431-434줄은 그 값을process.exitCode에 넣습니다. 그런데src/cli/dispatch.ts428-431줄models러너는await handleModels(...); return 0;이라서 상위process.exit(await dispatchCommand(...))가 exitCode 를 0 으로 덮어씁니다.provider러너(419-422줄)도 같은 패턴입니다. 반대로account는return await cmdAccount(...)로 실제 코드를 전달합니다.재현 설명과 HEAD 코드가 일치합니다. 패키지 표기 2.33.0 과 checkout
package.json2.32.1-preview.20260825 차이는 경로 버그와 무관합니다. 스크립트·에이전트가 성공으로 오판하면 운영 사고가 납니다.types.ts/config.ts분할로 닫을 대상이 아닙니다. 미리보기 배포는 계획에 없습니다.src/cli/dispatch.ts:428 - models 러너가 항상 return 0 이라 exitCode 1 이 버려집니다
src/cli/dispatch.ts:419 - provider 러너도 같은 return 0 패턴입니다
src/cli/models.ts:431 - handleModelsRuntimeCommand 코드는 exitCode 에 넣지만 상위가 덮습니다
src/cli/runtime-api.ts:321 - runCliAction 은 RuntimeApiError 에 1 을 이미 반환합니다
경로/심볼 - account/combo 등 성공 코드를 반환하는 명령과 불일치합니다
메인테이너의 판단이 필요한 지점
너의 추천
열어 두세요. current
dev에서 재현 가능한 고심각도 CLI 버그입니다. 수정 PR 은dispatch.tsmodels/provider 가process.exitCode또는 핸들러 반환값을 그대로 반환하게 하고, 관리면 503 픽스처로 exit!=0 회귀를 넣으세요. #2696 과 함께 다루되 이 티켓은 별도로 닫지 마세요. 미리보기 배포는 계획에 없습니다.이 댓글은 grok-bot이 작성했습니다
fix(cli): make the transport fixes reachable and cover tray
Merge pull request #2775 from lidge-jun/codex/ocx-transport-honesty
fix(cli): stop the CLI reporting success for failed management calls
fix(cli): make the transport fixes reachable and cover tray
Merge pull request lidge-jun#2775 from lidge-jun/codex/ocx-transport-…
fix(cli): stop the CLI reporting success for failed management calls
fix(cli): make the transport fixes reachable and cover tray
Merge pull request lidge-jun#2775 from lidge-jun/codex/ocx-transport-…