[Bug][Windows] Prompt probe misses Codex App runtime and base prompt source

[S0RYUASUKA]

Client or integration

OpenCodex dashboard

Area

Platform (Windows / macOS / Linux)

Summary

On Windows, the Codex prompt probe can report Codex program not found even when Codex is installed by the Codex App. The installed executable is under the stable product root %LOCALAPPDATA%\OpenAI\Codex\bin\<changing-version>\codex.exe, while the prompt probe only checked fixed POSIX paths. The probe also did not expose the selected model's published base prompt in its response.

Reproduction

1. Install Codex on Windows through the Codex App.
2. Start the OpenCodex service in the normal Windows service flow.
3. Call the prompt-text probe through the existing Codex prompt management endpoint.
4. Observe Codex program not found, although the Codex executable exists below %LOCALAPPDATA%\OpenAI\Codex\bin.
5. The response has no selected-model base prompt source or representation metadata.

Expected:

• The probe should resolve the installed Codex executable using the shared runtime-discovery rules, including the Windows installation root and the inherited Windows PATH.
• The prompt response should identify the selected model and source file, return the complete published base prompt, and distinguish expanded text from an unexpanded template.
• Probe failures should distinguish program not found, unsupported command, execution failure, and invalid output.

Actual:

• The probe reports repeated path does not exist candidates and stops before invoking the installed Windows Codex executable.
• The base prompt is absent from the probe response even when the selected model catalog contains base_instructions.

Version

• OpenCodex: local production reproduction on 2.52.0; candidate verification is based on current dev at dc33113a9e6f5597ef9b2eecd692d7dc4b28dbd3 (package version 2.53.0).
• Codex CLI: codex-cli 0.154.0-alpha.6.2.

Operating system

Windows (local reproduction; exact version omitted for privacy)

Provider and model

Not provider-specific.

Logs or error output

• Codex is installed below %LOCALAPPDATA%\OpenAI\Codex\bin\<changing-version>\codex.exe.
• The selected model catalog contains a base_instructions entry for the active model.

Screenshots and supporting files

No screenshot is included because this change does not modify the GUI.

Redacted configuration

• No account tokens, user names, or machine-specific absolute paths are included here.

Checks

The candidate fix was verified locally without a paid model request. Focused backend tests, type checking, privacy scanning, and diff whitespace checks passed. The broad changed-test run timed out at the local 240-second runner limit with 8,692 passed and 172 failures across unrelated provider/network, account-pool, management/API, and lab suites; it is not represented as upstream CI evidence. The candidate's prompt-probe and runtime tests passed in that run. This report is limited to the backend prompt-probe and runtime path; it does not propose GUI changes.

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[lidge-jun]

리뷰 · 우선순위 58 / 80

설명

이 이슈는 Windows에서 Codex 프롬프트 프로브가 Codex App으로 설치한 실행 파일을 못 찾고, 선택된 모델의 게시된 base prompt도 응답에 안 실어 주는 문제를 말합니다. 재현 경로는 대시보드의 Codex 프롬프트 관리 엔드포인트입니다. Windows에 Codex App을 깔면 실행 파일이 %LOCALAPPDATA%\OpenAI\Codex\bin\<버전>\codex.exe 아래에 생기는데, 프로브는 그걸 못 보고 Codex program not found 쪽 실패로 끝납니다.

