Codex bwrap Failed to make / slave 오류, doctor 정상과 왜 따로 봐야 하나?

Ubuntu에서 Codex의 pwd, cat, rg가 모두 bwrap: Failed to make / slave: Permission denied로 즉시 실패한다면 개별 명령이나 저장소부터 고치지 마세요. 같은 작업을 일반 sandbox 경로와 승인된 escalated 경로에서 나눠 보고, 오류가 명령 본체보다 앞선 bubblewrap 준비 단계에서 나는지 먼저 확인해야 합니다.

먼저 네 줄을 보존합니다

일반 터미널에서 다음 정보만 읽어 둡니다.

codex --version
uname -a
pwd
git status --short

Codex 안에서는 파일을 바꾸지 않는 pwd 한 번만 요청합니다. 이때 첫 오류 줄이 아래와 정확히 같은지 기록합니다.

bwrap: Failed to make / slave: Permission denied

pwd도 같은 줄로 멈춘다면 프로젝트 명령의 문법 문제보다 sandbox helper가 명령을 시작하기 전에 실패했을 가능성을 먼저 조사합니다.

doctor 정상과 명령 성공은 같은 검사가 아닙니다

2026년 9월 24일 공개된 Ubuntu 24.04·Codex CLI 0.156.1 사례에서는 일반 sandbox를 거친 pwd, cat, rg가 모두 같은 bwrap 오류로 실패했습니다. 반면 escalated 경로의 codex doctor는 실행됐고 요약에는 failure가 0개였습니다.

이 대조는 doctor가 정상이라고 해서 bubblewrap을 거치는 일반 명령도 성공한다고 결론내릴 수 없다는 뜻입니다. doctor 결과는 설치와 상태 데이터의 검사 범위를 보여 줄 뿐, 실패한 것과 같은 sandbox 실행 경로의 성공 증거로 쓰지 않습니다.

결과를 두 갈래로 나눕니다

결과	좁혀지는 범위	다음 행동
일반 sandbox의 최소 명령만 bwrap 오류, escalated 읽기 명령은 성공	Linux sandbox 준비·mount propagation 경로	OS·CLI 버전과 정확 오류를 묶어 보존하고 sandbox 환경 조사
일반 터미널에서도 같은 명령이 실패	Codex sandbox만의 문제로 좁힐 수 없음	셸·경로·파일 권한을 별도 확인
pwd는 성공하고 특정 명령만 실패	bubblewrap 전체 시작 실패와 다름	그 명령의 경로·권한·인자를 최소화해 대조

승인은 읽기 전용 최소 명령 한 번에만 사용합니다. danger-full-access를 상시 설정하거나 실제 빌드·설치 명령을 넓은 권한으로 다시 돌리는 것은 진단 범위를 넘어섭니다.

먼저 하지 않을 것

• 저장소를 초기화하거나 다시 clone하지 않습니다.
• chmod -R 777로 프로젝트 전체 권한을 넓히지 않습니다.
• doctor의 failure 0만 보고 오류가 사라졌다고 기록하지 않습니다.
• 오래된 다른 Linux 커널 사례의 해결책을 Ubuntu 24.04에 그대로 적용하지 않습니다.

현재 작성 환경은 macOS arm64이고 bwrap이 설치되어 있지 않아 이 Linux 오류를 직접 재현하지 못했습니다. 따라서 원인이나 영구 해결책은 확정하지 않고, 공개 보고에서 실제로 대조된 실패 단계까지만 설명합니다.

과거 Codex CLI 0.116.0과 0.130.0의 컨테이너 사례에서는 같은 최소 명령을 legacy Landlock 경로로 실행해 성공했다는 보고가 있습니다. 하지만 현재 다루는 Ubuntu 24.04·0.156.1 사례는 그 대조를 하지 않았습니다. 버전·컨테이너 여부·실제 재현을 확인하지 않은 채 과거 플래그를 현재 해결책으로 복사하지 마세요.

자동화 로그에서 실패한 명령 자체가 보이지 않는다면 codex exec JSON에 실패한 명령이 없을 때 확인 순서로 event 누락과 실제 실행 실패를 먼저 나눌 수 있습니다. 여러 폴더 접근 범위가 문제라면 Codex -C와 --add-dir 차이를 보세요. 두 글은 bwrap mount 준비 실패의 해결책이 아니라 다음 진단 분기를 구분하는 자료입니다.

정리

• 세 최소 명령이 같은 bwrap 줄로 실패하면 명령별 오류보다 sandbox 준비 단계를 먼저 봅니다.
• doctor 정상과 실제 일반 sandbox 명령 성공은 별도 결과입니다.
• 저장소 수정 전 OS·CLI 버전·첫 오류·일반/escalated 대조를 보존합니다.
• 현재 Mac에서는 Linux bubblewrap 오류를 재현하지 않았습니다.

자주 묻는 질문

doctor가 정상이라면 Codex 설치는 문제없나요?

그렇게 단정할 수 없습니다. 공개 사례에서는 escalated doctor가 failure 0으로 끝났지만 일반 sandbox의 pwd, cat, rg는 모두 같은 bwrap 오류로 멈췄습니다. 실패한 작업과 같은 실행 경로의 최소 명령 결과를 별도로 확인해야 합니다.

바로 danger-full-access로 바꿔도 되나요?

아닙니다. 먼저 읽기 전용 최소 명령 한 번으로 일반 sandbox와 승인된 경로의 차이만 확인합니다. 넓은 권한을 상시 적용하면 진단 범위가 커지고 실제 작업 변경까지 섞일 수 있습니다.

참고: OpenAI Codex 공개 이슈 #47744, 과거 0.130.0 대조 #23468, 과거 0.116.0 대조 #15434

검증 기준

• 마지막 업데이트일: 2026-09-25
• 공개 근거 환경: Ubuntu 24.04 x86_64, Codex CLI 0.156.1
• 현재 대조 환경: macOS arm64, Codex CLI 0.156.1, bwrap 미설치
• 확인 환경: 공개 Ubuntu 24.04 x86_64·Codex CLI 0.156.1 사례와 macOS arm64·CLI 0.156.1의 비재현 대조
• 주요 근거: OpenAI Codex 공개 이슈 #47744
• 직접 확인하지 않음: Linux 제품 오류 재현, 확정 원인, 영구 해결, 후속 버전 수정