# Codex 토큰 교환 403 실패: 오류 문구별 로그인 복구 방법

> Codex 로그인에서 403을 만나면 오류 끝부분부터 확인하세요. 국가·계정·정책 거부는 공식 확인으로, 콜백 실패는 기기 로그인이나 SSH 터널로 나누고, 복구 후 같은 호스트에서 실제 작업이 되는지 확인합니다.

- URL: https://blog.laozhang.ai/ko/posts/codex-token-exchange-failed-403
- Published: 2026-07-12
- Updated: 2026-10-06
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ko/about)
- Topic: 개발 도구·에이전트
- Tags: OpenAI Codex, Codex CLI, 토큰 교환, 403 Forbidden, OAuth, 로그인 오류

---
`Token exchange failed: token endpoint returned status 403 Forbidden`이 나오면 **로그인 과정의 토큰 교환 요청이 거부된 것입니다.** 먼저 오류의 마지막 문장과 응답 본문을 읽고 다음 행동을 정하세요. `country, region, or territory not supported`가 붙으면 지역 자격을 공식 경로에서 확인해야 합니다. 브라우저 승인 뒤 터미널이 계속 기다리기만 한다면 콜백 연결을 확인하고, `error sending request`라면 연결·프록시·인증서 오류부터 구분합니다.

처음에는 오류가 난 터미널에서 `codex --version`과 `codex login status`를 기록합니다. 그다음 확인된 조건 하나를 고쳐 다시 로그인하고, 같은 실행 호스트와 인증 방식으로 작은 작업까지 완료해 보세요. 브라우저의 성공 화면이나 `login status`만으로 복구가 끝났다고 판단하지 않습니다. 계정·워크스페이스·국가 제한이 명시되면 반복 재로그인 대신 해당 권한을 확인하는 것이 다음 단계입니다.

여기서 말하는 토큰은 **로그인 자격 증명**입니다. 모델의 입력·출력 토큰이나 사용량 한도가 아니므로, 이 오류만 보고 크레딧을 구매하거나 구독을 올릴 이유는 없습니다. 아래 명령은 현재 공식 문서에 따른 실행 참고이며, 이 글에서 실제 계정 로그인을 완료하거나 요청 성공을 시험한 것은 아닙니다.

## `token_exchange_failed` 뒤의 문구가 다음 행동을 알려 줍니다

같은 `token_exchange_failed`라도 뒤에 붙는 설명이 다릅니다. 마지막 상태 코드 한 줄만 남기지 말고, 비밀을 제거한 전체 오류에서 다음을 확인하세요.

| 오류 문구 또는 증상 | 먼저 구분할 문제 | 다음 행동 |
| --- | --- | --- |
| `token endpoint returned status 403 Forbidden` | 교환 요청에 HTTP 거부 응답이 돌아옴 | 응답 본문의 이유와 요청을 거부한 곳을 확인 |
| 위 문구 뒤에 `country, region, or territory not supported` | 지원 지역과 관련된 명시적 거부 | 공식 지원 지역·계정 조건 확인, 맞지 않는 판정이면 지원 문의 |
| `Token exchange failed: error sending request for url (https://auth.openai.com/oauth/token)` | 교환 요청을 보내는 중 실패 | 뒤에 나온 연결·프록시·TLS 오류를 확인. 이 문구만으로 HTTP 403이라 판단하지 않음 |
| 브라우저 승인 뒤 콜백 주소 연결 거부, 터미널은 계속 대기 | 브라우저에서 CLI로 돌아오는 연결 실패 | CLI 실행 위치 확인 후 허용된 디바이스 코드 로그인 또는 SSH 포워딩 |
| 로그인 뒤 `selected provider is forbidden`과 사용자 지정 게이트웨이 URL | 로그인 이후 모델 공급자 요청의 거부 | 그 공급자의 권한과 설정 확인. OAuth 토큰 교환 문제와 분리 |

