Codex Sandbox(Signal(6)) 오류, 새 exec로 범위를 좁힐 수 있나?

Codex 대화 안에서 pwd 같은 간단한 명령도 execution error: Sandbox(Signal(6))로 실패한다면 재설치부터 하지 마세요. 실패한 대화는 그대로 보존하고, 같은 폴더에서 새 codex exec에 같은 명령을 한 번만 시켜 보세요. 새 실행은 성공한다면 저장소나 설치 전체보다 기존 대화의 실행 경로를 먼저 의심할 근거가 생깁니다.

먼저 보존할 것

원래 Codex 대화를 종료하거나 설정을 지우기 전에 다음 네 가지를 메모합니다.

codex --version
pwd
git status --short

여기에 실패 화면의 첫 Sandbox(Signal(6)) 줄을 함께 남깁니다. git status --short조차 Codex 안에서 실패한다면 직접 터미널에서 읽기만 하고, 파일을 초기화하거나 정리하지 않습니다.

같은 폴더에서 새 exec 대조군 만들기

터미널에서 실패한 작업 폴더로 이동한 뒤 아래처럼 실행합니다.

codex exec --json --ephemeral \
  --sandbox workspace-write \
  "Run pwd exactly once using the shell tool. Then stop."

이 명령의 목적은 작업을 대신 끝내는 것이 아니라 같은 폴더의 새 비대화형 실행 경로에서 shell이 작동하는지 보는 것입니다. 프롬프트에는 파일 수정이나 여러 진단 명령을 넣지 않습니다.

현재 macOS arm64의 Codex CLI 0.156.1에서 임시 Git 저장소를 만들어 실행했을 때 pwd는 exit 0이었고 이벤트는 turn.completed로 끝났습니다. 이것은 정상 대조군입니다. 현재 버전에서 Signal(6) 실패 자체를 재현한 결과는 아닙니다.

결과를 이렇게 나눕니다

대조 결과	알 수 있는 범위	다음 행동
원래 대화만 Signal(6), 새 exec의 pwd는 성공	저장소·설치 전체가 아니라 기존 세션 경로 차이 가능성	원래 변경을 보존하고 새 세션에서 최소 작업부터 재개
원래 대화와 새 exec가 모두 같은 오류	세션 전용 문제로 좁힐 수 없음	버전·폴더·sandbox·첫 오류를 고정해 공통 환경 조사
새 exec가 인증·네트워크 오류로 실패	sandbox 대조가 완료되지 않음	Signal(6)와 섞지 말고 인증·연결 오류를 별도 해결
pwd는 성공하지만 실제 작업 명령만 실패	shell 전체 실패가 아님	실패한 단일 명령과 접근 경로를 최소화해 다시 비교

새 exec 성공이 뜻하지 않는 것

새 exec가 성공해도 기존 대화가 자동으로 복구된 것은 아닙니다. 원래 대화가 실행하던 프로세스나 미저장 파일 변경이 있을 수 있습니다. 따라서 기존 세션을 강제 종료하거나 설정 파일을 삭제하기 전에 git status --short와 필요한 작업 파일을 확인합니다.

또한 공개 질문은 Codex CLI 0.130.0의 macOS 사례입니다. 작성자는 대화형 세션의 여러 shell 명령이 Signal(6)로 실패했지만 같은 기기의 새 codex exec --sandbox workspace-write는 성공했다고 대조했습니다. 이 사례와 현재 0.156.1의 정상 exec 대조군만으로 현재 모든 Mac의 원인을 하나로 확정할 수는 없습니다.

OpenAI 공식 문서에서 2026년 9월 24일 이 특정 Sandbox(Signal(6))의 원인이나 복구 절차를 찾지는 못했습니다. 따라서 이 글은 공개 보고자가 제안한 “대화형/session runtime 경로 차이”를 확정 원인으로 쓰지 않고, 같은 폴더의 새 실행이 성공했을 때 조사 범위를 좁히는 방법으로만 사용합니다.

새 exec도 실패할 때

설정 여러 개를 한꺼번에 바꾸지 말고 아래 항목을 고정합니다.

1. codex --version
2. 실패한 폴더의 pwd
3. 사용한 sandbox 값
4. 처음 실패한 한 명령
5. 첫 오류 줄과 종료 여부

그다음 새 임시 Git 저장소에서 같은 pwd 대조를 한 번 실행합니다. 원래 저장소에서만 실패하면 경로·권한·저장소 설정을, 임시 저장소에서도 실패하면 설치·OS·공통 설정을 조사할 근거가 됩니다. 결과가 갈리기 전에는 “저장소 손상”이나 “Codex 전체 고장”으로 단정하지 않습니다.

codex exec --json에 실패한 명령의 lifecycle이 보이지 않는 문제는 별도 질문입니다. 그 경우에는 실패한 명령 이벤트가 없을 때 확인 순서처럼 stdout JSONL·stderr·각 명령 exit·바깥 exec 종료 상태를 분리하세요. Signal(6)의 대화형/새 exec 차이와 JSONL 관측 누락을 같은 원인으로 묶지 않습니다.

환경을 하나씩만 바꿔 비교해야 한다면 AI 코딩 도구의 같은 입력과 검사 명령을 고정하는 방법도 함께 사용합니다.

자주 묻는 질문

새 exec가 성공하면 기존 대화가 고쳐진 건가요?

아닙니다. 같은 폴더의 새 실행 경로가 작동한다는 대조만 확보한 것입니다. 기존 대화의 미저장 변경과 실행 중 작업을 확인하기 전에는 강제 종료하거나 설정을 지우지 않습니다.

새 exec도 Signal(6)로 실패하면 무엇을 보나요?

세션 전용 문제로 좁힐 수 없습니다. 버전·폴더·sandbox 값·첫 실패 명령을 고정한 뒤 비민감 임시 Git 저장소에서 같은 pwd를 한 번 실행해 원래 저장소에만 생기는지 공통 환경에서도 생기는지 나눕니다.

정리

• Sandbox(Signal(6)) 한 줄만으로 저장소나 설치 전체가 망가졌다고 결론 내리지 않습니다.
• 실패한 대화와 같은 폴더의 새 codex exec를 같은 단순 명령으로 비교합니다.
• 새 exec 성공은 실행 경로를 좁히는 대조군이지 기존 세션 복구 증거가 아닙니다.
• 현재 로컬 0.156.1에서는 새 workspace-write exec의 pwd가 성공했지만, 대화형 Signal(6)은 재현하지 못했습니다.

확인 환경: macOS arm64, Codex CLI 0.156.1, 임시 Git 저장소, gpt-5.6-sol low, workspace-write, pwd 1회.

참고: 공개 Sandbox(Signal(6)) 대조 사례

검증 기준

• 마지막 업데이트일: 2026-09-24
• 확인 환경: macOS arm64, Codex CLI 0.156.1, 임시 Git 저장소, gpt-5.6-sol low, workspace-write, pwd 1회
• 검색 관찰: 2026-09-24 Google 정확 오류 질의는 공개 이슈 #23185가 직접 결과였고, Naver 상단은 sandbox 일반 문서 중심이었음
• 기존 담당 URL 대조: WP1072는 JSONL lifecycle 관측 누락, 이 글은 대화형 세션과 새 exec의 실행 경로 차이
• 주요 근거: GitHub openai/codex 공개 이슈 #23185
• 한계: 공개 사례의 대화형 Signal(6)은 현재 환경에서 재현하지 못했고, 공식 문서에서 이 특정 오류의 확정 원인·복구 절을 찾지 못함