# Codex account/read failed during TUI bootstrap 오류: 마지막 문구별 해결

> `codex`가 TUI를 띄우기 전에 꺼지는 오류는 시작 시 account/read 요청 실패입니다. 조치는 마지막 문구로 갈리며, 백그라운드 서버 재시작·재로그인·프록시 설정 순으로 짚습니다.

- URL: https://blog.laozhang.ai/ko/posts/codex-account-read-failed-tui-bootstrap
- Published: 2026-10-17
- Updated: 2026-10-17
- Author: LaoZhang AI Team (https://blog.laozhang.ai/ko/about)
- Topic: 개발 도구·에이전트
- Tags: OpenAI Codex, Codex CLI, ChatGPT 로그인, app-server, 문제 해결

---
터미널에서 `codex`를 입력했는데 대화 화면이 그려지기 전에 아래 한 줄만 찍고 프로세스가 끝난다면, Codex CLI가 TUI(터미널 대화 화면)를 띄우기 직전에 app-server로 보내는 `account/read` 요청이 실패한 것입니다.

```text
Error: account/read failed during TUI bootstrap: account/read failed: workspace routing discovery failed (code -32603)
```

`codex login status`는 그대로 `Logged in using ChatGPT`라고 답하고 `codex exec "…"`는 돌아가는 경우가 있어 모순처럼 보이지만, 로그인이 풀린 것이 아니라 시작 절차의 한 단계가 막힌 것입니다. 단서는 두 번째 `account/read failed:` 뒤에 붙는 마지막 문구입니다. 끝의 `(code -32603)`은 JSON-RPC의 범용 내부 오류 코드(internal error)여서 어느 문구에나 똑같이 붙고, HTTP 상태 코드도 아니라서 원인을 알려 주지 못합니다. 마지막 문구가 `workspace routing discovery timed out`이나 `discovery failed`면 백그라운드 서버(daemon) 상태나 프록시가, `unauthorized (401)`이나 `failed to load workspace requirements`면 오래되거나 취소된 ChatGPT 토큰이, `duplicate workspace`면 계정 쪽 워크스페이스 문제가, `plan type is required`면 뒤섞인 자격 증명이 먼저 의심 대상입니다.

2026년 10월 17일 기준으로 OpenAI는 이 오류 계열에 대한 공식 원인이나 수정 사항을 내놓지 않았습니다. 2026년 4월에 열린 GitHub 이슈 #17800에 남은 OpenAI 쪽 답은 4월 14일 재현 절차를 묻는 한 줄이 마지막이고, 10월의 이슈와 커뮤니티 글에는 공식 답이 없습니다. 아래 설명의 근거는 세 갈래입니다. 오류 문구 목록과 15초 제한은 공개된 Codex 소스 코드에서, 명령과 옵션이 실제로 존재하는지는 ChatGPT 데스크톱 앱에 번들된 codex-cli 0.163.0-alpha.10.2에서 `--help`, `codex login status`, `codex doctor --summary --no-color`, `codex app-server daemon version` 네 가지를 직접 실행한 출력에서, 해결책은 날짜가 붙은 GitHub 이슈와 OpenAI 개발자 커뮤니티 글에서 가져왔습니다. 직접 실행한 것은 그 네 가지까지이며, 이 오류를 재현하거나 어떤 해결책의 효과를 시험하지는 않았습니다. 그래서 아래의 조치는 모두 "그렇게 해서 풀렸다는 보고"이고, 조치마다 출처와 날짜를 붙였습니다.

## account/read가 하는 일: 워크스페이스 라우팅 탐색과 15초 제한

Codex TUI는 시작하면서 app-server에 JSON-RPC 요청 `account/read`를 보냅니다. 이 요청이 오류로 돌아오면 TUI는 `account/read failed during TUI bootstrap: …`으로 감싸고, 그 안의 JSON-RPC 오류는 `account/read failed: 메시지 (code 번호)` 꼴로 찍힙니다. 그래서 한 줄에 `account/read failed`가 두 번 나옵니다. 같은 틀이 `model/list`, `configRequirements/read`, `thread/start`, `thread/fork`에도 있어서, 첫 줄이 비슷한 `thread/start failed during TUI bootstrap`은 시작 절차의 다른 단계에서 난 다른 오류입니다([Codex TUI 소스 app_server_session.rs](https://github.com/openai/codex/blob/main/codex-rs/tui/src/app_server_session.rs)).

ChatGPT 계정으로 로그인한 상태라면 `account/read`는 저장된 자격 증명을 읽는 데서 끝나지 않습니다. app-server가 ChatGPT 백엔드의 `accounts/check`에 요청을 보내 그 계정의 워크스페이스 라우팅(workspace routing)을 알아내고, 클라우드에 있는 워크스페이스 요구 사항(workspace requirements) 묶음까지 불러옵니다. 이 전체 읽기에는 15초 제한이 걸려 있어, 넘기면 `workspace routing discovery timed out`이 됩니다. 라우팅 단계의 오류는 JSON-RPC `internal error`인 -32603으로, 계정 상태 자체가 유효하지 않으면 `invalid request`인 -32600으로 돌아옵니다([Codex app-server 소스 workspace_routing.rs](https://github.com/openai/codex/blob/main/codex-rs/app-server/src/request_processors/account_processor/workspace_routing.rs)). 데스크톱 앱 로그에 `durationMs=15002 errorCode=-32603 method=account/read`가 남고(이슈 #49921), WSL2에서 `account/read`가 15.016초 걸린 뒤 실패한 보고(이슈 #51052)가 있는 이유입니다.

여기서 워크스페이스는 ChatGPT 로그인 때 고르는 개인·조직 공간을 뜻합니다. 프로젝트 폴더나 VS Code 워크스페이스가 아닙니다. 또 모든 실패가 시간 초과는 아닙니다. 기본 실행이 1.63초 만에 `discovery failed`로 끝난 사례(이슈 #52928, 2026년 10월 10일)가 있어, 문구가 `failed`면 15초를 기다리지도 않고 요청이 거부된 쪽입니다. API 키로 로그인했을 때는 이 탐색을 돌리지 않는다는 점이 소스 코드의 테스트(`api_only_login_does_not_discover_chatgpt_routing`)로 확인됩니다.

같은 첫 줄이라도 시기에 따라 원인이 다릅니다. 2026년 4월의 보고는 마지막 문구가 없는 `Error: account/read failed during TUI bootstrap`이었고 원인이 오래된 인증 캐시였습니다. 2026년 9월 말부터 늘어난 보고는 `(code -32603)`이 붙은 형태이고, 0.157.0(2026년 9월 25일)부터 기본으로 켜진 백그라운드 서버와 함께 나타났습니다. 옛 형태는 문구별 절의 마지막에서 따로 다룹니다.

## 점검 세 가지: login status, daemon version, doctor --summary

조치를 고르기 전에 아래 세 명령을 돌려 두면 마지막 문구와 맞춰 볼 재료가 생깁니다. 모두 읽기 전용이고 세션 기록에 손대지 않습니다.

```bash
codex login status
codex app-server daemon version
codex doctor --summary --no-color
```

- `codex login status`는 ChatGPT 로그인인지 API 키인지 알려 줍니다. 다만 `Logged in using ChatGPT`가 나와도 토큰이 취소됐을 수 있습니다. 이슈 #54184(10월 15일)와 #47456(9월 23일) 모두 이 줄은 정상인데 백엔드가 401을 돌려준 사례입니다. 이 줄이 정상이라는 것은 "자격 증명 파일이 있다"는 뜻에 가깝습니다.
- `codex app-server daemon version`은 백그라운드 서버가 돌고 있으면 `cliVersion`, `appServerVersion`, `managedCodexVersion`을 JSON으로 찍습니다. 한 보고의 출력은 `{"status":"running","backend":"pid","managedCodexVersion":"0.162.1","cliVersion":"0.162.1","appServerVersion":"0.162.1"}`이었습니다(이슈 #52928, 10월 15일). 서버가 없으면 `Error: failed to connect to ~/.codex/app-server-control/app-server-control.sock` 뒤에 `No such file or directory (os error 2)`가 나옵니다. 이 하위 명령은 CLI 자체의 `--help`에는 있지만 [OpenAI의 Codex 개발자 명령 문서](https://learn.chatgpt.com/docs/developer-commands?surface=cli)에는 아직 없습니다.
- `codex doctor --summary --no-color`는 그룹별 점검 행을 보여 줍니다. 볼 곳은 `Background Server` 그룹의 `app-server` 행(돌고 있는지, 아니면 `not running (ephemeral mode)`인지), `Connectivity` 그룹의 `websocket` 행(`connected (HTTP 101 Switching Protocols) · 15s timeout`), `network` 행(프록시 환경 변수 유무)입니다. `--summary`를 빼면 자세한 보고에 실행 중인 app-server 버전이 나와 CLI 버전과 비교할 수 있습니다. 커뮤니티 글의 작성자가 0.162.0 CLI와 0.161.0 서버의 불일치를 찾아낸 곳이 이 보고입니다.

네 번째로 `codex --no-daemon`을 한 번 실행해 보는 것도 진단이 됩니다. 이것으로 TUI가 열리면 문제는 공유 백그라운드 서버 경로에 있습니다(이슈 #52928, 10월 10일과 15일). 단, `duplicate workspace`에는 `--no-daemon`도 같은 오류를 냅니다(이슈 #47034, 9월 23일).

![codex login status, codex app-server daemon version, codex doctor --summary --no-color 세 점검 명령과 각 출력에서 읽을 줄, 네 번째 진단 codex --no-daemon을 정리한 그림](https://blog.laozhang.ai/posts/ko/codex-account-read-failed-tui-bootstrap/img/three-read-only-checks.webp)

## 마지막 문구별 원인과 조치 (2026년 10월 17일 기준)

| 마지막 문구 | 코드상 의미 | 보고된 원인 | 먼저 할 것 |
| --- | --- | --- | --- |
| `workspace routing discovery timed out` | 15초 안에 탐색이 끝나지 않음 | 오래 떠 있던 백그라운드 서버, 서버가 물려받은 프록시 환경, WSL2, 회사망 | `codex app-server daemon restart`, 프록시 환경 변수 |
| `workspace routing discovery failed` | 탐색 요청이 실패(시간 초과도 401도 아님) | 위와 같음, 그리고 CLI와 서버의 버전 불일치 | `daemon version`으로 버전 비교 뒤 `update --from-cli --yes` 또는 `restart` |
| `failed to load workspace requirements` | 클라우드 요구 사항 묶음을 못 불러옴, 실제 이유는 가려짐 | 취소된 토큰(401 token_revoked) | 재로그인 후 옛 토큰을 쥔 프로세스 종료 |
| `workspace routing discovery unauthorized (401)` | 백엔드가 401 | 계정 권한이나 플랜 변경 뒤 남은 옛 토큰 | 자격 증명이 있는 그 머신에서 재로그인 |
| `duplicate workspace in routing discovery` | 탐색 결과에 같은 워크스페이스가 둘 | 계정에 같은 이름의 Personal 워크스페이스가 둘 | 사용자 쪽 해결책 없음, 지원 티켓 |
| `selected workspace missing from routing discovery` | 저장된 선택이 탐색 결과에 없음 | 공개 보고 없음 | 재로그인하고 워크스페이스 다시 선택(추론) |
| `plan type is required for chatgpt authentication (code -32600)` | 토큰에 plan type이 없음 | 중계 서비스가 발급했거나 뒤섞인 자격 증명 | `codex logout` 후 공식 로그인 또는 API 키 |

![마지막 문구 네 갈래별 의심 원인과 먼저 할 조치, npm으로 올린 CLI와 옛 사본으로 도는 백그라운드 서버의 버전 차이를 보여 주는 그림](https://blog.laozhang.ai/posts/ko/codex-account-read-failed-tui-bootstrap/img/last-phrase-cause-action.webp)

### workspace routing discovery timed out / failed: 백그라운드 서버부터

두 문구는 보고에서 같은 조치로 풀린 경우가 많아 함께 봅니다. 가장 많이 확인된 조치는 백그라운드 서버 재시작입니다.

- [OpenAI 개발자 커뮤니티의 "Codex CLI 0.162.0 fails during TUI bootstrap" 글](https://community.openai.com/t/1404666)(2026년 10월 9일, Linux Mint, ChatGPT 로그인, 로컬 프록시): `codex app-server daemon restart` 뒤 `codex`가 열렸고, 설정·자격 증명·대화 기록은 지우지 않았습니다. 자세한 `doctor` 보고에서 CLI 0.162.0과 서버 0.161.0의 불일치를 발견했고, 프록시의 SOCKS 포트를 HTTP 포트 자리에 넣어 407이 났던 문제도 따로 고쳤지만 서버를 재시작하기 전까지는 계속 실패했다고 적었습니다. 작성자 스스로 옛 서버 버전과 묵은 프록시 설정 중 어느 쪽이 원인인지 단정하지 못했습니다. 채택 답변입니다.
- [openai/codex 이슈 #52928: -c 덮어쓰기로만 시작되는 문제](https://github.com/openai/codex/issues/52928): 10월 15일 Arch Linux 사용자는 CLI 0.162.1인데 `appServerVersion`이 0.160.0이어서 `codex app-server daemon update --from-cli --yes`로 맞추자 시작됐고, 같은 날 다른 사용자는 세 버전이 모두 0.162.1로 같았는데도 `restart`만으로 풀렸습니다. 후자는 프록시를 거친 `curl`이 `accounts/check`에서 0.46초 만에 401(인증 없이 보냈으니 정상)을 받아 네트워크는 멀쩡했고, 오래 떠 있던 서버의 묵은 상태나 물려받은 프록시 환경 변수를 의심했습니다.
- [openai/codex 이슈 #48894: VS Code 확장의 Sign-in failed](https://github.com/openai/codex/issues/48894): 9월 29일 `pkill -f codex`, `codex login status`, `codex` 순서가 올라왔고 10월 5일과 6일에 두 명이 효과를 확인했습니다.
- [openai/codex 이슈 #17800: 4월에 열린 원래 이슈](https://github.com/openai/codex/issues/17800): 10월 11일과 15일 댓글도 `codex app-server daemon restart`로 풀렸다고 적었습니다.

왜 서버 재시작이 통하는지에 대한 공식 설명은 없지만, 백그라운드 서버의 동작 방식이 배경입니다. 0.157.0(2026년 9월 25일)부터 대화형 `codex`는 `codex app-server --managed-daemon`이라는 서버를 띄워 두고 창을 닫아도 유지하며, 별도의 업데이터가 패키지를 `~/.codex/packages/app-server-daemon/releases/` 아래에 복사해 그 사본으로 서버를 돌립니다. 그래서 npm으로 CLI를 올려도 돌고 있는 서버는 옛 버전일 수 있습니다. 또 서버는 처음 띄운 세션의 환경 변수(프록시 포함)를 그대로 유지합니다([openai/codex 이슈 #48195: daemon_auto_start를 opt-in으로 바꿔 달라는 요청](https://github.com/openai/codex/issues/48195), 9월 25일). 프록시를 바꾼 뒤에도 서버가 옛 프록시로 나가고 있었다면 재시작 없이는 반영되지 않는다는 뜻입니다.

프록시와 네트워크 쪽 보고는 따로 묶입니다.

- 데스크톱 앱(macOS, 10월 1일, [openai/codex 이슈 #49921: HTTP_PROXY를 줘야 라우팅이 되는 macOS 데스크톱](https://github.com/openai/codex/issues/49921)): `account/read`가 15초 걸려 실패하고 `/wham/usage` 등이 HTTP 432 `Workspace routing is unavailable`을 받았습니다. Electron의 `--proxy-server` 옵션은 효과가 없었고, `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY` 환경 변수를 준 채로 앱을 띄우자 열렸습니다.
- CLI(10월 12일, 이슈 #52928 댓글): `~/.codex/.env` 파일에 `http_proxy`, `https_proxy`, `NO_PROXY`를 적어 두고 재시작해 풀렸다는 사용자가 한 명 있습니다. 이 파일은 공식 문서에 없는 방법입니다.
- 회사망(10월 16일, [openai/codex 이슈 #50211: macOS CLI의 discovery failed](https://github.com/openai/codex/issues/50211) 댓글): `chatgpt.com`은 막혀 있고 `*.openai.com`은 열려 있어 로그인은 되는데 그 뒤가 전부 실패했습니다. 로그인 성공이 네트워크 정상을 뜻하지 않는 경우입니다.
- 0.163.0(10월 15일)은 `accounts/check`와 `config/bundle` 같은 시작 단계 GET 요청이 실패하면 시스템 프록시로 다시 시도하도록 바뀌었습니다([openai/codex PR #52702](https://github.com/openai/codex/pull/52702)). 단, 401·403·407·429·503 응답은 재시도 대상이 아닙니다. 회사 TLS 검사 장비가 있다면 OpenAI 인증 문서대로 `CODEX_CA_CERTIFICATE`에 PEM 묶음을 지정하고, 없으면 `SSL_CERT_FILE`로 대체됩니다.

프록시를 쓰는 환경에서 시도할 때는 변수를 준 뒤 서버를 재시작하고 다시 실행합니다.

```bash
export HTTPS_PROXY=$PROXY_URL
export HTTP_PROXY=$PROXY_URL
codex app-server daemon restart
codex
```

WSL2는 별도 사례입니다. 같은 계정, 같은 0.160.0에서 Windows는 `account/read`가 0.422초에 성공하고 WSL2는 15.016초 뒤 시간 초과였으며 `codex exec`는 양쪽 다 됐습니다([openai/codex 이슈 #51052: WSL2에서만 15초 뒤 실패](https://github.com/openai/codex/issues/51052), 10월 5일). 어느 단계가 멎는지는 밝혀지지 않았습니다. 0.162.0부터 Windows 드라이브에 홈이 있는 WSL(DrvFS/9p)은 백그라운드 서버를 자동으로 띄우지 않고 경고와 함께 내장 모드(embedded mode, 공유 서버 없이 그 프로세스 안에서 app-server를 돌리는 방식)로 돕니다.

확인은 `codex`가 열리는지와 `codex app-server daemon version`의 세 버전이 같은지로 합니다. 오래 떠 있던 서버가 파일 디스크립터를 다 써서 다른 시작 단계가 `(os error 24)`로 실패한 보고([openai/codex 이슈 #37971: 8일 떠 있던 서버의 디스크립터 고갈](https://github.com/openai/codex/issues/37971), 8월 11일)도 같은 "묵은 서버" 부류라 재시작으로 풀렸고, 0.162.0은 관리형 서버의 한도를 4096으로 올렸습니다.

### failed to load workspace requirements: 가장 답이 약한 문구

이 문구는 2026년 10월 17일 기준 가장 답이 약합니다. 세 가지가 겹쳐서입니다.

첫째, 실제 이유가 가려집니다. 출시된 0.162.1과 0.163.0은 `failed to load workspace requirements (code -32603)`까지만 찍지만, 현재 `main` 소스는 뒤에 `cloud config: authentication failed (HTTP 401)`, `cloud config: request timed out`, `cloud config: invalid bundle` 같은 정리된 이유를 덧붙입니다. 지금 설치된 빌드에서는 이유가 빠진 문구만 볼 가능성이 큽니다.

둘째, 실체가 인증 실패였던 사례가 있습니다. [openai/codex 이슈 #54184: 실제 원인은 401 token_revoked](https://github.com/openai/codex/issues/54184)(10월 15일, 0.162.1, macOS, ChatGPT 로그인)에서는 모든 백엔드 호출이 `401 token_revoked`를 돌려주고 있었는데 TUI는 이 범용 문구만 보여 줬습니다. 새로 `codex login`을 해도 이미 떠 있던 TUI와 백그라운드 서버가 취소된 토큰을 계속 쓰다가, 그 프로세스들을 종료한 뒤에야 풀렸습니다. 그래서 순서는 `codex logout`, `codex login`, `codex app-server daemon restart`(또는 `stop`), `codex`입니다.

셋째, 최신 안정판에서도 재현됩니다. [OpenAI 개발자 커뮤니티의 0.163.0 보고](https://community.openai.com/t/1407111)(10월 17일, macOS, ChatGPT Plus)는 `codex login status`가 정상이고 로그아웃과 재로그인도, 0.162.1에서 0.163.0으로의 업그레이드도 효과가 없었으며, `codex exec "Reply only with READY"`는 READY를 돌려줬다고 적었습니다. 글이 올라온 날 기준 답글은 없고, 같은 문구를 0.162.1에서 겪었다는 다른 보고도 있습니다. `-c log_dir="…"`를 주면 열린다는 보고([openai/codex 이슈 #52775: 0.162.1 업그레이드 뒤 -c log_dir로만 시작](https://github.com/openai/codex/issues/52775), 10월 10일과 14일)와 `touch ~/.codex/log/codex-tui.log`만으로 열렸다는 보고(같은 이슈, 10월 15일)도 있는데, `-c`는 내장 모드를 강제하기 때문에 설명이 되고(아래 순서 절 참조), `touch` 쪽은 단독 사례로 이유가 밝혀지지 않았습니다.

이 문구에서 재로그인과 서버 재시작까지 했는데도 0.163.0에서 계속 실패하면, 현재로서는 알려진 사용자 쪽 해결책이 없습니다. `codex --no-daemon`으로 열리는지 확인해 작업을 이어 가고, `codex doctor --json` 결과와 함께 이슈나 커뮤니티에 올리는 것이 남은 선택입니다.

### workspace routing discovery unauthorized (401): 그 머신에서 재로그인

백엔드가 401을 돌려준 경우로, `codex login status`가 정상이어도 토큰이 더는 받아들여지지 않는 상태입니다. [openai/codex 이슈 #47456: 원격 호스트에 남은 옛 ChatGPT 인증](https://github.com/openai/codex/issues/47456)(9월 23일, 원격 Linux 호스트, 0.154.0에서 0.156.1로 올리는 중)에서는 계정에 새 권한이 부여된 직후 이 문구가 나타났고, 그 원격 호스트에서 `codex login --device-auth`로 다시 로그인하자 바로 풀렸습니다. 보고자는 권한 변경을 "확정된 원인이 아니라 유력한 계기"라고 적었습니다. 같은 이슈의 10월 1일 댓글은 `--device-auth`가 성공했는데도 401이 계속됐고, 오래 떠 있던 `codex app-server` 프로세스가 옛 토큰을 쥐고 있어서 `pkill -f 'codex app-server'` 뒤에 정상화됐다고 덧붙였습니다.

핵심은 자격 증명이 저장된 바로 그 머신에서 다시 로그인하는 것입니다. 데스크톱 앱이 SSH로 원격 호스트에 붙어 있으면 로컬 쪽 메시지는 다른 인증 오류처럼 보일 수 있지만 묵은 자격 증명은 원격에 있습니다. 브라우저가 없는 서버에서의 `--device-auth` 절차는 [Codex 로그인: 브라우저 없는 SSH 서버에서 쓰는 방법 3가지와 선택 기준](https://blog.laozhang.ai/ko/posts/codex-headless-login)에 있습니다. `codex login` 단계 자체가 403으로 실패하는 것은 다른 오류이며 [Codex 토큰 교환 403 실패: 오류 문구별 로그인 복구 방법](https://blog.laozhang.ai/ko/posts/codex-token-exchange-failed-403)에서 다룹니다. TUI가 열린 뒤 모델 요청에서 `401 Incorrect API key provided`가 나는 것도 별개로, [Codex 401 Incorrect API key provided 오류 해결: URL과 키로 원인 가리기](https://blog.laozhang.ai/ko/posts/codex-401-incorrect-api-key)를 보면 됩니다.

### duplicate workspace in routing discovery: 계정 쪽 문제, 지원 티켓

이 문구는 계정의 탐색 결과에 같은 워크스페이스가 둘 들어 있다는 뜻이고, 2026년 10월 17일 기준 사용자 쪽에서 고칠 방법이 보고되지 않았습니다. [openai/codex 이슈 #47034: 로그인 성공 뒤 duplicate workspace](https://github.com/openai/codex/issues/47034)(9월 21일 개설, Windows와 macOS, CLI 0.155.0-alpha.9.2, 0.156.1, 0.160.0)에 모인 보고를 보면, 10월 3일 사용자는 ChatGPT 모바일 앱에 "Personal account / Personal"이 두 개 보였고, 10월 4일 사용자는 웹 로그인 화면에 "Personal account"가 두 번 나오는데 자기가 만든 적이 없다고 적었습니다. `codex logout`과 재로그인, `--device-auth`, 새 `CODEX_HOME`, `forced_chatgpt_workspace_id` 지정, 재설치, `--no-daemon`이 모두 효과가 없었고 `codex exec`도 `Reconnecting… 2/5`를 반복한 뒤 같은 문구로 실패했습니다.

과도기 수단은 두 가지가 보고됐는데 둘 다 믿을 만하지 않습니다. 0.154.0으로 내리자 한 명(9월 23일)은 됐고 다른 한 명(10월 4일)은 안 됐습니다. VS Code의 Codex 확장은 같은 계정에서 동작했다는 보고(10월 4일)가 있습니다. 사용자들은 OpenAI 지원에 티켓을 열었고, 지원 쪽은 `codex login status`, `codex doctor`, `codex-login.log`, 워크스페이스 ID를 요청했습니다. 이슈 안에 공식 답은 없습니다.

### selected workspace missing from routing discovery: 다시 선택

소스 코드에는 있는 문구지만 이 문구만 다룬 공개 보고는 2026년 10월 17일 기준 없습니다. 코드상 의미는 "저장된 워크스페이스 선택이 계정의 탐색 결과에 없다"이므로, 추론에 그치는 조치는 다시 로그인해 워크스페이스를 고르고, `config.toml`에 `forced_chatgpt_workspace_id`를 넣어 뒀다면 그 ID가 계정에 아직 있는 워크스페이스인지 확인하는 것입니다. [OpenAI의 Codex 설정 참조 문서](https://learn.chatgpt.com/docs/config-file/config-reference)는 이 키를 "ChatGPT 로그인을 특정 워크스페이스 ID로 제한"하는 용도로 설명하고, 자격 증명이 제한과 맞지 않으면 Codex가 로그아웃시키고 종료한다고 적습니다.

### plan type is required for chatgpt authentication: 뒤섞인 자격 증명

이 문구만 `(code -32600)`, 즉 `invalid request`로 끝납니다. 코드상 의미는 ChatGPT 방식의 자격 증명인데 토큰에 `plan_type` 값이 없다는 것입니다. 이메일은 없어도 되지만 plan type은 필수입니다([Codex model-provider 소스 provider.rs](https://github.com/openai/codex/blob/main/codex-rs/model-provider/src/provider.rs)). 공식 로그인으로 받은 토큰에는 이 값이 들어 있으므로, 제3자 중계 서비스가 발급한 `auth.json`을 넣었거나 그런 상태에서 공식 계정으로 되돌아오며 파일이 뒤섞였을 때 이 문구가 나온다는 것이 코드와 중국어 커뮤니티 글 제목(2026년 4월 7일, 10월 3일)에서 읽히는 추론입니다. 조치는 `codex logout`으로 저장된 자격 증명을 비우고 공식 ChatGPT 로그인을 다시 하거나, API 키를 쓸 생각이면 `printenv OPENAI_API_KEY | codex login --with-api-key`로 로그인 방식 자체를 바꾸는 것입니다.

같은 계열로, 커스텀 provider에 `env_key`를 지정하면서 `requires_openai_auth = true`를 함께 둔 경우가 있습니다. [OpenAI의 Codex 인증 문서](https://learn.chatgpt.com/docs/auth)대로 `requires_openai_auth = true`면 Codex는 `env_key`를 무시하고 OpenAI 인증을 쓰므로, TUI는 provider 키가 아니라 저장된 ChatGPT 인증 상태를 읽는 `account/read`를 타게 됩니다. 이슈 #17800의 4월 27일 댓글이 이 조합을 짚었고, 조치는 그 줄을 지우거나 `false`로 두는 것입니다. `[model_providers]` 설정 방법은 [Codex Custom Provider 설정: API 키와 Base URL 연결법](https://blog.laozhang.ai/ko/posts/codex-config-toml)에 있습니다.

### 마지막 문구가 없는 옛 줄: 4월의 auth 캐시 문제

`Error: account/read failed during TUI bootstrap`만 찍히고 뒤가 없다면 2026년 4월에 열린 이슈 #17800과 같은 경우입니다(0.120.0, API 키 사용자, Linux). 당시 보고자는 로그아웃과 로그인으로 풀렸고, 5월 14일 댓글은 `rm ~/.codex/auth.json` 뒤 재인증으로 충분하다고 적었습니다. `~/.codex` 전체를 지우는 방법도 올라왔지만 5월 9일 댓글대로 세션 기록이 모두 사라집니다. 이 4월의 절차를 지금의 기본 조치로 삼을 이유는 없습니다. 10월 11일 댓글은 `auth.json`을 지우고 재로그인해도 부족했고 `codex app-server daemon restart`로 풀렸다고 적었습니다.

## 세션 기록을 지우지 않는 순서: 재시작, --no-daemon, 재로그인, 프록시

마지막 문구를 읽었다면 아래 순서로 시도합니다. 앞쪽은 되돌릴 수 있고 기록을 건드리지 않는 조치, 뒤쪽은 잃는 것이 있는 조치입니다.

1. 위의 점검 세 가지를 돌려 로그인 방식, 서버 유무와 버전, `doctor` 행을 기록해 둡니다.
2. 백그라운드 서버가 돌고 있으면 `codex app-server daemon restart`를 실행합니다. 세 버전이 다르면 `codex app-server daemon update --from-cli --yes`로 CLI 패키지를 서버에 맞춥니다. 두 명령 모두 공유 서버를 쓰는 다른 Codex 창이나 에이전트의 작업을 끊을 수 있다고 CLI 도움말과 커뮤니티 글이 적습니다. 0.163.0부터는 TUI가 열린 상태라면 `/daemon` 명령으로도 재시작할 수 있지만, 이 오류는 TUI가 열리기 전에 나므로 터미널 명령이 필요합니다.
3. `codex --no-daemon`으로 여는지 봅니다. 열리면 공유 서버 경로의 문제로 범위가 좁혀집니다. 이것은 우회이지 수정이 아닙니다. 내장 모드에서는 `codex agents`와 원격 제어 같은 공유 서버 기능을 쓸 수 없습니다. `-c`, `--enable`, `--disable`, `--search` 옵션도 같은 효과를 내며, 이때 CLI는 `Running without the shared background server: command-line configuration overrides (-c, --enable, --disable, or --search) requires embedded mode.`라고 알려 줍니다. `-c log_dir=…`가 "통하는" 이유가 이것이고 `log_dir` 값 자체는 무관합니다. `config.toml`에 적은 `log_dir`는 효과가 없었습니다(이슈 #52928). 백그라운드 서버를 아예 끄려면 `codex features disable daemon_auto_start`(CLI 도움말에 있는 방법) 또는 `config.toml`의 `[features]`에 `daemon_auto_start = false`를 넣습니다(이슈 #48195, 9월 25일 Windows 사용자가 효과 확인). 이 키는 OpenAI 설정 문서에는 아직 없습니다.
4. 재로그인이 필요한 문구(`unauthorized (401)`, `failed to load workspace requirements`, `plan type is required`)라면 `codex logout`, `codex login`(원격 서버는 `codex login --device-auth`), 옛 토큰을 쥔 TUI와 서버 종료(`codex app-server daemon restart` 또는 `pkill -f 'codex app-server'`), `codex` 순서입니다. `codex logout`은 저장된 자격 증명만 지우고 세션 기록은 그대로 둡니다.
5. 프록시를 쓰면 `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`를 환경 변수로 주고 서버를 재시작합니다. 프록시 포트가 HTTP용인지(SOCKS 포트를 넣으면 407), `chatgpt.com`이 열려 있는지(`*.openai.com`만 열려 있으면 로그인만 성공) 확인합니다. 회사 TLS 검사는 `CODEX_CA_CERTIFICATE`입니다.
6. 커스텀 provider를 쓰면 `requires_openai_auth = true`와 `env_key`가 함께 있는지 보고 하나로 정리합니다.
7. 마지막에 남는 것이 `rm ~/.codex/auth.json`입니다. 로그인만 잃습니다. `~/.codex` 전체 삭제는 세션 기록까지 잃으므로 이 오류 때문에 할 일은 아닙니다.

조치가 통했는지는 `codex`가 TUI를 그리는지로 확인하고, 서버를 손댔다면 `codex app-server daemon version`에서 세 버전이 같은지 다시 봅니다. `tui.show_server_version_notice`는 기본값이 켜져 있어 연결된 서버 버전이 CLI와 다르면 TUI 안에 안내가 뜹니다.

## codex exec는 되는데 codex만 종료되는 이유

`codex exec`가 돌아간다는 것은 자격 증명과 네트워크가 모델 요청에는 충분하다는 뜻입니다. TUI만 종료되는 것은 TUI가 시작하면서 `account/read`를 먼저 보내고 그 응답이 오류면 화면을 그리지 않고 끝내도록 되어 있기 때문입니다. `codex exec`는 TUI를 그리지 않으므로 이 bootstrap 단계가 없습니다. 10월 17일의 0.163.0 보고와 10월 5일의 WSL2 보고가 모두 이 패턴이었습니다. 반대로 `duplicate workspace`는 라우팅 자체가 안 되는 계정 문제라 `codex exec`도 `Reconnecting… 2/5`를 반복하다 같은 문구로 실패했습니다(이슈 #47034). 즉 exec가 되는지 자체가 진단입니다. 되면 서버 상태, 토큰 갱신, 프록시 같은 "그 한 요청"의 문제이고, 안 되면 계정이나 네트워크 전체의 문제입니다.

TUI가 열린 뒤 메시지를 보내는 단계에서 실패하는 것은 또 다른 오류이며 [Codex 메시지 전송 오류 해결: 두 번째 줄 문구로 원인 찾기](https://blog.laozhang.ai/ko/posts/codex-error-submitting-message)에서 다룹니다.

## 데스크톱 앱의 Sign-in failed: workspace routing discovery timed out

ChatGPT 데스크톱 앱의 Codex와 VS Code 확장에서 보이는 `Sign-in failed: workspace routing discovery timed out`이나 `… discovery failed`는 같은 15초 탐색이 다른 표면에서 실패한 것입니다. 데스크톱 앱 로그에는 CLI와 똑같이 `account/read failed: workspace routing discovery failed (error code -32603)`가 남고, 이어서 `/wham/tasks/list`와 `/wham/usage`가 HTTP 432 `Workspace routing is unavailable`을 받습니다([openai/codex 이슈 #49443: macOS 데스크톱이 거의 매일 재로그인을 요구](https://github.com/openai/codex/issues/49443), 9월 30일). 증상은 매일 다시 로그인을 요구하는 형태로 나타나기도 합니다(Windows의 [openai/codex 이슈 #53236](https://github.com/openai/codex/issues/53236) 10월 12일, [openai/codex 이슈 #53520](https://github.com/openai/codex/issues/53520) 10월 13일의 `Login failed: workspace routing discovery timed out`).

보고된 조치도 CLI와 같은 부류입니다. 남은 프로세스 종료(VS Code 확장은 `pkill -f codex`, 이슈 #48894; macOS에서 앱을 종료해도 남아 있던 `Dock Extra (ChatGPT.app)` 프로세스를 끝내자 로그인된 사례, 이슈 #49921의 10월 15일 댓글), 앱을 `HTTP_PROXY`와 `HTTPS_PROXY` 환경 변수와 함께 실행(이슈 #49921), Windows에서 번들된 런타임 대신 외부 CLI를 `CODEX_CLI_PATH`로 지정(로그인 유지는 되지만 ChatGPT 메모리 기능을 못 쓰는 트레이드오프, [openai/codex 이슈 #47145](https://github.com/openai/codex/issues/47145), 9월 22일)입니다. Windows에서 어떤 Codex 프로세스가 남아 있어도 되는지는 [Windows의 Codex 백그라운드 프로세스: 종료해도 되는 상태 판별법](https://blog.laozhang.ai/ko/posts/codex-windows-background-processes)에 정리되어 있습니다. VS Code에서 30초 뒤 "could not start"가 뜨는 것은 다른 오류로 [Codex could not start VS Code 확장 오류: 원인별 해결, WSL은 1.141.2로](https://blog.laozhang.ai/ko/posts/codex-could-not-start-vscode)를 보면 됩니다.

## 0.163.0에서 고쳐졌나: 2026년 10월 17일 기준 수정 기록 없음

[openai/codex의 GitHub 릴리스 노트](https://github.com/openai/codex/releases)를 0.157.0부터 보면 이 오류를 고쳤다는 항목은 없습니다. 0.157.0(9월 25일)이 백그라운드 서버 자동 시작을 기본으로 켰고 "호환되지 않는 백그라운드 서버에 대한 명시적 복구 제안"을 넣었습니다. 0.161.0(10월 7일)은 서버 진단을 보고서에 남기게 했고, 0.162.0(10월 8일)은 Windows 드라이브의 WSL 홈을 자동 시작에서 빼고 관리형 서버의 파일 디스크립터 한도를 4096으로 올렸으며, 0.162.1은 10월 9일에 나왔습니다. 0.163.0(10월 15일, 최신 안정판)은 `/daemon`에서 서버 재시작, 시작 단계 GET 요청의 시스템 프록시 재시도, ChatGPT 인증이 없을 때 백그라운드 라우팅 읽기 생략을 담았습니다. 셋 다 이 오류 주변을 손보지만 `workspace routing discovery failed`나 `timed out`을 고쳤다고 적은 항목은 아니며, 0.163.0에서 `failed to load workspace requirements`가 그대로 난다는 보고가 10월 17일에 올라왔습니다. 0.164는 알파만 있고 노트가 비어 있습니다.

업그레이드가 서버 버전 불일치를 만들 수 있다는 점도 기억해 둘 만합니다. CLI를 올린 직후라면 `codex app-server daemon version`을 먼저 보고, 다르면 `update --from-cli --yes`나 `restart`를 돌립니다. 설치와 업그레이드 경로는 [Codex CLI 설치와 설정: Windows·macOS·Linux에서 바로 시작하기](https://blog.laozhang.ai/ko/posts/codex-cli-install)에 있습니다.

## 재시작과 로그아웃에 관한 질문

### daemon restart를 하면 다른 Codex 창도 끊기나요?

끊길 수 있습니다. 백그라운드 서버는 그 머신의 Codex 창과 `codex agents`가 공유하므로, 커뮤니티 글의 작성자도 "재시작이 진행 중인 Codex 세션을 끊을 수 있다"고 적었고, 0.163.0의 `/daemon` 재시작은 다른 채팅의 진행 중이거나 대기 중인 작업이 끊길 수 있다는 확인 창을 띄우며, `daemon update`의 도움말에도 "may interrupt running work"가 붙어 있습니다. 다른 창의 작업이 끝난 뒤에 돌리는 것이 안전합니다.

### codex logout 뒤 다시 로그인했는데 왜 같은 오류가 나나요?

이미 떠 있는 TUI와 백그라운드 서버가 옛 토큰을 계속 쓰기 때문인 경우가 보고됐습니다(이슈 #54184 10월 15일, 이슈 #47456의 10월 1일 댓글). 재로그인 뒤 `codex app-server daemon restart`나 `pkill -f 'codex app-server'`로 그 프로세스들을 끝내고 다시 실행합니다. 마지막 문구가 `duplicate workspace`라면 재로그인 자체가 효과가 없는 계정 쪽 문제입니다.

### -c log_dir를 주면 되는데 log_dir이 원인인가요?

아닙니다. `-c`는 어떤 키든 내장 모드를 강제해 공유 백그라운드 서버를 쓰지 않게 하고, 그래서 `-c model_reasoning_effort="medium"`을 줘도 똑같이 열렸습니다(이슈 #52928, 10월 10일). `config.toml`에 같은 `log_dir`를 적어도 효과가 없었다는 비교가 같은 이슈에 있습니다. 같은 효과를 내는 분명한 방법은 `codex --no-daemon`입니다.

### API 키로 로그인하면 이 오류를 피할 수 있나요?

API 키 로그인은 ChatGPT 워크스페이스 라우팅 탐색을 돌리지 않는다는 것이 소스 코드 테스트로 확인되고, 0.163.0부터는 ChatGPT 인증이 없을 때 app-server 시작 시의 백그라운드 라우팅 읽기도 건너뜁니다. 다만 요금 체계가 구독 크레딧에서 API 사용량 과금으로 바뀌므로, 비용 차이는 [Codex API 키와 ChatGPT 구독 차이: 크레딧 환산 비용과 손익분기점](https://blog.laozhang.ai/ko/posts/codex-api-key-vs-subscription)에서 확인한 뒤 결정하는 것이 맞습니다. 커스텀 provider에 `requires_openai_auth = true`가 남아 있으면 API 키를 써도 `account/read`를 타므로 그 설정부터 정리해야 합니다.

### thread/start failed during TUI bootstrap도 같은 원인인가요?

아닙니다. `thread/start`는 `account/read`가 지난 뒤 스레드를 만드는 다음 단계이고, TUI가 같은 `… failed during TUI bootstrap` 틀로 감싸기 때문에 첫 줄이 비슷해 보일 뿐입니다. `thread goal/set failed`, `Operation not permitted (os error 1)`도 각각 다른 단계의 오류로 별도 이슈가 있습니다.

## 참고 자료

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

- [Codex TUI 소스 app_server_session.rs](https://github.com/openai/codex/blob/main/codex-rs/tui/src/app_server_session.rs) (github.com)
- [Codex app-server 소스 workspace_routing.rs](https://github.com/openai/codex/blob/main/codex-rs/app-server/src/request_processors/account_processor/workspace_routing.rs) (github.com)
- [OpenAI의 Codex 개발자 명령 문서](https://learn.chatgpt.com/docs/developer-commands?surface=cli) (learn.chatgpt.com)
- [OpenAI 개발자 커뮤니티의 "Codex CLI 0.162.0 fails during TUI bootstrap" 글](https://community.openai.com/t/1404666) (community.openai.com)
- [openai/codex 이슈 #52928: -c 덮어쓰기로만 시작되는 문제](https://github.com/openai/codex/issues/52928) (github.com)
- [openai/codex 이슈 #48894: VS Code 확장의 Sign-in failed](https://github.com/openai/codex/issues/48894) (github.com)
- [openai/codex 이슈 #17800: 4월에 열린 원래 이슈](https://github.com/openai/codex/issues/17800) (github.com)
- [openai/codex 이슈 #48195: daemon_auto_start를 opt-in으로 바꿔 달라는 요청](https://github.com/openai/codex/issues/48195) (github.com)
- [openai/codex 이슈 #49921: HTTP_PROXY를 줘야 라우팅이 되는 macOS 데스크톱](https://github.com/openai/codex/issues/49921) (github.com)
- [openai/codex 이슈 #50211: macOS CLI의 discovery failed](https://github.com/openai/codex/issues/50211) (github.com)
- [openai/codex PR #52702](https://github.com/openai/codex/pull/52702) (github.com)
- [openai/codex 이슈 #51052: WSL2에서만 15초 뒤 실패](https://github.com/openai/codex/issues/51052) (github.com)
- [openai/codex 이슈 #37971: 8일 떠 있던 서버의 디스크립터 고갈](https://github.com/openai/codex/issues/37971) (github.com)
- [openai/codex 이슈 #54184: 실제 원인은 401 token_revoked](https://github.com/openai/codex/issues/54184) (github.com)
- [OpenAI 개발자 커뮤니티의 0.163.0 보고](https://community.openai.com/t/1407111) (community.openai.com)
- [openai/codex 이슈 #52775: 0.162.1 업그레이드 뒤 -c log_dir로만 시작](https://github.com/openai/codex/issues/52775) (github.com)
- [openai/codex 이슈 #47456: 원격 호스트에 남은 옛 ChatGPT 인증](https://github.com/openai/codex/issues/47456) (github.com)
- [openai/codex 이슈 #47034: 로그인 성공 뒤 duplicate workspace](https://github.com/openai/codex/issues/47034) (github.com)
- [OpenAI의 Codex 설정 참조 문서](https://learn.chatgpt.com/docs/config-file/config-reference) (learn.chatgpt.com)
- [Codex model-provider 소스 provider.rs](https://github.com/openai/codex/blob/main/codex-rs/model-provider/src/provider.rs) (github.com)
- [OpenAI의 Codex 인증 문서](https://learn.chatgpt.com/docs/auth) (learn.chatgpt.com)
- [openai/codex 이슈 #49443: macOS 데스크톱이 거의 매일 재로그인을 요구](https://github.com/openai/codex/issues/49443) (github.com)
- [openai/codex 이슈 #53236](https://github.com/openai/codex/issues/53236) (github.com)
- [openai/codex 이슈 #53520](https://github.com/openai/codex/issues/53520) (github.com)
- [openai/codex 이슈 #47145](https://github.com/openai/codex/issues/47145) (github.com)
- [openai/codex의 GitHub 릴리스 노트](https://github.com/openai/codex/releases) (github.com)