[HTTP 403 표준](https://www.rfc-editor.org/rfc/rfc9110.html#section-15.5.4)은 서버가 요청을 이해했지만 수행을 거절했다는 뜻으로 정의합니다. 인증 정보와 무관한 이유로도 거절할 수 있고, 같은 자격 증명으로 자동 반복 요청하지 않도록 설명합니다. 따라서 403만으로 “토큰이 만료됐다”거나 “OpenAI 서버까지 정상 도착했다”고 단정할 수 없습니다. 중간 프록시나 게이트웨이가 거부 응답을 만들었을 수도 있습니다.

브라우저 승인 → 로컬 루프백 콜백 → 토큰 교환 → 인증 정보 저장 → 작업 요청을 나눠 보면 문제를 좁히기 쉽습니다. 브라우저 승인은 사용자가 로그인을 허용했다는 뜻이고, 그 뒤의 교환이나 작업 요청까지 성공했다는 뜻은 아닙니다.

![브라우저 승인, 루프백 콜백, 토큰 교환, 자격 증명 저장과 실제 작업 요청을 나누고 HTTP 403과 요청 전송 실패를 구분하는 Codex 인증 개념도](https://blog.laozhang.ai/posts/ko/codex-token-exchange-failed-403/img/auth-stages.webp)

## 오류가 난 실행 호스트에서 상태와 로그를 남기세요

노트북에서 브라우저를 열었더라도 Codex는 SSH 서버, WSL 또는 컨테이너 안에서 실행 중일 수 있습니다. 로그인 상태와 네트워크를 확인할 곳은 **Codex 프로세스가 실제로 실행되는 환경**입니다. 호스트 터미널의 성공이 컨테이너의 성공을 증명하지는 않습니다.

그 환경에서 다음을 기록합니다.

```bash
codex --version
codex login status
```

`codex login status`는 현재 인증 방식을 확인하는 데 쓰입니다. [CLI 명령 문서](https://learn.chatgpt.com/docs/developer-commands#codex-login)에 따르면 종료 코드 `0`은 **자격 증명이 존재한다는 뜻**입니다. 서버가 그 정보를 받아들이는지, 의도한 워크스페이스에 접근하는지, 모델 요청이 되는지는 별도로 확인해야 합니다.

[공식 인증 문서의 로그인 진단 안내](https://learn.chatgpt.com/docs/auth#login-diagnostics)에 따르면 `codex login`을 직접 실행하면 설정된 로그 디렉터리에 `codex-login.log`가 남습니다. 여기서 실패 단계, 상태 코드, 짧은 오류 코드, request ID와 시각을 확인하세요. 전체 로그를 그대로 붙여 넣지 말고 토큰, 일회용 코드, Cookie, 이메일, 프록시 인증 정보와 전체 콜백 URL을 제거한 부분만 보관합니다.

[OpenAI 상태 페이지](https://status.openai.com/)에서는 발생 시각에 맞는 인증·Codex 사고 공지가 있는지 확인합니다. 공지된 사고가 자신의 증상과 맞으면 로컬 설정을 계속 바꾸기보다 복구를 기다립니다. 공지가 없다는 사실만으로 내 계정이나 네트워크 문제라고 확정할 수는 없습니다.

## `country, region, or territory not supported`라면 여기서 방향을 바꾸세요

이 문구가 정확히 붙은 교환 403이라면 DNS, 인증 캐시, 구독 가격을 바꿔 가며 재시도하지 마세요. 우선 이용하려는 서비스의 [공식 ChatGPT 지원 국가 안내](https://help.openai.com/en/articles/7947663-chatgpt-supported-countries)와 계정에 표시되는 조건을 확인합니다. 한국어로 사용한다는 사실이 요청이 한국에서 나간다는 뜻도, 모든 서비스 이용 자격을 갖췄다는 뜻도 아닙니다.

지원 조건에 해당한다고 생각되는데도 같은 문구가 나온다면, 발생 시각·시간대, Codex 버전, 실행 국가와 환경, 비밀을 제거한 오류 및 request ID를 [OpenAI 지원](https://help.openai.com/)에 전달하세요. 회사 네트워크를 사용 중이라면 네트워크 담당자에게 실제 외부 연결 경로를 확인해 달라고 요청할 수 있습니다. 프록시 주소나 비밀번호를 공개할 필요는 없습니다.

이 글은 현재 국가 목록이나 해당 계정의 자격을 판정하지 않습니다. **공식 확인이 필요한 이 분기에서는 VPN으로 지역을 바꾸거나 다른 사람의 계정·토큰을 쓰는 복구를 제안하지 않습니다.** API 키 결제나 디바이스 코드 로그인이 해당 제한을 해제한다는 근거도 없습니다.

## 브라우저 콜백이 막혔을 때: 디바이스 코드 로그인과 SSH

브라우저가 로컬 콜백 주소에 연결하지 못하고 CLI가 기다리는 상황이라면, 브라우저와 CLI가 같은 머신인지 먼저 확인합니다. 이미 HTTP 교환 403과 정책 거부 본문을 받았다면 콜백을 바꾸는 것만으로 그 거부가 풀린다고 기대해서는 안 됩니다.

### 디바이스 코드는 허용 설정을 먼저 확인합니다

[공식 헤드리스 로그인 절차](https://learn.chatgpt.com/docs/auth#login-on-headless-devices)는 원격 환경이나 로컬 콜백이 막힌 경우 디바이스 코드 인증을 우선 권합니다. 현재 문서에서는 베타로 표시하며, 개인 계정은 ChatGPT 보안 설정에서, 워크스페이스 계정은 관리자가 권한 설정에서 먼저 허용해야 합니다.

허용된 환경에서는 Codex를 실행할 터미널에서 다음 명령을 사용합니다.

```bash
codex login --device-auth
```

터미널이 보여 준 링크를 자신의 브라우저에서 열고 같은 계정으로 로그인한 뒤 일회용 코드를 입력합니다. “ChatGPT 보안 설정 내 Codex용 장치 코드 인증을 활성화한 뒤 다시 실행하세요”라는 안내가 나오면 코드 발급을 반복하지 말고 해당 허용 조건을 확인하세요. 관리자가 허용하지 않은 워크스페이스에서는 관리자에게 요청하거나, 그 환경에서 허용된 다른 로그인 방식을 사용해야 합니다.

자신이 시작한 로그인에 대한 코드만 입력하고, 코드와 인증 URL을 다른 사람에게 보내지 않습니다. 이 방식은 브라우저에서 CLI로 돌아오는 루프백 연결을 대신하는 선택지이며, 국가·계정·기업 정책 거부를 없애는 수단은 아닙니다.

### SSH 터널은 브라우저 콜백을 원격 CLI로 전달합니다

디바이스 코드가 불가능하지만 SSH 포워딩과 일반 브라우저 로그인이 허용된다면, 자신의 로컬 컴퓨터에서 공식 문서의 기본 콜백 포트를 연결합니다.

```bash
ssh -L 1455:localhost:1455 user@remote
```

`user@remote`를 자신의 원격 접속 대상으로 바꿉니다. 이어서 **그 SSH 세션 안에서** 로그인합니다.

```bash
codex login
```

CLI가 출력한 로그인 주소를 로컬 브라우저에서 열면 콜백이 터널을 통해 원격 호스트로 전달됩니다. `1455`는 공식 문서의 기본 콜백 포트이며 프록시 포트가 아닙니다. 실제 CLI 안내의 포트가 다르거나 포트가 이미 사용 중이면 그 상태를 먼저 확인합니다. 로그인 포트를 인터넷에 공개하는 방식으로 해결하지 마세요. 자세한 원격 환경 선택과 예외는 [브라우저 없는 SSH 서버의 Codex 로그인 방법](https://blog.laozhang.ai/ko/posts/codex-headless-login)을 참고할 수 있습니다.

## 교환 요청의 연결·프록시·TLS 문제를 구분하세요

응답 본문에 회사 차단 페이지, block ID, 사내 문의처가 있으면 네트워크 담당자에게 그 기록을 전달합니다. 짧은 JSON이라는 이유만으로 OpenAI가 만든 응답이라고 확정하지 말고, 오류에 표시된 대상과 사내 경로를 함께 확인하세요. 접속 경로를 바꿔 비교할 때도 조직이 허용한 방법을 사용합니다.

Codex가 “운영체제 프록시는 무조건 무시하고 환경 변수만 읽는다”고 가정해서는 안 됩니다. [현재 공식 변경 기록](https://learn.chatgpt.com/docs/changelog)에는 로그인과 시작 요청에 시스템 프록시 fallback을 추가했다는 항목이 있습니다. 그 기록만으로 모든 플랫폼에서 동일하게 동작한다거나, HTTP 403이 나면 다른 프록시로 자동 해결된다고 결론 낼 수는 없습니다. 실행 버전과 시작 환경, 실제로 적용되는 승인된 프록시 경로를 확인하는 것이 우선입니다.

루프백 콜백과 외부 토큰 교환은 목적지가 다릅니다. 로컬 콜백을 프록시에서 제외할지, 외부 인증 요청을 회사 프록시로 보낼지는 네트워크 정책에 맞춰 따로 확인하세요. 모든 OpenAI 도메인을 `NO_PROXY`에 한꺼번에 넣으면 필수 회사 경로를 건너뛰거나 연결 자체가 끊길 수 있습니다. 프록시 설정을 비교하려고 환경 변수 전체를 출력하면 URL 속 비밀번호가 노출될 수도 있습니다.

인증서 체인 오류는 HTTP 403과 구분합니다. 회사 TLS 검사나 사설 루트 CA를 사용하는 환경에서 인증서 검증 실패가 확인됐을 때만 보안팀이 제공한 PEM 묶음을 지정하세요.

```bash
export CODEX_CA_CERTIFICATE="/path/to/corporate-root-ca.pem"
codex login
```

경로를 실제 승인된 PEM 파일로 바꿉니다. [공식 사용자 지정 CA 안내](https://learn.chatgpt.com/docs/auth#custom-ca-bundles)에 따르면 `CODEX_CA_CERTIFICATE`가 없을 때 `SSL_CERT_FILE`을 사용하며, 같은 설정은 로그인·일반 HTTPS·보안 WebSocket 연결에 적용됩니다. CA 설정은 신뢰할 인증서를 알려 주는 것이지 권한 거부를 해제하는 것이 아닙니다. 인증서 오류가 사라진 뒤에도 403이 남으면 그 응답 본문에 따라 다음 분기로 넘어갑니다. TLS 검증을 끄거나 출처를 모르는 인증서를 설치하지 않습니다.

## 저장된 인증 정보만 다시 만들기: 파일 삭제보다 먼저 할 일

계정·정책 거부가 없고, 접속 조건을 고쳤거나 저장된 로그인 상태를 갱신해야 한다면 정상 로그아웃과 재로그인을 사용합니다. CLI와 IDE 확장은 같은 로그인 캐시를 공유하므로, 한쪽에서 로그아웃하면 다른 쪽도 다시 로그인해야 할 수 있습니다. [로그인 캐시 설명](https://learn.chatgpt.com/docs/auth#login-caching)

```bash
codex logout
codex login
codex login status
```

단, 프로세스가 워크로드 ID 인증(workload identity)을 선택한 환경에서는 `codex login`과 `codex logout`이 거부됩니다. 이 경우 인증을 정하는 것은 프로세스 환경이므로, 사람이 쓰는 로그인 캐시를 초기화하지 말고 해당 자동화의 인증 담당자에게 확인해야 합니다. 위 명령을 모든 CI 환경에 적용하지 마세요. [현재 인증 안내](https://learn.chatgpt.com/docs/auth#check-authentication-or-sign-out)

`auth.json`이 안 보인다고 로그인 정보가 없다고 판단하지 않습니다. [공식 저장 방식](https://learn.chatgpt.com/docs/auth#credential-storage)은 다음과 같습니다.

| `cli_auth_credentials_store` | 저장 위치 또는 동작 | 복구할 때 주의할 점 |
| --- | --- | --- |
| `file` | `CODEX_HOME` 아래의 `auth.json`. 기본 홈은 `~/.codex` | 사용자 지정 `CODEX_HOME`이면 기본 경로를 지워도 대상이 다름 |
| `keyring` | 운영체제 자격 증명 저장소 | `auth.json` 삭제로 이 저장소가 초기화되지는 않음 |
| `auto` | OS 저장소를 우선 사용하고 불가능하면 파일로 저장 | 파일 존재만으로 전체 로그인 상태를 판단하지 않음 |
| `ephemeral` | 현재 프로세스 메모리 | 프로세스가 끝나면 인증 정보를 유지하지 않음 |

그래서 `rm -rf ~/.codex`는 첫 복구 명령이 될 수 없습니다. 구성과 상태, 진단 자료까지 함께 잃을 수 있고 실제 자격 증명 저장소는 다른 곳일 수 있습니다.

공식 문서에는 브라우저가 있는 머신에서 로그인한 **자신의 파일 기반 캐시**를 신뢰하는 헤드리스 머신으로 옮기는 대안도 있습니다. 실제 파일이 존재하고, 대상 머신과 전송이 안전하며, 조직이 허용한 저장 방식일 때에만 적용합니다. keyring에 저장된 정보를 파일이 있다고 가정해 복사하거나, 다른 사람의 토큰을 받아 사용하는 절차가 아닙니다. 파일은 비밀번호처럼 다뤄야 하므로, 안전하게 적용할 조건이 불명확하면 [공식 캐시 복사 절차](https://learn.chatgpt.com/docs/auth#login-on-headless-devices)를 확인하고 다른 허용된 로그인 방식을 선택하세요.

![국가·계정·정책 거부, 콜백 미도달, TLS 오류, 로그인 캐시, 워크로드 ID와 API 별도 전환에 따라 허용된 Codex 복구 방법을 고르는 개념도](https://blog.laozhang.ai/posts/ko/codex-token-exchange-failed-403/img/safe-recovery.webp)

## 회사 워크스페이스 거부는 관리자 설정과 맞춰야 합니다

계정은 맞는데 특정 회사 워크스페이스에서만 실패한다면, 허용된 로그인 방식과 워크스페이스에 해당하는지 관리자에게 확인합니다. 개인 계정 로그인이 성공했다고 회사 워크스페이스 권한까지 확인된 것은 아닙니다.

[현재 관리형 인증 문서](https://learn.chatgpt.com/docs/enterprise/managed-configuration#manage-authentication-locally)는 로컬 시스템의 `requirements.toml` 또는 macOS MDM에서 다음을 제한할 수 있다고 설명합니다.

- `allowed_login_methods`: ChatGPT, API 또는 둘 다 허용.
- `allowed_chatgpt_workspaces`: 선택 가능한 ChatGPT 워크스페이스 제한.
- `cli_auth_credentials_store`: 인증 정보 저장 방식 강제.
- `chatgpt_base_url`: 관리형 서비스 주소 요구 사항.

이 조건은 자격 증명을 읽기 전에 적용됩니다. 허용 목록에 맞는 워크스페이스가 없으면 ChatGPT 로그인을 사용할 수 없고, API 인증도 허용된 경우에만 남습니다. 사용할 로그인 방식이 없으면 클라이언트가 시작을 거부합니다. 사용자 설정의 `forced_login_method`와 `forced_chatgpt_workspace_id`도 관리 요구 사항을 따라야 하므로 캐시 복사나 `config.toml` 수정으로 이를 덮어쓰는 것이 해법은 아닙니다.

이 네 필드는 클라우드 관리 요구 사항에서는 무시된다는 구분도 있습니다. 회사 환경에서는 클라우드 정책 화면만 보고 로컬 인증 제한이 없다고 판단하지 말고, 관리자에게 실제 적용된 로컬 요구 사항을 확인해 달라고 요청하세요. 관리자가 조건을 수정한 뒤에는 원래 워크스페이스와 실행 호스트에서 다시 확인합니다.

## API 키로 전환할 수 있는 경우와 복구 확인 방법

로컬 Codex를 API 과금으로 사용하려는 경우에는 API 키 로그인이 별도 선택지입니다. 조직이 허용하고, 자신이 관리하는 키가 해당 환경의 `OPENAI_API_KEY`에 안전하게 준비돼 있을 때 공식 CLI 예제는 다음과 같습니다.

```bash
printenv OPENAI_API_KEY | codex login --with-api-key
```

키를 명령 인자나 화면에 직접 쓰지 않고 stdin으로 전달합니다. [공식 인증 문서](https://learn.chatgpt.com/docs/auth#sign-in-with-an-api-key)에 따르면 API 사용량은 OpenAI Platform 계정에 표준 API 요금으로 별도 청구되며 ChatGPT 플랜의 포함 사용량을 쓰는 방식이 아닙니다. ChatGPT 워크스페이스나 클라우드에 의존하는 기능은 제한될 수 있고, Codex cloud는 ChatGPT 로그인이 필요합니다. API 경로에서 작업이 된 것은 API 인증을 확인한 결과이지 원래 ChatGPT 토큰 교환 403이 해결됐다는 증거가 아닙니다.

기업 자동화에서 관리자가 허용한 Codex 액세스 토큰을 제공한 경우에는 공식 문서의 `printenv CODEX_ACCESS_TOKEN | codex login --with-access-token`도 사용할 수 있습니다. 이는 허용된 구성원의 신뢰하는 비대화형 로컬 작업을 위한 인증이며, 일반 Platform API 키나 누구에게나 발급되는 대체 로그인 수단으로 보지 않습니다. [기업 자동화 인증 안내](https://learn.chatgpt.com/docs/auth#use-codex-access-tokens-for-enterprise-automation)

### 복구는 원래 호스트에서 작은 작업까지 확인합니다

로그인 명령이 끝나면 `codex login status`의 인증 방식이 의도한 것인지 확인합니다. 그다음 오류가 났던 호스트의 민감한 자료가 없는 작업 디렉터리에서 `codex`를 실행하고, 예를 들어 “파일을 읽거나 수정하지 말고 `AUTH_CHECK_OK`만 답하세요”라는 짧은 요청을 보냅니다. API 방식이면 이 요청도 API 과금 대상입니다.

확인할 결과는 세 가지입니다. 예상한 계정·워크스페이스 또는 API 인증을 쓰고 있는지, 해당 방식의 모델 요청이 실제 응답을 받는지, 원래 작업에 필요한 기능도 동작하는지입니다. 짧은 답변이 왔다고 모든 도구나 클라우드 기능까지 정상이라고 판단하지는 않습니다.

첫 요청에서 다른 오류가 나면 새 오류의 URL과 본문으로 다시 구분합니다. 특히 사용자 지정 공급자의 `selected provider is forbidden`이라면 로그인 교환이 아니라 그 공급자 요청의 거부입니다. [Codex Custom Provider의 API 키와 Base URL 설정](https://blog.laozhang.ai/ko/posts/codex-config-toml)에서 해당 구성을 점검할 수 있습니다. 현재 공식 인증 문서는 `requires_openai_auth = true`이면 OpenAI 인증을 사용하고 `env_key`를 무시한다고 설명합니다. 다른 공급자의 키를 쓰려던 설정이라면 이 관계를 확인하되, 거부 원인이 밝혀지기 전에 키를 임의의 새 주소로 보내지 마세요. [사용자 지정 공급자 인증](https://learn.chatgpt.com/docs/auth#alternative-model-providers)

## 같은 거부가 남으면 지원팀에 넘길 기록을 정리합니다

명시적인 국가·계정·워크스페이스·정책 거부는 해당 공식 지원이나 관리자에게 전달합니다. 그 외에는 확인된 조건을 하나 수정한 뒤에도 같은 단계와 본문으로 실패하는지 보세요. 변화 없이 같은 로그인을 반복하는 것보다 그 기록을 넘기는 편이 다음 확인에 도움이 됩니다.

```text
발생 시각과 시간대: <예: 2026-10-05 14:20 KST>
OS / 실행 환경: <로컬, WSL, 컨테이너, SSH>
Codex 버전: <codex --version 결과>
인증 방식: <ChatGPT, 디바이스 코드, API 키, 액세스 토큰, 워크로드 ID>
실패 단계: <콜백, 토큰 교환, 저장, 로그인 후 요청>
오류: <비밀을 제거한 전체 문구, 상태 코드, 짧은 오류 코드>
request ID: <있으면 기록>
연결 조건: <직접 연결, 승인된 회사 프록시, TLS 검사 여부>
변경과 결과: <무엇 하나를 바꿨고 어떤 단계가 달라졌는지>
```

토큰, API 키, 전체 `auth.json`, Cookie, 디바이스 코드, 전체 callback URL, 프록시 비밀번호는 제출하지 않습니다. 네트워크 차단 기록은 네트워크 담당자에게, 워크스페이스 허용 목록은 관리자에게, 공식 인증 경로의 지속적인 교환 실패는 OpenAI 지원에 전달하면 서로 다른 문제를 한 문의에 섞는 일을 줄일 수 있습니다.

## 자주 묻는 질문

### 브라우저에서 성공했는데 `login status`가 정상이어도 실패할 수 있나요?

있습니다. 브라우저 승인은 인증 과정의 일부이고, `codex login status`의 종료 코드 `0`은 자격 증명이 있다는 뜻입니다. 서버가 받아들이는지 확인하려면 같은 실행 호스트와 인증 방식에서 작은 작업 요청까지 완료해야 합니다. [CLI 상태 명령의 정의](https://learn.chatgpt.com/docs/developer-commands#codex-login)

### 디바이스 코드 인증을 켜라는 안내도 403 복구에 해당하나요?

그 안내가 표시된 로그인은 먼저 허용 설정을 확인해야 합니다. 개인 계정은 ChatGPT 보안 설정, 워크스페이스는 관리자 권한 설정이 적용됩니다. 허용된 뒤 `codex login --device-auth`를 다시 실행하되, 디바이스 코드가 다른 계정·국가·기업 정책 거부까지 해결하지는 않습니다. [공식 디바이스 코드 절차](https://learn.chatgpt.com/docs/auth#login-on-headless-devices)

### `auth.json`을 지우면 토큰 교환 403이 해결되나요?

항상 그렇지는 않습니다. 자격 증명은 파일 또는 OS 저장소에 있을 수 있고, 403은 자격 증명과 무관한 이유로도 발생합니다. 저장된 로그인을 다시 만들 필요가 확인되면 `codex logout`과 허용된 로그인을 사용하세요. 워크로드 ID 환경에서는 이 두 명령이 거부되므로 프로세스의 인증 설정을 확인해야 합니다. [인증 정보 저장과 로그아웃 안내](https://learn.chatgpt.com/docs/auth)

## 참고 자료

이 글이 링크한 외부 페이지를 본문에 나온 순서대로 정리했습니다. 마지막 업데이트: 2026-10-06.

- [HTTP 403 표준](https://www.rfc-editor.org/rfc/rfc9110.html) (rfc-editor.org)
- [CLI 명령 문서](https://learn.chatgpt.com/docs/developer-commands) (learn.chatgpt.com)
- [공식 인증 문서의 로그인 진단 안내](https://learn.chatgpt.com/docs/auth) (learn.chatgpt.com)
- [OpenAI 상태 페이지](https://status.openai.com/) (status.openai.com)
- [공식 ChatGPT 지원 국가 안내](https://help.openai.com/en/articles/7947663-chatgpt-supported-countries) (help.openai.com)
- [OpenAI 지원](https://help.openai.com/) (help.openai.com)
- [현재 공식 변경 기록](https://learn.chatgpt.com/docs/changelog) (learn.chatgpt.com)
- [현재 관리형 인증 문서](https://learn.chatgpt.com/docs/enterprise/managed-configuration) (learn.chatgpt.com)