Skip to content

[Bug] OpenAI Codex 계정 풀이 정상이어도 native auth 만료 시 로그인창이 열림 #320

Closed

Description

@jhste102lab

Client or integration

Codex CLI

Area

Authentication and account pool

Summary

OpenCodex의 OpenAI/Codex 계정 풀이 정상이고 OAuth 계정도 유효한 상태인데, 로컬 Codex CLI의 native auth.json 토큰이 만료되면 codex 실행 시 OpenCodex proxy로 요청이 전달되기 전에 ChatGPT/Codex 로그인창이 열립니다.

현재 codexAccountMode = pool을 사용하고 있으므로, OpenCodex가 보유한 계정 풀을 이용할 수 있다면 별도의 만료된 native Codex 인증 때문에 실행 자체가 중단되지 않아야 한다고 생각합니다. native 인증이 Codex CLI 시작 단계에서 반드시 필요하다면, 최소한 OpenCodex가 원인과 복구 방법을 명확하게 안내하거나 자동 복구해야 합니다.

추가로 Codex CLI npm 업데이트 후 기존 Codex 실행 파일이 교체되면서 OpenCodex autostart shim이 사라졌습니다. ocx status는 shim 상태를 감지했지만, 사용자가 직접 ocx codex-shim install을 다시 실행하기 전까지 codex가 proxy를 자동 시작하지 않았습니다.

Reproduction

  1. OpenCodex에서 OpenAI/Codex 계정 풀을 설정하고 OAuth 계정을 2개 이상 등록합니다.

  2. OpenAI provider를 다음과 같이 설정합니다.

    {
      "baseUrl": "https://chatgpt.com/backend-api/codex",
      "authMode": "forward",
      "codexAccountMode": "pool"
    }
  3. ocx start 또는 ocx ensure를 실행합니다.

  4. ocx account refresh openai --json에서 계정들이 needsReauth: false로 표시되는 것을 확인합니다.

  5. 로컬 Codex CLI가 사용하는 CODEX_HOME/auth.json의 access token을 만료시키거나, 만료된 native auth 상태에서 codex를 실행합니다.

  6. OpenCodex proxy가 정상 실행 중이고 계정 풀에도 유효한 OAuth가 있어도, proxy 요청 전에 Codex 로그인창이 열립니다.

  7. Codex CLI를 npm으로 업데이트한 뒤 ocx codex-shim status를 실행하면 wrapper가 존재하지만 OpenCodex shim이 아닌 상태가 될 수 있습니다. 이 경우 codex가 proxy autostart를 우회합니다.

현재 확인된 임시 workaround:

ocx account refresh openai --json
ocx codex-shim install
# CODEX_HOME/auth.json을 유효한 native Codex 인증으로 갱신

Version

  • @bitkyc08/opencodex: 2.7.33
  • @openai/codex: 0.145.0

Operating system

Ubuntu 24.04 (Linux x86_64; WSL 환경)

Provider and model

  • Provider: openai / Codex account pool
  • Model: gpt-5.6-luna

Logs or error output

$ ocx status
Default provider: openai
Codex autostart: enabled
OAuth logins: configured accounts present
Codex autostart shim: wrapper present but not an opencodex shim

$ ocx account refresh openai --json
# registered pool accounts returned with needsReauth: false

$ codex
# OpenAI/ChatGPT login window opens before a request reaches the local proxy

Screenshots and supporting files

없음. 재현 시 계정·토큰·개인정보가 포함된 화면은 첨부하지 않았습니다.

Redacted configuration

{
  "port": 10100,
  "defaultProvider": "openai",
  "providers": {
    "openai": {
      "adapter": "openai-responses",
      "baseUrl": "https://chatgpt.com/backend-api/codex",
      "authMode": "forward",
      "codexAccountMode": "pool"
    }
  }
}

Checks

  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.

Activity

  1. lidge-jun commented on Jul 23, 2026

    @lidge-jun
    Owner

    Thanks for the detailed report. There are two distinct issues here, and they have different root causes:

    1. CLI login gate before proxy intercept

    This is an upstream Codex CLI limitation. The CLI checks its native auth.json token validity before any request reaches the OpenCodex proxy. When codexAccountMode: pool is active, the proxy has healthy pool accounts ready to serve, but the CLI's own startup gate fires first and opens the login window. OpenCodex cannot intercept or suppress this gate — it happens inside the Codex binary before it contacts any endpoint.

    The practical workaround today is to keep a valid native Codex login alongside the pool. We're tracking #327 to improve observability: once __main__ exposes needsReauth in the account API (like pool accounts already do), it will be much easier to diagnose when the native credential has died.

    2. Shim loss after npm update

    When @openai/codex is updated via npm, the codex binary is replaced and the OpenCodex autostart shim is lost. ocx codex-shim status correctly detects this ("wrapper present but not an opencodex shim"), but the user must manually run ocx codex-shim install to restore it. This is a real pain point.

    For now, re-running ocx codex-shim install after a Codex CLI update is the documented workaround. A durable fix would involve either a post-install hook or a filesystem watcher, which is on the roadmap but not yet prioritized.

    Summary:

  2. added a commit that references this issue on Jul 24, 2026
  3. lidge-jun commented on Jul 24, 2026

    @lidge-jun
    Owner

    Thanks for the detailed report. There are two separate layers here.

    Pool mode vs. the native login gate

    In Pool mode (codexAccountMode="pool"), OpenCodex selects and refreshes its managed account per request when the call reaches /v1/responses (src/codex/auth-context.ts selection + token refresh). Startup does fire off a non-blocking pool quota prime (src/server/index.ts), but that is best-effort and does not gate anything — the pool does not require a usable native auth.json to serve requests.

    The login window you see comes earlier, from upstream Codex itself, before any request reaches the proxy. Loopback injection deliberately keeps Codex's built-in openai provider and only rewrites openai_base_url (src/codex/inject.ts), so Codex still applies its own native-account handling at startup. (In dedicated-provider mode we set requires_openai_auth = true at src/codex/inject.ts:96, which is a related but separate path.) Because this gate lives in the upstream client, the proxy can't suppress it without risking Codex App/TUI account-gated behavior — so from OpenCodex's side this is best treated as documentation/guidance rather than a proxy-side code fix. If you'd like it fully removed, that needs upstream Codex to separate local startup auth from the bearer used for a custom base URL.

    Shim disappearing after a Codex npm update

    A global npm update rewrites the launcher at the shim's path, replacing our wrapper. Current dev auto-restores this on the next ordinary ocx command (src/cli/index.ts → maybeAutoRestoreCodexShim) — it's best-effort and needs valid prior shim state, and it intentionally skips uninstall/help paths, so the very first direct codex call right after the update can still miss it. Manual fallback: ocx codex-shim install. For restart-safe operation that doesn't depend on the launcher, ocx service install bakes in Bun/CLI paths (though those can themselves go stale if the npm prefix moves).

    We'll also add a docs note that Pool credentials are proxy-side and do not satisfy Codex's native-login prerequisite.

  4. lidge-jun commented on Jul 24, 2026

    @lidge-jun
    Owner

    Fixed by #356 (auto-restore the codex shim after external npm updates). Merged to dev — will ship in the next release.

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 working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions