AIFreeAPI Logo

Codex cloud config bundle이 15초 후 시간 초과될 때 진단 순서

A
4 min readOpenAI Codex

이 15초 오류는 모델 응답보다 앞선 시작 단계에서 발생합니다. 현재 identity와 일치하는 유효 cache와 증거를 보존하고, 조건 하나만 바꾼 비교로 다음 담당 영역을 찾으세요.

Codex 15초 오류에서 시작 경계 확인, 증거와 유효 cache 보존, 한 조건 변경, 결과 비교, 담당 영역 전달로 이어지는 안전한 순서

error loading configuration: timed out waiting for cloud config bundle after 15s는 Codex가 정상 세션을 준비하기 전에 workspace의 관리 요구 사항을 적용하지 못했다는 뜻입니다. 모델 응답이 느린 상황이나 MCP 도구가 오래 실행되는 상황과는 단계가 다릅니다.

하지만 이 문구만으로 근본 원인은 알 수 없습니다. OpenAI 서비스 장애, proxy·VPN·firewall, 인증 상태, 선택한 workspace, cache, client version 가운데 어느 것도 이 오류 한 줄로 확정되지 않습니다. 그러므로 첫 조치는 전체 상태 삭제나 재설치가 아니라 현재 상태 보존과 비교 가능한 한 번의 재시도여야 합니다.

15초 동안 Codex가 확인하는 경계

OpenAI의 Managed configuration 문서는 지원되는 ChatGPT desktop app, Codex CLI, IDE extension이 조직의 요구 사항을 cloud config bundle로 받는 방식을 설명합니다. 실제 지원 범위는 client와 version에 따라 다를 수 있습니다.

시작할 때 client는 먼저 현재 identity와 일치하는 유효한 서명 cache를 확인합니다. 사용할 cache가 없으면 bundle을 재시도와 함께 가져오고, 검증에 성공한 내용을 저장합니다. 요청이 실패하거나 timeout이 발생했고 유효 cache도 없으면, 조직 정책을 조용히 건너뛰지 않고 시작 오류를 반환합니다.

따라서 이 메시지로 확정할 수 있는 범위는 세 가지입니다.

  • 정상 model turn 전의 관리형 구성 로딩에서 멈췄다.
  • 현재 identity에 사용할 수 있는 유효 cache만으로 시작을 이어 갈 수 없었다.
  • 15초는 관찰된 경계일 뿐 service, network, auth, workspace, client 중 원인을 지정하지 않는다.

로컬 config.toml은 별도 계층입니다. Config precedence는 CLI override, trusted project, profile, user, system 등 로컬 값의 우선순위를 다룹니다. managed requirements는 workspace가 허용하는 범위를 강제하므로, TOML을 편집해도 cloud bundle 경로가 정상인지 증명할 수 없습니다.

Codex 시작 시 현재 identity와 일치하는 유효 cache를 먼저 확인하고, 없으면 cloud config bundle을 가져오는 분기 흐름
Codex 시작 시 현재 identity와 일치하는 유효 cache를 먼저 확인하고, 없으면 cloud config bundle을 가져오는 분기 흐름

삭제나 재로그인 전에 기록할 것

다음 항목을 남기면 재시도 결과를 비교할 수 있습니다.

  • 정확한 오류와 timezone을 포함한 발생 시각
  • desktop app, CLI, IDE extension 중 오류가 나온 surface
  • Codex version, OS, process가 실제 실행되는 host
  • 인증 방식과 선택된 account/workspace(토큰과 이메일 제외)
  • office/home network, VPN, proxy, WSL, container, Remote SSH 등의 route
  • 첫 실행, update 직후, workspace 전환 직후, 재로그인 직후인지 여부

설치된 CLI가 지원한다면 삭제를 수반하지 않는 명령부터 확인합니다.

bash
codex --version codex --help codex doctor --summary codex login status

공식 Developer commands에 따르면 codex doctor는 설치, 구성, 인증, runtime 등의 상태를 정리합니다. --json 출력은 redacted 형태로 설명되어 있습니다. 그래도 doctor 통과가 remote bundle 도달성을 독립적으로 증명하지는 않습니다.

codex login status 역시 활성 인증 방식을 보여 줄 뿐 network test가 아닙니다. 설치 버전에 없는 명령은 다른 문서 예제를 억지로 적용하지 말고 codex --help를 기준으로 삼으세요. codex logout은 저장된 credentials를 제거하므로, 일반 timeout 하나만 보고 실행해서는 안 됩니다.

공유할 log에서는 token, cookie, 이메일 주소, private path, repository 이름, prompt 본문을 제거합니다. home directory나 Codex data 전체를 그대로 전달할 필요는 없습니다.

조건 하나만 바꾸는 비교 테스트

