Codex에서 timeout이 발생했다고 해서 곧바로 사용량 한도나 OpenAI 장애로 결론 내릴 수는 없습니다. 앱이 연결되기 전, IDE 확장이 초기화되는 동안, MCP 서버가 시작될 때, 도구 하나가 실행되는 동안, 하위 프로세스가 종료되기를 기다릴 때, 또는 긴 turn이 더 이상 진행을 표시하지 않을 때 모두 비슷한 “멈춤”으로 보입니다.
먼저 이미 만들어진 변경을 보호하세요. 같은 작업을 여러 세션에서 동시에 실행하지 말고, 로그아웃·모델 변경·네트워크 전환·MCP 비활성화·설정 삭제를 한꺼번에 하지 마세요. Git 변경과 살아 있는 프로세스를 확인하고 정확한 오류, 시간과 시간대, Codex surface와 version, 마지막으로 끝난 작업, 표시된 request/session ID를 기록합니다. 공유할 때는 token, 이메일, 비공개 prompt, 소스 코드와 전체 프로젝트 식별자를 제거합니다.
가장 중요한 질문은 시간이 끝났을 때 Codex가 무엇을 기다리고 있었는가입니다.
마지막으로 확인된 진행을 기준으로 분류하기
| 마지막 상태 | 먼저 확인할 경계 | 첫 번째 작은 테스트 |
|---|---|---|
| 앱·CLI·확장이 ready가 되지 않음 | client 초기화, 인증, 연결 | 같은 account/project로 한 번만 clean launch |
| Connecting 또는 stream reconnect 반복 | host network, proxy/VPN, remote host, service route | 같은 경로에서 중복 세션 없이 한 번 재현 |
| MCP server startup 실패 | local command, environment, remote URL | codex mcp list 후 해당 server만 점검 |
| 특정 MCP tool만 timeout | tool execution, downstream, 입력 크기 | 동일 tool의 최소 read-only call |
| shell command가 종료되지 않음 | watcher, stdin, child process, cleanup | 같은 directory/environment에서 직접 관찰 |
| turn은 active인데 새 진행이 없음 | model request, tool loop, approval, context, UI | session state와 마지막 action 확인 |
| HTTP 429가 명시됨 | account/project/workspace/provider limit | Codex 429 진단으로 이동 |
브라우저에서 사이트가 열린다는 사실은 sandbox command, IDE extension host, container, WSL, Remote SSH host, MCP process가 같은 주소에 접근할 수 있음을 증명하지 않습니다. OpenAI의 sandbox 문서는 approval 동작과 command가 접근 가능한 file/network resource를 별도 제어로 설명합니다. 승인 창이 나타나지 않았다는 사실만으로 네트워크가 정상이라고 판단할 수 없습니다.
특히 한국어 결과에서는 “시간 초과”가 “사용량 초과”와 쉽게 섞입니다. 오류에 429, credit, reset window가 없다면 우선 timeout stage를 확인하세요. 반대로 명확한 429를 단순 연결 문제로 다루면 같은 요청을 더 많이 만들어 진단을 어렵게 할 수 있습니다.
변경 전에 비교 가능한 상태 남기기
긴 로그 전체보다 다음 항목이 유용합니다.
- desktop app, CLI, IDE, cloud, remote 중 실제 surface;
- client version, OS, local/worktree/container/WSL/remote host;
- ChatGPT sign-in, direct API key, custom provider 중 인증 유형(비밀 값 제외);
- exact error, timestamp, request/session ID;
- 마지막 MCP server, tool, shell command;
- 변경된 파일과 남아 있는 background process;
- 이번 경계와 관련된 config 한 항목.
공식 Developer commands에서 /status는 session configuration과 token/context usage, /debug-config는 실제 config layer와 policy source, codex login status는 active authentication mode를 확인합니다. 이 명령들은 서로 다른 질문에 답하며 MCP endpoint나 network를 자동으로 테스트하지 않습니다. 설치 버전에 명령이 없으면 다른 버전의 예를 강제로 적용하지 말고 codex --help를 확인하세요.
MCP 시작과 도구 실행에는 다른 timeout이 적용됩니다
Codex host의 MCP 설정은 서버 시작과 개별 도구 실행을 분리합니다.
toml[mcp_servers.example] command = "example-mcp" startup_timeout_sec = 20 tool_timeout_sec = 90
OpenAI의 MCP 가이드에 따르면 startup_timeout_sec 기본값은 10초이며 server startup을 기다립니다. tool_timeout_sec 기본값은 60초이며 한 번의 tool run을 기다립니다.
startup에서 실패하면 executable, environment variable, interactive input, remote URL, authentication을 확인하세요. 도구 하나만 느리다면 입력을 줄이고 server log, downstream service, request ID를 봅니다. 같은 작업이 정확하게 끝나지만 현재 경계를 조금 넘는다는 증거가 있을 때만 timeout을 늘리는 것이 진단에 도움이 됩니다. 접속 불가, 인증 실패, crash, deadlock은 긴 대기로 해결되지 않습니다.
local STDIO server와 remote streamable HTTP server는 실패 증거도 다릅니다. 또한 desktop app, CLI, IDE extension은 같은 Codex host의 MCP config를 공유할 수 있지만 process environment나 remote host까지 반드시 같지는 않습니다. server가 실제로 어디에서 실행되는지를 기록하세요.
하위 프로세스가 끝나지 않는 경우
dev server, test watcher, stdin을 기다리는 script는 설계상 종료되지 않을 수 있습니다. 주요 작업이 끝났어도 open handle 또는 cleanup 때문에 process가 남기도 합니다. 이때 Codex connection은 정상일 수 있습니다.
동일한 working directory와 environment에서 command를 직접 실행하고 확인합니다.
- 새 output 또는 listening address가 나오는가?
- 스스로 종료되어야 하는 command인가?
- Codex run이 제공할 수 없는 interactive input을 기다리는가?
long-lived service라면 의도적으로 background process로 관리하고 별도의 readiness check를 사용합니다. 종료되어야 하는 command는 자체 log, process tree, exit behavior를 조사합니다. Codex 전체의 기다림만 늘리면 두 경우의 차이가 사라집니다.
Resume 전에 부분 완료를 확인하기
session이 남아 있다면 blind duplicate보다 resume이 문맥 보존에 유리합니다. 공식 문서는 interactive session용 codex resume과 조건에 맞는 non-interactive run용 codex exec resume을 설명합니다. 하지만 대화가 복구됐다고 해서 중단된 외부 write를 다시 실행해도 안전하다는 뜻은 아닙니다. 먼저 Git, cloud job, remote service에서 부분 완료 여부를 확인하세요.
회복 테스트는 account, route, model, project를 유지하고 증거가 가리키는 조건 하나만 바꿉니다. read-only 또는 쉽게 되돌릴 수 있는 작은 작업을 한 번 실행한 뒤 마지막 진행 지점을 원래 기록과 비교합니다. 성공하면 점진적으로 범위를 키우고, 같은 단계에서 멈추면 그 최소 재현과 request/session/server/process ID를 지원에 전달할 수 있습니다.
결과가 permission, config precedence, command network를 가리키면 Codex sandbox와 config.toml로, 429나 usage window를 가리키면 제한 진단으로 이동하세요. 안전한 해결의 핵심은 더 오래 기다리는 것이 아니라 어떤 대기가 끝났고 누가 그 대기를 소유하는지 확인하는 것입니다.
