codex exec –json에 실패한 명령이 없을 때 확인 순서

메타디스크립션: codex exec –json에서 실패한 명령 이벤트가 빠졌을 때 stdout JSONL, 최종 답, 종료 상태와 성공 대조군으로 실제 실행 여부를 구분한다.

codex exec --json의 command_execution 목록에 실패한 명령이 없는데 최종 답에는 실패가 적혀 있다면, 곧바로 “명령을 실행하지 않았다”거나 “실제로 실패했다”고 단정하지 마세요. 공개 이슈는 초기 sandbox 거부가 최종 답에만 남는 사례를 보고했습니다. 로컬 재확인에서는 실패 lifecycle이 정상 기록됐습니다. 이벤트가 없는 실행은 최종 답의 보고만 있고 원시 lifecycle은 확인되지 않은 상태로 남겨야 합니다.

먼저 구분할 것

명령 실패와 이벤트 누락은 별개입니다. 첫 로컬 실행은 공개 이슈와 같은 요약을 남겼지만 원시 stdout과 바깥 종료 상태를 보존하지 않아 독립 재검증할 수 없습니다. 재확인에서는 같은 종류의 거부가 원시 command_execution completed와 exit 1로 남았습니다.

따라서 세 질문을 나눕니다.

1. 명령 결과를 원시 이벤트로 확인했는가: command_execution completed와 exit code를 확인합니다.
2. 최종 답에만 결과가 적혔는가: 이 경우 실제 실행 여부는 확정하지 않습니다.
3. 바깥 codex exec가 어떻게 끝났는가: 내부 명령의 exit와 별도로 저장합니다.

네 출력을 따로 보관하세요

네 자료를 각각 보관해야 판정할 수 있습니다. 재현이나 자동화에서는 다음을 한 파일로 섞지 말고 분리해 저장합니다.

• stdout JSONL 원본
• stderr 원본
• codex exec 프로세스 종료 상태
• 최종 assistant message 또는 --output-last-message

stderr에는 인증·계정 관련 메타데이터가 섞일 수 있으므로 공개 글이나 이슈에 그대로 붙이지 않습니다. 비민감 marker, 관련 오류 한 줄, 버전과 실행 조건만 골라 공유하세요.

다음처럼 stdout·stderr와 바깥 종료 상태를 분리합니다. <비민감 요청>에는 파일·계정 정보를 넣지 않은 최소 재현을 사용합니다.

codex exec --json --sandbox read-only --ephemeral \
  --skip-git-repo-check '<비민감 요청>' \
  >stdout.jsonl 2>stderr.log
codex_exit=$?
printf '%s\n' "$codex_exit" >codex-exit.txt

최종 답을 별도 파일로 받아야 한다면 같은 실행에 --output-last-message final.txt를 추가합니다. stderr.log는 공개 전에 계정·경로 메타데이터를 제거합니다.

성공 대조군을 한 번 더 실행하세요

파일을 만들지 않는 단순 출력 명령을 대조군으로 실행하세요. 실패 명령 뒤에 다음 명령을 별도로 요청합니다.

printf '%s\n' 'CODEX_JSON_CONTROL'

성공 명령의 started/completed·출력·exit 0은 JSONL에 있고, 실패 명령은 최종 답에 exit 1이 있지만 JSONL에 없다면 로컬 parser가 모든 명령을 버린 상황과 구분할 수 있습니다.

반대로 성공 대조군까지 없다면 먼저 다음을 확인합니다.

• stdout을 JSONL parser 전에 원본 그대로 저장했는가
• stdout과 stderr를 합치지 않았는가
• 중간 필터가 알 수 없는 event type을 삭제하지 않았는가
• 실행한 Codex CLI 버전과 --json 옵션이 기록돼 있는가

MCP 도구가 통째로 보이지 않는 문제라면 JSONL 누락과 섞지 말고 Codex MCP enabled_tools에서 도구가 0개가 될 때의 서버 연결·필터 분기부터 확인하세요.

자동화 판정을 어떻게 바꿀까

세 가지 상태로 나누면 미시도와 관측 누락을 섞지 않습니다. command_execution 개수만으로 “시도하지 않음”을 확정하지 않습니다.

• observed: started/completed와 exit가 JSONL에 있음
• reported_by_final_message_without_lifecycle: 최종 답에는 실패가 적혔지만 대응 원시 lifecycle이 없음
• unknown: 원시 stdout·stderr·최종 답 중 하나가 없어 판정 불가

