[Bug]: Native-main refresh publication can overwrite external Codex writers

[MarcTCruz]

Client or integration

Codex CLI

Area

Authentication and account pool

Summary

Current dev (9cd4e4b8efc055ec8c8f7f9fd76d7c556a065fa6) contains the native-main refresh implementation merged for #2221, but its publication and coordination protocol still has two credential-safety races.

The publisher hashes auth.json, checks it again, and then renames a staged file over it. A Codex writer that replaces auth.json between the final check and rename can still be overwritten. Native-main refresh also reuses the pool refresh lock under OPENCODEX_HOME; two OpenCodex instances with different OPENCODEX_HOME values but the same canonical CODEX_HOME therefore do not coordinate the file they both write.

Expected behavior: native-main refresh coordinates by canonical CODEX_HOME, preserves an external writer atomically, recovers deterministically after process death, and never removes the canonical auth.json target during publication.

Reproduction

1. Check out current dev and install the frozen dependency tree:

   git checkout dev
   git pull --ff-only origin dev
   bun install --frozen-lockfile

2. Create one temporary CODEX_HOME/auth.json containing an expired access token and a valid refresh token.

3. Start two child processes with that same CODEX_HOME and distinct OPENCODEX_HOME directories. Have both request native-main refresh while counting OAuth refresh callbacks.

4. Observe that the existing pool-lock namespace does not serialize the two processes by canonical Codex home.

5. At the existing final pre-rename test hook in src/codex/main-account.ts, atomically replace auth.json from a simulated Codex writer. Resume the native-main publisher.

6. Observe that the staged credential can overwrite the external writer after the last hash check.

A deterministic regression is included in the linked fix branch:

./node_modules/bun/bin/bun.exe test --preload ./tests/preload.ts \
  tests/atomic-file-preserving-replace.test.ts \
  tests/codex-main-account-refresh.test.ts \
  tests/native-main-refresh-process.test.ts

The test asserts one physical refresh across different OPENCODEX_HOME values, byte-for-byte preservation of an external writer, process-death recovery, and stable canonical target presence.

Version

dev at 9cd4e4b8efc055ec8c8f7f9fd76d7c556a065fa6

Operating system

Ubuntu 24.04 (Linux 6.8); macOS and Windows replacement adapters require CI runtime coverage

Provider and model

OpenAI native main account / gpt-5.5

Logs or error output

No token values are logged. The failure is observed as either more than one refresh callback for one CODEX_HOME or an auth.json SHA-256 different from the external writer's expected SHA-256.

Screenshots and supporting files

Not applicable. The linked regression uses temporary homes, child processes, SHA-256 identities, and loopback-only fixtures.

Redacted configuration

{
  "CODEX_HOME": "/tmp/ocx-native-main-repro/codex",
  "OPENCODEX_HOME_A": "/tmp/ocx-native-main-repro/ocx-a",
  "OPENCODEX_HOME_B": "/tmp/ocx-native-main-repro/ocx-b"
}

Checks

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

[lidge-jun]

리뷰 · 우선순위 64 / 80

지금 dev HEAD는 9cd4e4b8e이고 패키지는 2.36.0입니다. #2848이 이미 들어가 있습니다. 그 작업은 #2221을 고치려고, OpenCodex가 Codex CLI가 쓰는 CODEX_HOME/auth.json을 직접 읽고, 만료된 액세스 토큰을 리프레시 토큰으로 갈아 끼운 뒤 같은 파일에 다시 쓰게 했습니다. 이 이슈는 그 살아 있는 길이 아직 두 곳에서 위험하다고 말합니다. 저는 HEAD 코드를 다시 봤고, 버그는 아직 그대로입니다. 고치는 새 파일은 HEAD에 없습니다.

첫 번째 구멍은 파일을 덮어쓰는 순간입니다. src/codex/main-account.ts의 persistRefreshedMainAuthJson은 먼저 auth.json 전체를 읽어서 SHA-256을 기억합니다. 그다음 atomicWriteFile에 임시 파일을 만들고, beforeRename과 validateBeforeRename에서 해시가 같은지 다시 본 다음, 임시 파일 이름을 auth.json으로 바꿉니다. 마지막 확인과 이름 바꾸기 사이에 Codex CLI 같은 다른 프로그램이 그 파일을 통째로 바꿔 두면, OpenCodex는 새 내용을 보지 못합니다. 이름 바꾸기는 그냥 덮어씁니다. Codex가 방금 저장한 토큰이 사라지고, OpenCodex가 들고 있던 예전 스냅샷이 남습니다. 해시를 두 번 보는 것은 도움이 되지만, 확인과 rename 사이의 틈은 막지 못합니다.

