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

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

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).

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). 데스크톱 앱 로그에 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

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

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 개발자 명령 문서에는 아직 없습니다.
• 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일).

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

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

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

• OpenAI 개발자 커뮤니티의 "Codex CLI 0.162.0 fails during TUI bootstrap" 글(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 덮어쓰기로만 시작되는 문제: 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: 9월 29일 pkill -f codex, codex login status, codex 순서가 올라왔고 10월 5일과 6일에 두 명이 효과를 확인했습니다.
• openai/codex 이슈 #17800: 4월에 열린 원래 이슈: 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으로 바꿔 달라는 요청, 9월 25일). 프록시를 바꾼 뒤에도 서버가 옛 프록시로 나가고 있었다면 재시작 없이는 반영되지 않는다는 뜻입니다.

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

• 데스크톱 앱(macOS, 10월 1일, openai/codex 이슈 #49921: HTTP_PROXY를 줘야 라우팅이 되는 macOS 데스크톱): 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 댓글): chatgpt.com은 막혀 있고 *.openai.com은 열려 있어 로그인은 되는데 그 뒤가 전부 실패했습니다. 로그인 성공이 네트워크 정상을 뜻하지 않는 경우입니다.
• 0.163.0(10월 15일)은 accounts/check와 config/bundle 같은 시작 단계 GET 요청이 실패하면 시스템 프록시로 다시 시도하도록 바뀌었습니다(openai/codex PR #52702). 단, 401·403·407·429·503 응답은 재시도 대상이 아닙니다. 회사 TLS 검사 장비가 있다면 OpenAI 인증 문서대로 CODEX_CA_CERTIFICATE에 PEM 묶음을 지정하고, 없으면 SSL_CERT_FILE로 대체됩니다.

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

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초 뒤 실패, 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일 떠 있던 서버의 디스크립터 고갈, 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(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 보고(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로만 시작, 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 인증(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가지와 선택 기준에 있습니다. codex login 단계 자체가 403으로 실패하는 것은 다른 오류이며 Codex 토큰 교환 403 실패: 오류 문구별 로그인 복구 방법에서 다룹니다. TUI가 열린 뒤 모델 요청에서 401 Incorrect API key provided가 나는 것도 별개로, Codex 401 Incorrect API key provided 오류 해결: URL과 키로 원인 가리기를 보면 됩니다.

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

이 문구는 계정의 탐색 결과에 같은 워크스페이스가 둘 들어 있다는 뜻이고, 2026년 10월 17일 기준 사용자 쪽에서 고칠 방법이 보고되지 않았습니다. openai/codex 이슈 #47034: 로그인 성공 뒤 duplicate workspace(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 설정 참조 문서는 이 키를 "ChatGPT 로그인을 특정 워크스페이스 ID로 제한"하는 용도로 설명하고, 자격 증명이 제한과 맞지 않으면 Codex가 로그아웃시키고 종료한다고 적습니다.

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

이 문구만 (code -32600), 즉 invalid request로 끝납니다. 코드상 의미는 ChatGPT 방식의 자격 증명인데 토큰에 plan_type 값이 없다는 것입니다. 이메일은 없어도 되지만 plan type은 필수입니다(Codex model-provider 소스 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 인증 문서대로 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 연결법에 있습니다.

마지막 문구가 없는 옛 줄: 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 메시지 전송 오류 해결: 두 번째 줄 문구로 원인 찾기에서 다룹니다.

데스크톱 앱의 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 데스크톱이 거의 매일 재로그인을 요구, 9월 30일). 증상은 매일 다시 로그인을 요구하는 형태로 나타나기도 합니다(Windows의 openai/codex 이슈 #53236 10월 12일, openai/codex 이슈 #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, 9월 22일)입니다. Windows에서 어떤 Codex 프로세스가 남아 있어도 되는지는 Windows의 Codex 백그라운드 프로세스: 종료해도 되는 상태 판별법에 정리되어 있습니다. VS Code에서 30초 뒤 "could not start"가 뜨는 것은 다른 오류로 Codex could not start VS Code 확장 오류: 원인별 해결, WSL은 1.141.2로를 보면 됩니다.

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

openai/codex의 GitHub 릴리스 노트를 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에서 바로 시작하기에 있습니다.

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

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 구독 차이: 크레딧 환산 비용과 손익분기점에서 확인한 뒤 결정하는 것이 맞습니다. 커스텀 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)도 각각 다른 단계의 오류로 별도 이슈가 있습니다.