두 번째 상태를 실패한 실제 실행으로 확정하라는 뜻도 아닙니다. 실행 감사가 불완전하므로 수동 검토 대상으로 두고, 실제 실행·미시도·최종 답의 잘못된 보고 중 하나를 추가 근거 없이 고르지 않습니다.

자동화가 어느 프로젝트 지침을 읽었는지도 함께 흔들린다면 Codex가 어떤 AGENTS.md를 읽었는지 확인하는 순서에서 현재 폴더와 활성 지침을 먼저 고정하세요. 입력 조건이 달라진 실행을 JSONL 이벤트 차이로 비교하면 원인을 잘못 좁힐 수 있습니다.

권한을 풀어 다시 실행해야 하나요?

아니요. 관측 이벤트를 얻기 위해 sandbox 권한부터 넓히지 마세요. 이번 입력은 read-only sandbox가 막아야 하는 heredoc이었습니다. 재확인에서는 실제 원시 이벤트가 exit 1을 기록했습니다. 최소 재현은 비민감 임시 폴더에서 유지하고, 성공 대조군으로 이벤트 경로만 비교하는 편이 안전합니다.

후속 버전에서 같은 입력의 실패 command_execution이 정상적으로 생기는지 확인한 뒤 자동화 예외를 제거합니다. 이번 회차에는 --disable unified_exec나 다른 backend 전환을 해결책으로 검증하지 않았습니다.

직접 확인한 결과

보존된 원시 근거에서는 실패 lifecycle이 정상 기록됐습니다. 2026-09-23 macOS의 Codex CLI 0.155.1에서 gpt-5.6-sol, low reasoning, ephemeral, read-only sandbox로 비민감 marker를 실행했습니다. 앞선 로컬 실행은 공개 이슈와 같은 요약을 남겼지만 원시 자료가 없어 참고 관찰로만 둡니다.

독립 검수 뒤 같은 종류의 입력을 다시 실행하자 실패 heredoc의 started/completed, 원시 오류, exit 1이 모두 나타났습니다. 바깥 codex exec 프로세스는 exit 0이었습니다. 내부 명령 실패와 전체 turn 완료가 같은 종료 상태가 아님도 확인했습니다.

공개 이슈의 0.156.0 관찰은 문제 상황의 근거입니다. 이 글의 독립 확인 범위인 0.155.1에서는 재확인 결과가 달랐습니다. 모든 sandbox 오류, 모든 운영체제, 같은 버전의 모든 실행에서 lifecycle이 빠진다고 일반화하지 않습니다.

정리

1. JSONL 이벤트 부재와 명령 미시도를 같은 뜻으로 보지 않습니다.
2. stdout JSONL·stderr·프로세스 상태·최종 답을 분리해 저장합니다.
3. 단순 성공 대조군으로 parser와 이벤트 경로를 확인합니다.
4. 자동화에는 reported_by_final_message_without_lifecycle 같은 불확실 상태를 둡니다.
5. 관측을 위해 sandbox 권한을 확대하지 말고 후속 버전에서 회귀 여부를 확인합니다.

자주 묻는 질문

command_execution이 없으면 명령을 실행하지 않은 건가요?

항상 그렇지는 않습니다. 최종 답에만 실패가 남고 성공 대조군의 lifecycle은 정상이라면 reported_by_final_message_without_lifecycle로 두고 원시 자료를 수동 검토합니다. 이 상태만으로 실제 실패를 확정하지 않습니다.

codex exec 프로세스가 exit 0이면 내부 명령도 성공한 건가요?

같은 뜻이 아닙니다. 프로세스 종료 상태, 각 command_execution의 exit code, 최종 assistant message를 따로 판정해야 합니다.

JSONL이 빠졌으니 sandbox 권한을 넓혀도 되나요?

관측만을 위해 권한을 넓히지 않습니다. 비민감 최소 재현과 성공 대조군을 유지하고 후속 버전에서 같은 입력의 lifecycle이 복구되는지 확인합니다.

검증 기준

• 마지막 업데이트일: 2026-09-23
• 확인일: 2026-09-23
• 확인 환경: macOS, Codex CLI 0.155.1, read-only sandbox
• 주요 근거: 공개 재현 보고
• 직접 확인: 재확인의 원시 실패 lifecycle·내부 exit 1·바깥 exit 0, 성공 printf 대조군
• 참고 관찰: 첫 로컬 실행 요약은 lifecycle 누락을 기록했지만 원시 stdout·바깥 종료 상태 미보존으로 독립 재검증 불가
• 한계: 0.156.0 설치본, Windows/Linux, 다른 sandbox startup 오류는 독립 재현하지 않았다.