ocx injects into `$CODEX_HOME` (Orca's runtime home on Windows), silently missing the ChatGPT app's `~/.codex` while reporting success

[minerva32]

Summary

ocx restore back / ocx sync inject openai_base_url and the model catalog into the Codex home resolved from $CODEX_HOME. When Orca is installed on Windows, Orca exports CODEX_HOME / ORCA_CODEX_HOME pointing at its own bundled runtime home (%APPDATA%\orca\codex-runtime-home\home). The ChatGPT desktop app (MSIX package OpenAI.Codex, binary ChatGPT.exe, with Codex integrated) reads %USERPROFILE%\.codex instead.

Running ocx from an Orca shell therefore injects into the Orca home, which the user's app never reads: the proxy receives zero traffic (/api/usage requests stays at 0) and the app's model picker only shows native gpt models. Despite this, ocx prints:

Plain codex now routes through opencodex again

i.e. the failure is silent. On macOS the same setup "just works" because nothing overrides CODEX_HOME, so it defaults to ~/.codex, which is where the app reads — so the Orca-vs-~/.codex mismatch is effectively a Windows-with-Orca regression.

Environment

• Windows 11
• opencodex 2.7.40 (@bitkyc08/opencodex)
• Orca installed → in Orca shells: CODEX_HOME = ORCA_CODEX_HOME = %APPDATA%\orca\codex-runtime-home\home
• ChatGPT desktop app (integrated Codex), MSIX OpenAI.Codex_..._x64__2p2nqsd0c76g0, reads %USERPROFILE%\.codex (its config.toml has a [desktop] section with selected-avatar-id, ambient-suggestions-enabled, etc.)

Repro

1. From a shell where CODEX_HOME points at the Orca home, run ocx restore back.
2. It writes openai_base_url = "http://127.0.0.1:10100/v1" into the Orca home config.toml and prints the success line above.
3. The ChatGPT app is unaffected: curl http://127.0.0.1:10100/api/usage → "requests":0; the app's model picker shows only gpt models.
4. Re-run with the home forced to the app's home:

   env -u ORCA_CODEX_HOME CODEX_HOME='C:\Users\<user>\.codex' ocx restore back
   env -u ORCA_CODEX_HOME CODEX_HOME='C:\Users\<user>\.codex' ocx sync-cache

   Now ~/.codex/config.toml gets openai_base_url and model_catalog_json = ".../opencodex-catalog.json", the cache gains 13 non-gpt models (zai/glm-, antigravity/claude-, gemini-, gpt-oss-), and the app's picker shows them. This confirms the target-home mismatch is the sole cause.

Inconsistency that made this hard to diagnose

ocx restore back reported "catalog sync skipped: no Codex catalog source found" when targeting the Orca home, but "+ 13 models appended to Codex catalog" when targeting ~/.codex. The behavior differing by target home (not by any flag) made the failure mode non-obvious.

Suggestions

1. Detect the mismatch in ocx doctor / ocx status. Compare the home $CODEX_HOME points at vs. the home the Codex/ChatGPT desktop app reads (~/.codex on Windows & macOS), and warn loudly when they differ — e.g. "CODEX_HOME=…\orca\codex-runtime-home\home, but the ChatGPT app reads ~/.codex — injection won't reach the app."
2. Don't print the "codex now routes through opencodex" success line when the targeted home isn't one a Codex app actually reads (or at least qualify it with which home was targeted). The current message is actively misleading in the multi-home case and cost real debugging time.
3. (Windows) Document/detect the MSIX loopback restriction. The ChatGPT app is an MSIX package; packaged apps are blocked from 127.0.0.1 by default unless a loopback exemption (CheckNetIsolation LoopbackExempt -a -n=<package family name>) is added. A note — or auto-detect — in ocx doctor would help; there is no equivalent hurdle on macOS.

Workaround

Run ocx with CODEX_HOME forced to the home your Codex app reads, and unset ORCA_CODEX_HOME:

env -u ORCA_CODEX_HOME CODEX_HOME="$HOME/.codex" ocx restore back

Happy to provide full ocx doctor / ocx status output or config diffs if useful. Thanks for the tool — it's great once it's pointed at the right home.

[github-actions]

_{Automated translation bookkeeping — detected language: English.}

[Ingwannu]

Confirmed as a real diagnostic and success-reporting gap on current dev (911373db). OpenCodex intentionally honors an explicit CODEX_HOME, but it currently has no high-confidence warning for an Orca-owned runtime home while the ChatGPT/Codex app continues to use the default ~/.codex home. The resulting success text can therefore describe the targeted Orca home while the app remains unchanged.

I will preserve explicit CODEX_HOME semantics, but add:

• a Windows/Orca dual-home diagnostic in ocx doctor and status output;
• target-home-qualified injection/restore messaging;
• actionable wording that identifies the app home and the environment override;
• regression tests for matching homes, intentional custom homes, and the Orca mismatch.

I will link the dev PR and verification here before closing.

[Ingwannu]

Fixed and merged into dev via PR #503, with the final PowerShell-command correction in follow-up PR #505.

The landed behavior preserves explicit CODEX_HOME semantics and only warns for the high-confidence Windows Orca signature: CODEX_HOME equals ORCA_CODEX_HOME, the target ends in orca\\codex-runtime-home\\home, and it differs from the default ChatGPT/Codex App home.

The diagnostic now appears in human/JSON status, doctor, sync, and restore-back paths; all displayed user paths are redacted. Recovery guidance is executable in both Command Prompt and PowerShell, includes service uninstall/reinstall migration, and targets the symbolic %USERPROFILE%\\.codex / $env:USERPROFILE App home rather than a redacted placeholder.

Documentation was updated in English, Korean, Japanese, Chinese, and Russian, with the detector's narrow scope stated consistently.

Verification included 88 focused integration/diagnostic/state/CI-contract tests, TypeScript typecheck, a 131-page docs build, and full required CI on Ubuntu, macOS, and Windows. The follow-up separator regression passed all 12 checks and the final review queue is resolved.