Codex 작업은 다음과 같은 문장으로 끝날 수 있습니다.
textexceeded retry limit, last status: 429 Too Many Requests stream disconnected before completion exceeded retry limit, last status: 401 Unauthorized
세 문장은 같은 장애를 뜻하지 않습니다. 401은 특정 요청 경로가 인증을 거부했다는 뜻입니다. 429는 어떤 서비스가 요청 속도, 잔액, 지출 또는 사용량 경계를 적용했다는 뜻입니다. stream disconnected는 응답이 완료되기 전에 스트림이 끊겼다는 사실만 말합니다. exceeded retry limit는 client가 재시도를 멈춘 이유이지 또 다른 quota가 아닙니다.
인증 파일을 지우거나 key를 재발급하고, timeout을 늘리고, 큰 작업을 반복하기 전에 실제 경로와 첫 유효 오류를 기록해야 합니다.
상태를 바꾸기 전 두 가지 확인
CLI에서는 먼저 읽기 전용 명령을 실행합니다.
bashcodex --version codex login status
정확한 오류 원문, 발생 시각과 시간대, Codex 화면, 모델, 표시된 request ID도 함께 남기세요. codex login status는 인증 방식을 보여 주지만 downstream 권한까지 모두 유효하다는 증거는 아닙니다. custom provider를 쓴다면 credential을 출력하지 않고 실제 provider와 base URL도 확인합니다.
공식 Codex App Server 오류 분류는 Unauthorized, 상위 HTTP 실패, ResponseStreamConnectionFailed, ResponseStreamDisconnected, ResponseTooManyFailedAttempts를 별도 범주로 둡니다. 상위 HTTP status가 있으면 httpStatusCode로 따로 전달될 수 있습니다. 화면에 마지막 retry 문장만 보여도 이 범주를 섞지 않는 것이 중요합니다.
어떤 계정과 provider가 오류를 소유하는가
| 실제 경로 | 우선 확인할 증거 | 대신 쓸 수 없는 정보 |
|---|---|---|
| ChatGPT로 로그인한 Codex | 활성 account/workspace, Codex usage, 새 session의 재현 | Platform API 잔액과 RPM/TPM |
| OpenAI API key | structured error, organization/project, billing·limits, response header | ChatGPT Plus/Pro 상태 |
| 외부 provider/gateway | 유효 endpoint, provider account, gateway/upstream log, trace ID | 관련 없는 OpenAI dashboard |
실패 요청을 처리하지 않은 계정의 “잔여량 있음”은 정확하더라도 진단 근거가 아닙니다. 인증 방식, provider, 확인 중인 console이 같은 요청 경로에 속하는지 먼저 맞추세요.
401은 재시도가 아니라 인증 상태 문제다
OpenAI Platform API의 401은 invalid authentication, 잘못된 API key, organization membership 부족, IP allowlist 불일치로 나뉩니다. 현재 공식 API 오류 문서의 구체적인 error.code와 실제 project를 확인해야 합니다.
ChatGPT login이라면 codex login status가 예상한 방식인지 봅니다. 저장 session이 무효이거나 잘못된 account임을 확인한 뒤에 재인증하세요. codex logout는 저장된 credential을 지우는 상태 변경 작업이므로 첫 진단 명령으로 쓰지 않습니다. 공식 인증 안내는 process environment가 관리하는 workload identity가 login/logout와 다르게 동작한다는 점도 설명합니다.
API key 경로에서는 실행 process의 key가 확인 중인 endpoint, project, organization, IP policy와 일치해야 합니다. key, 전체 environment, auth.json을 출력하거나 issue에 붙이지 마세요. invalid_api_key, membership, IP authorization을 바로잡은 뒤 짧은 요청을 한 번 검증합니다. 인증 상태가 그대로인 안정적인 401은 backoff로 해결되지 않습니다.
외부 gateway의 401은 gateway 입구 인증일 수도 있고, gateway가 받은 upstream 401일 수도 있습니다. request ID를 같은 시각의 log와 맞춰 어느 hop에서 거부됐는지 확인하세요.
429는 구체적인 owner를 읽어야 한다
OpenAI Platform API의 429는 단순한 request-rate 제한만 뜻하지 않습니다. 공식 오류 문서는 credit balance, organization/project spend limit, organization usage limit도 구분합니다. billing, spend, quota 조건은 반복 요청만으로 회복되지 않습니다.
- 유효한
Retry-After나 request-rate code가 있다면 concurrency를 낮추고 지정 시간 이상 기다린 뒤 제한된 횟수만 재시도합니다. credit_balance_exhausted라면 해당 organization의 balance가 바뀌기 전에는 멈춥니다.- spend limit라면 실제 요청이 속한 project와 organization을 확인합니다.
- ChatGPT/Codex usage window라면 그 account 화면에 표시된 회복 조건을 따릅니다.
- 외부 provider의 429라면 해당 provider의 billing, quota, concurrency, log가 기준입니다.
- 마지막 429 문장만 있다면 시각, route, request ID를 보존하고 고정 대기 시간을 추측하지 않습니다.
짧은 직렬 요청은 성공하고 병렬 작업만 실패한다면 concurrency를 줄여 경계를 기록하세요. 이는 workload 형태에 대한 증거이지 최종 원인 증명은 아닙니다. 부하를 줄여도 결과가 불규칙하면 테스트를 멈추고 gateway/provider log로 돌아갑니다.
Stream disconnected는 끊긴 시점을 비교한다
응답 스트림은 client, proxy/TLS inspection, 관리형 network, gateway, upstream service, 로컬 network 전환 때문에 끊길 수 있습니다. 오류 문장만으로 VPN, server outage, client bug를 확정할 수 없습니다.
한 번의 작은 대조 테스트로 범위를 좁히세요.
- 같은 account, provider, model에서 새 session과 민감하지 않은 짧은 요청을 사용합니다.
- 출력 전, 부분 출력 후, 명시적 HTTP status 중 언제 실패했는지 기록합니다.
- 정책이 허용하는 경우에만 다른 신뢰할 수 있는 network에서 같은 요청을 한 번 실행합니다.
- 실패 시각과 request ID를 gateway/provider log와 맞춥니다.
- 특정 client/version만 실패한다면 차이를 기록하고 여러 변수를 동시에 바꾸지 않습니다.
다른 network에서 성공했다는 사실은 network path를 좁힐 뿐 조직의 security control을 끄라는 뜻이 아닙니다. 두 network에서 같은 시각에 실패하면 account, provider, gateway, 현재 service evidence를 더 우선해야 합니다.
곧바로 stream_idle_timeout_ms를 늘리지 마세요. timeout은 client가 기다리는 시간만 바꿉니다. 잘못된 base URL, 401, 잔액 소진, gateway의 의도적 종료는 고치지 못합니다.
Retry 설정은 상위 상태를 바꾸지 않는다
Codex provider 설정에는 request retries, stream retries, stream idle timeout이 있습니다. 공식 config reference는 model_providers와 provider/auth key가 user-level 설정이며 project-local .codex/config.toml에서는 무시된다는 점도 설명합니다.
횟수를 늘리면 확정적인 실패 시간을 늘리고, gateway의 retry와 중첩돼 요청을 증폭시키며, 첫 유효 error를 가릴 수 있습니다. 일시적인 rate/transport 조건과 재시도 가능성을 확인하고 attempt 수와 총 시간에 상한을 둘 수 있을 때만 조정하세요. 변경 뒤에는 짧은 요청 한 번으로 검증하고 같은 첫 오류가 돌아오면 중단합니다.
지원 요청에 필요한 최소 증거
새 session에서도 최소 요청이 실패하거나 account 상태와 error가 충돌하고, 특정 version/provider 조합에서만 재현한다면 다음을 준비합니다.
- Codex version, CLI/App/IDE, OS
- auth method와 provider 이름(credential 제외)
- 첫 실패와 최근 실패 시각, time zone
- 출력 전인지 부분 출력 후인지
- error category, HTTP status,
error.code, request ID - 단일 session/model인지 여러 곳에서도 발생하는지
- 한 번 수행한 대조 테스트와 결과
- 첫 실패를 보존한 최소 redacted log
API key, token, authorization header, 완전한 auth/config, environment dump, private prompt, source code는 보내지 않습니다.
복구 판정은 원래 경로에서 해야 합니다. 같은 account, provider, client의 짧은 요청이 끝까지 완료되고 첫 오류가 다시 나타나지 않아야 합니다. account, model, network를 바꾼 성공은 유용한 우회일 수 있지만 원래 경로가 회복됐다는 증거는 아닙니다.
