Token exchange failed와 Your access token could not be refreshed는 모두 Codex 인증 문제지만 실패 단계가 다릅니다. 전자는 브라우저 인증 결과를 실제 token으로 교환하는 중에, 후자는 이미 있던 세션을 갱신하는 중에 나타납니다. OpenAI는 각 문구를 하나의 원인에 대응시키는 완전한 오류표를 제공하지 않습니다.
브라우저가 로그인 완료를 보여도 Codex 프로세스가 로컬 루프백 callback을 받고 token endpoint에 도달해 자격 증명을 저장했다는 보장은 없습니다. 어디서 Codex가 실행되고 인증의 어느 단계까지 끝났는지부터 확인하세요.
오류 끝부분으로 첫 확인 지점을 정하세요
비밀을 가린 전체 오류 문구를 보존합니다. 끝부분에 따라 다음 확인이 달라집니다.
| 관찰한 신호 | 확인된 경계 | 먼저 할 일 |
|---|---|---|
error sending request for url (.../oauth/token), timeout, connection error | Codex 프로세스의 token endpoint 요청이 완료되지 않음 | 브라우저가 아니라 실행 호스트의 네트워크, proxy, TLS 확인 |
token endpoint returned status 403 | endpoint가 요청을 받고 거부함 | 상태와 정리된 문맥을 보존하고 계정, workspace, 관리 정책 확인 |
| 브라우저 완료 후 CLI가 계속 대기 | 로컬 루프백 callback이 Codex에 도착하지 않았을 수 있음 | WSL, SSH, container, remote extension host 중 실제 위치 확인 |
access token could not be refreshed | 저장된 세션의 갱신 실패 | 실행 환경의 auth status를 확인하고 지원되는 방식으로 자격 증명 재생성 |
CERTIFICATE_VERIFY_FAILED 또는 명시적 CA 오류 | 프로세스가 인증서 체인을 신뢰하지 못함 | 확인된 기업 TLS proxy/private CA 환경에서만 신뢰 CA bundle 사용 |
이는 진단 경계이지 자동 원인이 아닙니다. 특히 403은 거부 사실만 보여 주며 지역, VPN, 계정, 구독 중 무엇이 원인인지는 단독으로 말해 주지 않습니다.
인증을 바꾸기 전에 작업 상태부터 보존하세요
인증 오류가 이미 작성된 파일을 되돌리지는 않습니다. 손실은 대개 여러 창에서 같은 작업을 중복 실행하거나, 캐시를 지운다는 이유로 프로젝트 파일까지 건드릴 때 생깁니다.
먼저 다음을 기록합니다.
- 저장소의 미커밋 변경 사항
- 개인 정보와 비밀을 지운 전체 오류 문구
- 발생 시간과 시간대
- Codex App, CLI, IDE 중 어떤 표면인지와 버전
- 프로젝트 경로와 마지막으로 완료된 동작
auth.json, access token, refresh token, API key, OTP, Cookie, 정리되지 않은 HAR는 게시물이나 지원 채팅에 올리지 마세요. OpenAI 인증 문서는 파일 기반 auth.json에 액세스 토큰이 들어 있으므로 비밀번호처럼 다루라고 안내합니다.
화면이 있는 컴퓨터와 실행 호스트를 구분하세요
노트북에 VS Code 창이 보여도 extension host는 Remote SSH 서버에 있을 수 있습니다. 터미널은 WSL이나 dev container 안일 수 있고, 별도 에이전트나 gateway는 Codex CLI와 다른 OAuth profile을 가질 수 있습니다.
| 오류가 보이는 곳 | 먼저 확인할 인증 경계 | 로그아웃 증거가 아닌 것 |
|---|---|---|
| Codex App | App의 현재 profile과 로컬 자격 증명 저장소 | 다른 브라우저 profile의 ChatGPT 로그아웃 |
| Codex CLI | 해당 shell의 OS 사용자와 CODEX_HOME | 웹 ChatGPT가 정상인 상태 |
| IDE 확장 | extension host가 local인지 remote인지 | 에디터 UI만 재설치한 것 |
| WSL, SSH, container, VM | 그 환경 안의 home 또는 keyring | 호스트 PC에서만 로그아웃한 것 |
| 외부 harness | 그 도구의 자체 auth profile | 독립 Codex CLI가 정상인 상태 |
공식 문서에 따르면 Codex CLI와 IDE 확장은 캐시된 로그인 정보를 공유할 수 있습니다. 저장 위치는 ~/.codex/auth.json일 수도 있고 OS 자격 증명 저장소일 수도 있습니다. 그래서 파일을 추측해 수동 삭제하는 것보다 지원되는 logout을 먼저 쓰는 편이 안전합니다.
외부 harness에서만 오류가 난다면 그 도구의 profile도 별도로 확인해야 합니다. 다만 직접 Codex 복구가 우선이며, OpenClaw 같은 다른 제품의 캐시 삭제법을 Codex 공식 절차로 섞어서는 안 됩니다.
CLI와 IDE의 저장 자격 증명을 다시 만드세요
오류를 낸 프로세스가 실제로 실행되는 환경에서 현재 인증 방식을 확인합니다.
bashcodex login status
이 명령은 자격 증명 존재 여부와 활성 인증 모드를 보여 줍니다. ChatGPT 구독으로 로그인했다고 생각했지만 실제로는 API key를 쓰는 경우, Remote SSH에서 다른 OS 사용자로 실행되는 경우를 여기서 발견할 수 있습니다. 다만 status 성공은 실제 모델 요청 성공을 보장하지 않습니다.
그다음 저장된 인증을 지원되는 명령으로 지우고 다시 로그인합니다.
bashcodex logout codex login
브라우저에서 의도한 ChatGPT 계정과 workspace를 확인합니다. 완료되면 codex login status를 다시 실행하세요.
현재 OpenAI 인증 문서는 codex login, codex login status, codex logout을 안내합니다. CLI와 IDE가 캐시를 공유하더라도 이미 실행 중인 extension host는 오래된 상태를 붙잡고 있을 수 있으므로 IDE를 완전히 종료했다가 다시 엽니다.
Codex App에서는 profile 메뉴에서 계정 또는 API key 상태를 확인하고 App 안에서 로그아웃합니다. App을 완전히 종료한 뒤 다시 실행해 의도한 방식으로 로그인하세요. 한 브라우저의 chatgpt.com에서 로그아웃한 것만으로 App의 로컬 자격 증명이 사라졌다고 볼 수 없습니다.
API key 로그인은 ChatGPT 로그인 오류를 우회하는 만능 수단이 아닙니다. API 사용량은 Platform 계정에 청구되고, ChatGPT workspace나 cloud 기능에 의존하는 일부 기능은 제한될 수 있습니다. 원래 사용하려던 인증 경로가 무엇인지 먼저 확정해야 합니다.
새 로그인 자체가 끝나지 않는다면
오래된 자격 증명을 지운 뒤 브라우저가 Codex로 돌아오지 못한다면 문제는 token refresh에서 새 로그인 단계로 이동했습니다.
Remote SSH나 headless CLI에서는 로컬 콜백 엔드포인트를 사용할 수 없을 수 있습니다. 계정 또는 workspace에서 허용한다면 device code 흐름을 사용합니다.
bashcodex login --device-auth
표시된 링크를 열고 로그인한 다음 일회용 code를 입력합니다. code를 다른 사람에게 보내지 마세요. 기능이 꺼져 있으면 개인 보안 설정이나 workspace 관리자가 활성화해야 합니다.
표준 browser flow를 유지하고 CLI가 SSH 호스트에서 실행된다면 공식 기본 callback은 로컬 루프백의 1455 포트를 사용합니다. 로컬에서 터널을 만들고 같은 SSH 세션에서 로그인하세요.
bashssh -L 1455:[::1]:1455 user@remote codex login
1455를 인터넷에 공개하지 말고, 로컬 CLI에 무조건 적용하지 마세요. 이 터널은 callback 경로만 닫아 주며 endpoint 403이나 인증서 실패는 해결하지 않습니다.
회사 네트워크가 TLS proxy 또는 private root CA를 사용한다면 공식 가이드는 신뢰할 PEM bundle을 지정하는 CODEX_CA_CERTIFICATE를 제공합니다. 직접 실행한 codex login은 설정된 로그 디렉터리에 codex-login.log도 작성합니다. callback, 인증서, 브라우저 로그인을 진단할 때 유용하지만 공유 전에 token, 이메일, workspace 식별자와 비공개 경로를 제거해야 합니다.
관리형 환경은 ChatGPT 또는 API key 방식을 강제하거나 특정 ChatGPT workspace만 허용할 수 있습니다. 새 계정이 즉시 거부되거나 로그아웃되면 로컬 캐시를 계속 지우지 말고 관리자에게 membership, provisioning, 허용 인증 방식, 대상 workspace를 확인하세요.
workload identity를 쓰는 환경에서는 프로세스가 인증을 공급하므로 사용자 codex login과 codex logout이 거부됩니다. 이때 고칠 대상은 로컬 파일이 아니라 identity provider, federation rule, runtime 환경입니다.
로그인 화면이 아니라 작은 작업으로 검증하세요
복구는 세 가지 증거가 있어야 끝납니다.
codex login status가 의도한 인증 방식을 보여 준다.- App 또는 IDE에서 가능한 범위 내에 올바른 계정과 workspace가 보인다.
- 원래 오류가 난 같은 프로젝트와 실행 환경에서 작은 저위험 작업이 완료된다.
처음에는 민감하지 않은 파일 하나를 읽고 요약하게 하세요. 곧바로 큰 쓰기 작업을 재개하지 말고 기존 변경 사항을 확인한 뒤 원래 작업으로 돌아갑니다.
새 오류가 나타나면 진단도 바꿔야 합니다. HTTP 429는 Codex 사용량 제한, 연결이나 도구가 멈추는 현상은 Codex 시간 초과, 전화번호·MFA·device verification은 Codex 인증 확인의 범위입니다.
지원에 보낼 수 있는 최소 정보
올바른 호스트에서 새로 로그인해도 같은 오류가 반복되면 다음만 준비합니다.
- 개인정보를 지운 오류 문구, 시간과 시간대
- App, CLI, IDE와 버전
- OS 및 local, WSL, SSH, container, VM 여부
- token이나 전체 계정 ID를 제외한 활성 인증 방식
- logout 및 새 browser/device flow 결과
- 작은 확인 작업의 결과
- 새 로그인 자체가 실패했을 때만 정리한
codex-login.log일부
auth.json, token, API key, OTP, Cookie, 전체 HAR, 비밀이 보이는 스크린샷은 첨부하지 않습니다. 올바른 실행 호스트의 새 자격 증명이 의도한 계정과 방식에 연결되고, 범위가 작은 Codex 작업을 완료해야 복구가 끝난 것입니다.
