Reconnecting은 Codex가 끊어진 연결을 복구하려 한다는 상태 표시입니다. 현재 task가 손상됐는지, client version 문제인지, 인증이 만료됐는지, network route가 불안정한지, 서비스가 잠시 중단됐는지는 이 표시만으로 결정할 수 없습니다.
그러므로 ~/.codex, 모든 session, 로그인 정보를 먼저 삭제하지 마세요. repository의 변경은 disk에 남아 있을 수 있지만 미완료 task에는 마지막 prompt, approval, tool output, 확실히 끝난 단계가 들어 있습니다. 이것이 복구와 버그 보고에 필요한 증거입니다.
Reconnecting 1/5가 5/5까지 진행한 뒤 다음 오류가 보이면, 재전송하기 전에 작업 상태를 기록하세요.
textstream disconnected before completion
마지막 지시, 대상 파일, 마지막으로 완료를 확인한 작업을 짧게 복사합니다. 외부 메시지 전송, 배포, 삭제처럼 되돌리기 어려운 지시는 즉시 반복하지 마세요. 실행은 끝났지만 마지막 UI event만 도착하지 않았을 가능성이 있습니다.
2분 안에 영향 범위를 먼저 확인하기
문제가 난 task는 그대로 두고 다음을 확인합니다.
- 같은 project에서 새 task를 열어 current directory 확인처럼 작은 read-only 요청을 보냅니다.
- integrated terminal에서
pwd또는git status를 실행합니다. - CLI나 IDE extension이 있다면 같은 크기의 read-only 요청을 다른 surface에서 보냅니다.
결과는 바로 다음 선택을 바꿉니다.
| 관찰 | 좁혀진 범위 | 안전한 다음 행동 |
|---|---|---|
| 새 task는 정상이고 기존 task만 재연결 | 저장된 task 또는 해당 response stream | 기존 task를 보존하고 짧은 handoff로 새 task에서 계속 |
| CLI는 정상이고 Desktop만 실패 | Desktop build, host process, 해당 route | version을 비교한 뒤 Desktop을 완전히 종료하고 다시 열기 |
| shell은 정상인데 여러 Codex surface가 실패 | local command가 주된 blocker는 아님 | auth, version, service, network를 하나씩 확인 |
git status도 멈춤 | repository, filesystem, shell, local process 문제 | 먼저 기본 command 경계를 복구 |
| 여러 surface가 두 개의 허용된 network에서 모두 실패 | account, service, 광범위한 client 문제 가능성 | local data 변경을 멈추고 diagnostic 준비 |
OpenAI 공식 Troubleshooting도 stuck state에서 approval 대기 여부, 기본 terminal command, 더 작은 새 chat을 먼저 확인하라고 안내합니다. 기존 task를 파괴하지 않으면서 문제 범위를 나누는 신호입니다.
surface마다 version을 따로 기록하기
CLI에서는 다음을 실행합니다.
bashcodex --version codex --help
Desktop은 About 화면, IDE는 extension detail에서 version을 확인합니다. “최신 버전”이라는 메모만으로는 부족합니다. OpenAI는 Desktop app과 CLI가 서로 다른 Codex version을 포함할 수 있다고 설명합니다.
업데이트를 초기에 확인할 이유도 있습니다. 공식 ChatGPT & Codex changelog는 Codex CLI 0.148.0에서 temporary provider outage 중 turn reconnect가 개선됐다고 기록합니다. 같은 날 client update에는 idle 또는 reconnecting 이후 task를 사용할 수 없게 되는 문제의 수정도 있습니다.
이는 “version을 비교하고 업데이트하라”는 근거이지 “모든 Reconnecting은 오래된 버전 때문이다”라는 근거는 아닙니다. update 후에는 같은 minimal request만 다시 실행하고 다른 설정을 동시에 바꾸지 마세요.
명확한 error는 별도 경로로 분리하기
재연결 횟수보다 전체 오류가 더 구체적인 단서를 줍니다.
access token could not be refreshed라면 Codex token refresh 문제로 이동합니다.- HTTP 429, usage limit, reset time이면 Codex rate limit을 확인합니다.
- command, MCP server, cloud config bundle의 timeout이 명시되면 Codex timeout 경계를 확인합니다.
stream disconnected before completion과 반복 재연결만 있다면 아직 limit 또는 auth라고 단정하지 않습니다.
일반 stream interruption 하나만 보고 logout하지 마세요. logout은 authentication state를 바꾸므로 원래 문제가 network인지 token인지 비교하기 어렵게 만듭니다. 명확한 auth error가 있을 때 원문을 저장한 뒤 문서화된 로그인 흐름을 시도합니다.
실제 Codex host에서 network를 한 조건만 비교하기
브라우저에서 ChatGPT가 열리는 것은 브라우저 route만 정상이라는 뜻입니다. Codex Desktop, terminal, VS Code extension host, WSL, container, Remote SSH는 서로 다른 proxy, DNS, certificate trust, firewall policy를 사용할 수 있습니다.
먼저 Codex process가 실제로 실행되는 host를 확인하세요. account, project, client version, request size를 고정하고 허용된 조건 하나만 바꿉니다.
- managed office network와 승인된 일반 network를 비교합니다.
- 정책이 허용하는 경우 VPN on/off를 한 번 비교합니다.
- local proxy가 필수라면 process가 실제 port에서 listen하는지 확인합니다.
- WSL, container, Remote SSH에서 실패하면 laptop browser가 아니라 그 환경에서 확인합니다.
변경 전후의 시간, 마지막 status, exact error를 기록합니다. 다른 network에서 복구되면 기존 route가 관련 있다는 증거는 강해집니다. 그러나 한 번의 성공으로 DNS, TLS inspection, WebSocket, proxy rule 중 무엇이 원인인지 확정할 수는 없습니다.
Clash나 proxy 설정이 항상 답은 아닌 이유
한국어 자료에서는 Clash, .env, HTTP_PROXY, WebSocket 설정을 하나의 답으로 묶는 경우가 많습니다. 하지만 적어도 두 network plane을 구분해야 합니다.
- Codex client가 model response를 받는 연결
- Codex가 sandbox 안에서 실행하는 command의 outbound network
OpenAI permissions configuration spec의 network proxy는 sandboxed command traffic을 위한 설정입니다. tool에 HTTP(S)와 WebSocket proxy variable을 제공할 수 있지만, curl이나 package manager가 성공했다는 사실이 Desktop App의 model stream route까지 바뀌었다는 증거는 아닙니다.
공식 current config reference에 없는 key를 영구 해결책으로 추가하지 마세요. 비교가 필요하면 before value를 저장하고 한 항목만 변경한 뒤 rollback 경로를 유지합니다. custom model provider를 사용한다면 해당 provider와 설치된 Codex version의 transport 문서를 기준으로 해야 합니다.
증상 범위에 맞는 restart 선택하기
기존 task 하나만 실패하면 삭제하지 말고 새 task로 goal, 완료 단계, file list, 남은 불확실성만 전달합니다. 새 task에는 먼저 git status로 현재 상태를 확인하도록 요청하세요.
client 하나만 실패하면 다른 active tasks가 끝난 뒤 App 또는 IDE host를 완전히 종료하고 다시 엽니다. window를 닫아도 background process가 남을 수 있습니다. 공식 Troubleshooting 역시 active chats가 끝난 뒤 restart하라고 안내합니다.
모든 surface가 실패하면 OpenAI Status를 확인하고 local time을 남긴 뒤 승인된 network 한 조건만 비교합니다. 범위가 넓은 상태에서 재설치와 cache 삭제를 반복하면 변수만 늘어납니다.
reconnect 후에는 git status와 외부 시스템의 실제 상태를 확인합니다. 최종 메시지가 도착하지 않았어도 tool call이나 write가 완료됐을 수 있습니다.
session 정리는 마지막 검증으로 남기기
OpenAI가 안내하는 위치는 다음과 같습니다.
- macOS App log:
~/Library/Logs/com.openai.codex/YYYY/MM/DD - active transcript:
$CODEX_HOME/sessions, 기본~/.codex/sessions - archived transcript:
$CODEX_HOME/archived_sessions
여기에는 prompt, path, repository 이름, tool output이 포함될 수 있습니다. 공유 전 token, cookie, email, private code를 제거하고 전체 data directory를 업로드하지 마세요.
같은 project의 새 task는 안정적으로 동작하고 특정 기존 task만 반복 실패할 때에만 해당 transcript 격리를 검토할 수 있습니다. 먼저 복구 가능한 copy를 만들고 정확한 파일만 active directory 밖으로 이동한 뒤 같은 minimal test를 실행합니다. 날짜만 보고 sessions를 대량 삭제하는 것은 진단이 아닙니다.
문제가 계속되면 /feedback에 surface와 version, OS와 실제 실행 host, 발생 시간과 timezone, Reconnecting sequence, 새 task·다른 surface·기본 command·network 비교 결과, 최소한의 redacted log를 포함합니다.
해결을 확인했다는 뜻은 badge가 한 번 사라졌다는 뜻이 아닙니다. 문제 범위를 “기존 task 하나”, “client 하나”, “network route 하나”, “모든 surface” 중 하나로 설명할 수 있고 같은 작은 테스트로 다시 확인할 수 있어야 합니다.