두 번째 구멍은 누가 같은 파일을 고치는지 줄을 세우는 잠금입니다. 리프레시는 withCodexRefreshFileLock으로 한 줄로 섭니다. 그 잠금 파일은 src/codex/account-store.ts의 codexRefreshLockPath가 getConfigDir() 아래에 만듭니다. getConfigDir()은 OPENCODEX_HOME이고, 없으면 ~/.opencodex입니다. 실제로 쓰는 파일은 CODEX_HOME/auth.json입니다. 그래서 CODEX_HOME은 같고 OPENCODEX_HOME만 다른 두 OpenCodex는 서로 다른 잠금 폴더를 봅니다. 같은 auth.json을 동시에 고칩니다. 리프레시가 두 번 나가거나, 한쪽이 다른 쪽이 쓴 결과를 덮어쓸 수 있습니다.

이미 HEAD에 있는 src/codex/native-main-claim.ts, src/codex/native-main-owner.ts, src/codex/native-profile-store.ts는 이 네이티브 메인 리프레시 길에 아직 연결되어 있지 않습니다. 이슈가 말하는 고침 파일 src/codex/native-main-refresh-publication.ts와 src/lib/atomic-file-preserving-replace.ts는 HEAD에 없습니다. 연결된 고침은 초안 PR #3000 하나입니다. 예전 초안 #2497은 이미 닫혀 있습니다. 이 이슈도 #3000도 그 초안을 다시 열지 말라고 분명히 적혀 있습니다. 같은 주제로 새 브랜치를 또 열 필요는 없습니다.

이 구멍은 계정 풀 레인의 자격 증명 안전 문제입니다. 문서 로케일 맞춤(#2980)이나 카탈로그 다운로드(#2979)보다, 지금 dev에서 실제로 auth.json을 쓰는 길을 단단히 하는 일이 먼저입니다. #2848이 연 길을 이 이슈가 이어서 막습니다. types.ts/config.ts 쪼개기와는 겹치지 않습니다. 미리보기 배포도 이 일과 무관합니다.

라인 15 - src/codex/main-account.ts가 풀 계정용 withCodexRefreshFileLock을 그대로 가져옵니다. 네이티브 메인 파일과 잠금 위치가 다릅니다.
라인 149-162 - persistRefreshedMainAuthJson이 atomicWriteFile의 beforeRename에서 해시를 보고 바로 rename합니다. 그 사이에 들어온 외부 작성자 파일을 보존하지 않습니다.
라인 191-192 - 리프레시 잠금 키가 리프레시 토큰 지문이고, withCodexRefreshFileLock 호출이 그 키로 잠급니다. 잠금 파일은 OPENCODEX_HOME 아래에 생깁니다.
경로 src/codex/account-store.ts codexRefreshLockPath / withCodexRefreshFileLock - 잠금은 getConfigDir() 아래 codex-refresh-*.lock입니다. CODEX_HOME이 아닙니다.
경로 src/config/paths.ts getConfigDir - OPENCODEX_HOME이 잠금 집을 바꿉니다. CODEX_HOME은 바꾸지 않습니다.
경로 src/codex/native-main-refresh-publication.ts, src/lib/atomic-file-preserving-replace.ts - 이슈가 말하는 고침 파일은 아직 HEAD에 없습니다.

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

• #3000을 이 이슈의 유일한 고침으로 둘지. 같은 레이스를 다른 브랜치로 다시 짜지 말지
• #2497은 이미 닫혀 있습니다. 그 초안을 다시 열지 말지. 이 이슈와 fix(codex): harden native main refresh publication #3000 본문도 다시 열지 말라고 적혀 있습니다
• #2848이 연 네이티브 메인 쓰기 길을, 외부 Codex 작성자를 보존하는 교환이 올 때까지 그대로 둘지
• 라벨 bug / account-pool 은 이 내용과 맞습니다. 바꾸지 않는 쪽이 맞습니다

너의 추천
이슈를 연 채로 두고 고침은 #3000만 따라갑니다. 같은 주제로 새 PR을 열지 않습니다. #2497은 닫힌 채로 둡니다. 다시 열지 않습니다. 라벨은 그대로 둡니다. 머지는 #3000이 초안에서 나오고, CI와 메인테이너 보안 검토가 끝난 뒤에 하면 됩니다.

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