지금 dev HEAD(04d060efd, 패키지 2.53.0, 방금 문서 PR #4463까지 포함)를 보면 원인이 코드에 그대로 있습니다. src/codex/prompt-text-probe.ts의 resolveCodexBinary()는 홈 아래 POSIX 경로 네 개만 검사합니다(~/.codex/packages/standalone/current/bin/codex, ~/.local/bin/codex, /usr/local/bin/codex, /opt/homebrew/bin/codex). Windows Codex App 루트나 서비스가 물려받은 PATH 탐색이 없습니다. 같은 파일 머리주석도 codex debug prompt-input이 base_instructions를 버리고 prompt.input만 돌려준다고 명시합니다. 그래서 카탈로그에 base_instructions가 있어도 프로브 응답에는 base prompt 원본/출처가 빠지는 설계입니다.

런타임 쪽은 이미 더 넓은 발견기가 있습니다. src/codex/runtime.ts는 후보를 순위 매기고, 없는 절대 경로를 path does not exist(PATH_MISSING_REASON)로 분류합니다. 프롬프트 프로브만 그 공유 해석기를 안 쓰고 짧은 로컬 후보 목록을 쓰는 상태라, Windows App 설치본이 서비스 프로세스에서 보이더라도 프로브만 놓칩니다. 이슈가 기대한 세 가지는 (1) 공유 runtime discovery로 실행 파일 찾기, (2) 선택 모델의 base prompt 원본·출처·확장/템플릿 구분, (3) program-not-found / unsupported / execution / invalid-output 실패 분류입니다.

이미 고치는 PR이 열려 있습니다. #4461 fix(codex): read base prompt source on Windows 가 이 이슈를 Fixes로 걸고, 공유 runtime resolver 재사용·Windows Codex App bin 탐색·서비스 wrapper PATH 보존·base prompt 메타데이터 노출을 목표로 합니다. 다만 Draft이고 review gate 체크리스트가 비어 있어 바로 merge 대상은 아닙니다. 이슈 자체는 재현·기대·버전(2.52.0 재현, 후보 검증은 dev dc33113a9/2.53.0)·라벨(bug/catalog/platform)이 충분합니다.

현재 dev 방향(Remote Workspace·quota·Devin 캐시/effort·오디오·문서화된 36-PR 레인 머지)과 겹치지 않는 독립 Windows/플랫폼 버그입니다. types.ts/config.ts 분할 캠페인에 무효화될 변경도 아닙니다.

라인 90-97 - resolveCodexBinary()가 POSIX 고정 경로만 보고 Windows %LOCALAPPDATA%\OpenAI\Codex\bin\...\codex.exe와 PATH 상속을 안 본다
라인 11-12 - 파일 주석이 base_instructions 부재를 인정한다. 카탈로그에 값이 있어도 프로브 응답에 base prompt 원본/출처가 안 실린다
src/codex/runtime.ts PATH_MISSING_REASON - 공유 런타임은 path does not exist로 후보를 분류하는데 프로브는 이 해석기를 안 써서 Windows App 설치본을 놓친다
src/server/management/codex-prompt-routes.ts - 프롬프트 관리 엔드포인트가 위 프로브에 의존하면 Windows에서 program-not-found와 base prompt 공백이 그대로 API 응답이 된다
#4461 - 이미 수정 PR이 Draft로 열려 있으니 이슈만 따로 새 작업으로 열 필요는 없다. gate(CI·latest dev·ready) 끝날 때까지 Draft로 두면 된다

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

• #4461을 이 이슈의 정식 수정본으로 묶고 Draft gate만 기다릴지, 아니면 Windows PATH/App 루트 탐색만 먼저 작은 PR로 쪼갤지
• base prompt를 카탈로그 base_instructions에서 읽을지, model_instructions_file까지 포함해 ‘실제 Codex가 쓰는 원본’으로 볼지 (프로브가 CLI debug 출력만 보면 base는 영원히 안 나온다)
• Windows 서비스 wrapper가 PATH를 새로 보존하면, 서비스 재설치/업그레이드 시 기존 고정 PATH 동작을 깨지 않는지

너의 추천

• 이슈는 열어 두고 #4461에 연결한 채 Draft gate(로컬/호스티드 CI·latest dev·ready 확인)를 마친 뒤 merge 한다. 중복 수정 PR은 새로 받지 말고, 이슈 본문 기대 세 가지를 #4461 검증 목록에 그대로 체크하게 한다. types/config 분할과는 무관하니 close-don't-rebase 대상이 아니다.

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

[lidge-jun]

The Codex program not found half is fixed on dev by #4585, merged as dfa0e2f985e32df8263c87ad43d17ce0123a42be. Thanks for the report and for #4461 — the runtime-discovery work is carried from your branch with a Co-authored-by trailer.

The prompt probe no longer carries its own four-path POSIX list. It resolves through the shared runtime resolver, which gained an installed source that enumerates %LOCALAPPDATA%\OpenAI\Codex\bin\<version>\codex.exe newest-first, and a probeVersion: false mode so a request-path caller gets a deferred inspection instead of paying a blocking --version exec per candidate. The probe spawns through the shared invocation helper so a resolved .cmd launches correctly, and now returns a stable failure.kind — program-not-found, command-unsupported, execution-failed, output-invalid — which is the failure classification you asked for. Process stderr is read only to classify and never returned.

One part of this report is deliberately not in that PR: the selected model's published base prompt in the probe response, including the model_instructions_file override and the expanded-versus-template distinction. That surface was owned by separate work this round. I am closing this issue for the runtime-discovery and failure-classification scope it is titled for; the base-prompt-source half is tracked as follow-up on the prompt-source surface. Say the word if you would rather keep this one open for that instead.

[lidge-jun]

Follow-up for the base-prompt-source half is now tracked at #4590.

[lidge-jun]

Half of this landed on dev in dfa0e2f. Leaving the issue open, because the pull request claimed both halves and only delivered one.

What landed: the prompt probe now resolves through the shared runtime resolver, so the Windows Codex App runtime is found instead of being reported as an absent candidate, and a program-not-found case becomes a deferred inspection rather than a false negative. The probe also gained a redacted display path, stable failure kinds, and classified stderr that is never returned verbatim.

What did not land: the published base prompt source itself. The probe finds the runtime; it still does not publish the base prompt source the issue asks for. That is what this issue stays open for.