account, workspace, project, client version은 유지하고 허용된 조건 하나만 변경합니다. 재시도 시각, 걸린 시간, 같은 오류인지, 더 뒤 단계까지 진행했는지를 함께 기록하세요.

관찰한 번의 비교다음 확인 영역
OpenAI Status에 관련 active incident가 있음로컬 데이터를 바꾸지 않고 복구 후 동일 조건 재시도service. 단, status는 집계 정보
office network 또는 VPN에서만 실패정책상 허용된 다른 route에서 같은 host로 한 번 시도proxy, firewall, TLS inspection, DNS, egress
update 직후부터 발생변경 전후 version을 기록하고 지원되는 update 확인client version 또는 package
account/workspace 전환과 함께 시작현재 identity를 확인하고 cache는 유지한 채 재현authentication, workspace assignment, policy
같은 workspace의 여러 사용자에게 동시에 발생version, 지역, 시각을 secret 없이 비교workspace 관리자 또는 OpenAI support
한 사용자만 여러 허용 route에서 반복doctor 결과와 timestamp를 함께 전달account, workspace, client, 개별 route

브라우저에서 웹사이트가 열린다는 사실은 Codex process 경로가 정상임을 증명하지 않습니다. IDE extension host, container, WSL, Remote SSH, corporate VM은 브라우저와 다른 proxy, DNS, CA, egress rule을 사용할 수 있습니다. 오류를 실제로 낸 host의 route를 비교해야 합니다.

조직의 보안 제어를 끄거나 금지된 네트워크로 우회하지 마세요. 다른 route가 허용되지 않으면 시간, host, client, version, route 종류를 network 관리자에게 전달합니다.

허용된 비교 결과를 바탕으로 서비스, 네트워크, 클라이언트 버전, 인증과 workspace, 관리자와 지원 중 다음 확인 영역을 고르는 지도
허용된 비교 결과를 바탕으로 서비스, 네트워크, 클라이언트 버전, 인증과 workspace, 관리자와 지원 중 다음 확인 영역을 고르는 지도

처음부터 하면 안 되는 조치

.codex, 알 수 없는 cache directory, app data 전체를 먼저 삭제하지 마세요. 공식 동작에서 identity와 일치하는 유효 cache는 remote fetch 실패 시에도 시작을 가능하게 할 수 있습니다. 삭제하면 그 상태와 진단 증거를 함께 잃습니다. 공개 문서는 수동 cache 삭제를 일반 복구 절차로 안내하지 않습니다.

MCP의 startup_timeout_sec 또는 tool_timeout_sec도 이 오류의 첫 수정 지점이 아닙니다. cloud config bundle은 정상 세션보다 먼저 처리됩니다. bundle 단계를 통과한 뒤 MCP에서 멈춘다면 그때는 새 stage를 별도로 진단합니다.

여러 config.toml 값을 한꺼번에 바꾸지 마세요. 증거가 local precedence나 sandbox를 가리키면 Codex config.toml 안내, refresh token 문구가 명시되면 인증 갱신 오류 안내, HTTP 429라면 Codex rate limit 진단으로 이동합니다.

재로그인이 필요한 경우

재로그인은 별도의 인증 증거가 있을 때만 선택합니다. 예를 들어 login status가 예상과 다르거나, workspace가 잘못 선택됐거나, refresh token 오류가 명시되거나, 관리자가 assignment 변경을 확인한 경우입니다. 먼저 status와 doctor 결과를 저장하고 로그인 수단을 준비하세요.

증상이 15초 bundle timeout뿐이라면 logout은 진단 결과가 아니라 추측입니다. 저장된 credentials를 없애면 network 또는 workspace 문제 위에 새로운 인증 문제를 만들 수 있습니다.

관리자나 support에 전달할 자료

정확한 오류, timezone을 포함한 2~3회 timestamp, surface, version, OS, 실행 host, 인증 방식, 안전하게 식별한 account/workspace, status 결과, 허용된 network 비교, codex doctor --summary 또는 redacted JSON을 준비합니다. 첫 발생 직전에 바뀐 내용과 이미 수행한 조치도 짧게 적습니다.

“같은 version과 workspace에서 home route는 통과하고 office route는 실패한다”는 비교가 “여러 번 재설치했다”보다 유용합니다. 다음 실행에서 bundle을 통과한 뒤 다른 곳에서 멈춘다면, 15초 오류의 추정을 새 단계에 적용하지 말고 그 stage를 새로 기록하세요.

핵심은 더 오래 기다리거나 cache를 지우는 것이 아닙니다. 시작 단계의 managed configuration 경계를 보존하고, 증거를 남기고, 비교 가능한 한 번의 test로 service·network·version·authentication·workspace policy 중 다음 담당 영역을 정하는 것입니다.