Codex CLI가 stream disconnected before completion에서 멈출 때, 재실행 전에 남길 것

Codex CLI가 stream disconnected before completion에서 멈췄다면, 같은 지시를 바로 다시 보내기 전에 오류 문구·시각·버전·작업 상태를 남겨야 합니다. 2026년 7월 24일 KST에 OpenAI 상태 페이지는 오류율 상승을 모니터링 중이라고 표시했습니다. 다만 상태 페이지도 계정·모델·기능별 경험을 보장하지는 않으므로, 상태 메시지 하나만으로 원인을 서버나 내 PC로 단정하면 안 됩니다.

작성·검토: FMNOTE 운영 노트 | 처음 발행: 2026-07-24 | 최종 검토: 2026-07-24
변경: Codex CLI 스트림 중단 오류에서 재실행 전에 남길 기록과 중단 기준을 정리했습니다.

10초 결론: 재실행은 한 번만, 그 전에 네 가지를 남긴다

• 오류 문자열 전체와 발생 시각을 복사한다.
• codex --version 결과와 사용 중인 셸을 적는다.
• 저장하지 않은 파일과 실행 중이던 명령의 상태를 먼저 확인한다.
• 상태 페이지와 새 세션을 각각 한 번만 확인한 뒤, 같은 오류가 반복되면 재시도 대신 증거를 붙여 문제를 분리한다.

이 글은 오류를 고치는 만능 명령이 아닙니다. 원인을 확인하지 않은 상태에서 긴 작업을 다시 돌려 파일 변경이나 비용만 중복되는 일을 줄이기 위한 기록 순서입니다.

왜 프롬프트부터 바꾸면 안 될까

OpenAI Codex 공개 이슈에는 stream disconnected before completion 때문에 세션이 더는 응답하지 않는다는 보고가 반복해서 보입니다. 2026년 7월 24일 검색 시점에 같은 문구를 포함한 공개 이슈 검색 결과는 461건이었습니다. 이 숫자가 장애율이나 모든 사용자의 원인을 뜻하지는 않습니다. 다만 혼자만 겪는 오타로 치부하고 계속 재전송하기보다, 세션·서비스 상태·로컬 실행 환경을 나눠 봐야 할 신호로는 충분합니다.

예를 들어 한 Windows 사용자 보고는 원격 compact 작업 뒤 세션이 멈춘 사례를 설명합니다. 그 글의 운영체제·Codex 버전·모델은 그 작성자의 환경일 뿐, 다른 PC의 원인이나 재현 조건으로 가져오면 안 됩니다.

1. 먼저 작업 상태를 고정한다

코드 수정이나 긴 명령을 맡긴 직후였다면 새 세션을 열기 전에 파일 상태부터 확인합니다. 저장하지 않은 변경, 이미 끝난 명령, 중간에 만들어진 결과물이 섞여 있으면 같은 지시를 다시 넣었을 때 수정이 겹칠 수 있습니다. 오류 화면만 캡처하고 곧바로 재실행하는 습관이 특히 위험한 이유입니다.

• 파일 변경이 남아 있음: diff와 실행 결과를 먼저 읽고, 같은 작업을 다시 맡기지 않습니다.
• 명령이 아직 실행 중: 새 세션을 추가로 열지 말고 종료 여부와 로그를 확인합니다.
• 오류 직후 세션만 멈춤: 오류 문구와 시각을 남긴 뒤 다음 단계로 갑니다.

2. 서비스 상태와 내 환경을 같은 칸에 넣지 않는다

OpenAI 상태 페이지에 진행 중인 오류율 상승이 보이면, 바로 재실행하지 말고 복구 공지를 잠시 지켜보는 편이 낫습니다. 반대로 상태가 정상이어도 로컬 설치·로그인·네트워크·특정 세션 문제는 남을 수 있습니다. 상태 페이지의 가용성 수치는 전체 서비스의 집계이며, 개별 구독·모델·기능 경험과 다를 수 있다고 명시되어 있습니다.

CLI 자체가 시작되지 않거나 codex --version부터 실패한다면, 이 글의 스트림 중단 분기보다 설치·런타임·경로 문제를 먼저 해결해야 합니다. 이번 Windows 10 확인 환경에서도 기존 실행 진입점이 대상 런타임 경로를 찾지 못해 Codex를 시작하지 못했습니다. 이는 stream disconnected before completion 재현이 아니며, 두 오류를 같은 원인으로 묶지 않는 이유입니다.

3. 새 세션 재실행은 한 번만 한다

기록을 남겼고 파일 상태도 안전하다면, 새 세션에서 같은 작업을 한 번만 짧게 재현해 봅니다. 새 세션에서 정상이라면 이전 세션에만 남은 맥락이나 원격 처리 경로와 분리해 볼 단서가 생깁니다. 그렇다고 원인이 확정된 것은 아닙니다. 다시 같은 메시지가 나오면 세 번째·네 번째 재시도보다 오류 문자열, 시각, 버전, 운영체제, 셸, 재현 단계만 정리하는 편이 다음 판단에 도움이 됩니다.

4. 출력 회수 문제와 스트림 중단은 다르다

명령은 끝났는데 화면 출력만 비어 있는 경우와, 원격 응답이 완료 전에 끊긴 경우도 분리해야 합니다. 전자는 응답이 실제로 남았는지 stdout·stderr·기록 파일을 확인할 여지가 있습니다. 후자는 응답이나 변경이 끝났다고 가정하면 안 됩니다. 실행은 끝났고 stdout만 비었을 때의 확인 순서는 Antigravity CLI 출력이 비어 있을 때 transcript 로그로 확인하는 법에서 따로 정리했습니다.

이 순서를 쓰지 말아야 할 때

명확한 로그인·권한·결제·할당량 오류가 표시됐거나, CLI가 시작 전부터 실패한 경우에는 스트림 오류처럼 재시도하지 마세요. 계정 조치나 네트워크 정책 변경은 원래 안내 경로를 따르고, 저장하지 않은 작업이 있다면 복구를 먼저 해야 합니다. 이 글은 인증을 우회하거나 서비스 제한을 피하는 방법을 제공하지 않습니다.

오류가 났을 때 가장 아쉬운 선택은 아무 기록 없이 같은 긴 작업을 반복하는 것입니다. 한 번의 재시도보다, 다음 사람도 읽을 수 있는 오류 문구와 작업 상태를 남기는 쪽이 보통 더 빨리 원인을 가릅니다.