Codex bubblewrap 경고 해결법 | 전체 액세스와 user namespace 설정

Codex를 사용하다 보면 다음과 같은 경고가 뜰 때가 있다.

⚠ Codex's Linux sandbox uses bubblewrap and needs access to create user namespaces.

영어가 길어서 복잡한 오류처럼 보이는데, Linux 샌드박스를 만드는 데 필요한 권한을 확인하라는 뜻이다. 필자의 경우에는 권한을 전체 액세스(Full access)로 바꾸니 이 경고가 뜨지 않았다. 우선 이 방법과 함께, 샌드박스를 유지하면서 해결하는 방법도 정리해보려고 한다.

이 경고는 왜 뜰까?

샌드박스는 Codex가 실행하는 명령의 접근 범위를 제한하는 장치다. 여기서 쓰는 bubblewrap은 Linux의 격리 기능을 이용해 실행 환경을 만들고, 명령어 이름은 bwrap이다. user namespace는 일반 사용자도 격리된 환경 안에서 필요한 기능을 사용할 수 있게 해주는 Linux 기능이다. 이 환경을 만들 수 없으면 샌드박스 준비가 막힐 수 있다. bubblewrap 공식 설명

Codex 소스에는 실제로 위 경고 문구가 들어 있다. 현재 구현은 bwrap으로 사용자·네트워크 namespace를 만드는 시험 명령을 실행하고, 권한 관련 실패를 감지하면 경고를 표시한다. 따라서 문구만으로 원인을 하나로 확정하기는 어렵다. Codex 경고 검사 코드

특히 Ubuntu에서는 AppArmor 보안 정책이 일반 프로그램의 user namespace 사용을 제한할 수 있다. bubblewrap이 설치되어 있어도 정책에 막히면 비슷한 문제가 생기는 이유다. AppArmor는 프로그램별 규칙을 적용하므로, 패키지 설치 여부와 사용 권한을 각각 확인해야 한다. Ubuntu의 AppArmor 설명

필자가 사용한 방법: 전체 액세스로 변경

필자는 우선 전체 액세스로 바꿔서 사용했고, 그 상태에서는 경고가 나오지 않았다. 빠르게 작업을 이어가야 할 때는 이 방법이 가장 간단하게 느껴졌다.

앱이나 IDE 확장에서는 입력창 아래 권한 메뉴에서 전체 액세스 / Full access를 선택한다. CLI는 /permissions로 권한 메뉴를 열 수 있다. 메뉴 이름은 버전에 따라 다를 수 있다. 공식 권한 설정 안내

전체 액세스에서는 일반적인 로컬 샌드박스 제한이 해제되므로, 샌드박스를 요구하는 경로에서 벗어나 경고가 사라질 수 있다. Codex의 경고 검사도 플랫폼 샌드박스가 필요한 권한 설정인지 먼저 확인한다. 경고가 사라졌다고 Linux의 namespace 설정까지 수정된 것은 아니다. 관련 검사 코드

작업 범위 밖의 파일과 네트워크에도 접근할 수 있으므로, 중요한 파일이 있는 컴퓨터에서는 아래 방법으로 샌드박스가 정상 작동하도록 맞추는 편이 좋다. 전체 액세스도 현재 로그인한 OS 사용자의 권한을 넘어서 자동으로 root 권한을 주는 기능은 아니다. 권한 범위와 OS 제한

다른 해결법 1: bubblewrap 설치 후 확인

Linux 또는 WSL2 안에서 사용하는 경우, 해당 환경의 터미널에서 설치한다. Ubuntu·Debian 계열은 다음 명령을 사용한다.

sudo apt update
sudo apt install bubblewrap

Fedora 계열은 다음과 같다.

sudo dnf install bubblewrap

설치한 뒤 Codex를 다시 실행한다. 공식 문서는 PATH에 있는 bwrap을 사용한다고 안내한다. 공식 설치 안내

아래 확인 명령은 Codex가 명령을 실행하는 내부 터미널이 아닌, 직접 연 일반 Linux 터미널에서 실행한다.

command -v bwrap
bwrap --version
bwrap --unshare-user --unshare-net --ro-bind / / /bin/true
echo $?

마지막 숫자가 0이면 이 시험 명령은 성공한 것이다. 다른 숫자라면 바로 앞의 오류 메시지를 확인한다. 이 명령은 Codex 소스의 사전 검사와 같은 옵션을 사용하지만, 성공했다고 모든 Codex 작업까지 보장하는 것은 아니다. 시험 명령의 근거

--unshare-user와 --unshare-net은 각각 격리된 사용자·네트워크 환경을 만들고, --ro-bind / /는 루트 파일시스템을 읽기 전용으로 연결한다. /bin/true는 별도 작업 없이 성공으로 종료하는 명령이다. 진단 명령에 sudo를 붙이면 Codex가 일반 사용자로 실행되는 상황과 달라진다. bwrap 명령 설명

다른 해결법 2: Ubuntu의 AppArmor 설정 확인

Ubuntu에서 설치 후에도 실패하면 AppArmor를 확인한다. 먼저 다음으로 상태와 이미 적용된 프로필을 살펴본다.

sysctl kernel.apparmor_restrict_unprivileged_userns
sudo aa-status

sysctl 값이 1이면 관련 제한이 켜져 있다는 뜻이다. 다만 이것만으로 오류 원인이 확정되지는 않는다. aa-status를 사용할 수 없다면 아래의 apparmor-utils 패키지 설치 후 다시 확인할 수 있다. AppArmor의 user namespace 제한 설명

앞의 bwrap 시험 명령이 이미 성공했다면 프로필을 추가하지 말고 다음 절로 넘어간다. 다른 프로그램이 설치한 bwrap 프로필과 새 프로필이 충돌한 사례도 보고되어 있다. 기존 프로필이 있다면 중복 여부부터 확인해야 한다. 이는 사용자 사례 보고이며 모든 Ubuntu 환경에서 발생하는 현상은 아니다. 프로필 충돌 보고

Ubuntu 24.04에서 시험 명령이 실패하고 필요한 프로필이 없다면, 공식 문서의 절차는 다음과 같다.

sudo apt update
sudo apt install apparmor-profiles apparmor-utils
sudo install -m 0644 \
  /usr/share/apparmor/extra-profiles/bwrap-userns-restrict \
  /etc/apparmor.d/bwrap-userns-restrict
sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict

기존에 같은 경로의 파일이 있으면 덮어쓰기 전에 내용과 출처를 확인한다. 원본 프로필 파일이 없거나 명령이 실패하면 다음 단계로 밀어붙이지 말고 패키지·배포판 구성을 확인한다. 적용 후 bwrap 시험 명령과 Codex를 다시 실행한다. Ubuntu 설정 안내

AppArmor는 프로그램별 프로필을 커널에 적용한다. apparmor_parser -r은 지정한 프로필을 다시 로드하는 명령이다. 시스템 전체의 제한을 끄기 전에 필요한 프로그램에 맞는 정책을 확인하는 접근이다. Ubuntu의 프로필 관리 설명

그래도 안 된다면? 제한을 잠시 해제해 진단

AppArmor 문서는 아래 설정으로 관련 제한을 켜고 끌 수 있다고 설명한다. 다만 Codex에만 적용되는 설정이 아니라 시스템 전체의 AppArmor user namespace 제한을 완화한다. 공유 서버나 관리되는 PC라면 관리자와 정책을 확인해야 한다.

# 먼저 기존 값을 기록한다
sysctl kernel.apparmor_restrict_unprivileged_userns

# 일시적으로 제한을 해제한다
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

이 상태에서 bwrap 시험 명령과 Codex를 다시 확인한다. 이 키가 존재하는 환경에만 해당한다. 여기서는 영구 설정 파일을 만들지 않으며, 재부팅하면 부팅 시 설정이 다시 적용된다. 진단 후에는 기록한 기존 값으로 되돌린다. 기존 값이 1이었던 경우의 복원 명령은 다음과 같다.

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=1

제한을 끄고 정상 작동했다면 해당 정책과의 관련성을 의심할 수 있다. 그대로 영구 적용하기보다는 bwrap 프로필을 정리하는 방법을 먼저 검토한다. AppArmor의 설정·복원 안내, sysctl 명령 설명

Windows의 WSL이나 컨테이너에서 뜬다면?

Codex 소스는 필요한 namespace를 만들 수 없는 WSL1을 별도로 안내하며, 샌드박스 명령에는 WSL2를 사용하도록 명시한다. WSL1 관련 코드

Windows PowerShell에서 다음 명령으로 버전을 확인한다.

wsl -l -v

사용 중인 배포판의 VERSION이 1이면 WSL2 전환을 검토한다. 중요한 데이터는 먼저 백업한다. 실제 배포판 이름이 Ubuntu인 경우의 예시는 다음과 같다.

wsl --set-version Ubuntu 2

다른 이름으로 설치했다면 목록에 표시된 이름으로 바꿔 실행한다. WSL2에서도 Linux 배포판의 bubblewrap과 보안 정책은 확인해야 한다. Microsoft의 WSL 명령 안내

Docker·개발 컨테이너 등 이미 격리된 환경에서는 바깥 환경의 정책도 영향을 줄 수 있다. bubblewrap은 namespace 생성 같은 핵심 단계에 실패하면 종료하므로, 내부 패키지만 설치해도 해결되지 않을 수 있다. 이 경우 실행 환경 담당자에게 오류 메시지와 필요한 namespace 지원을 확인하는 편이 좋다. bwrap의 실패 조건

시험 명령은 성공하는데 경고만 계속 뜨는 경우

일반 터미널의 bwrap은 정상 작동하지만, 이미 만들어진 샌드박스 안에서 다시 bwrap을 실행할 때 막혀 같은 경고를 본 사례도 있다. 따라서 경고를 없애려고 보안 설정부터 계속 풀 필요는 없다. 일반 터미널과 Codex 내부의 실행 결과를 구분해 확인한다. 중첩 샌드박스 관련 사용자 보고

앱 또는 CLI를 최신 버전으로 업데이트하고 재시작한 뒤에도 계속되면, Codex 버전·Linux 배포판·일반 터미널의 시험 결과·정확한 오류를 함께 기록해 문제를 문의할 수 있다. 위 사례는 특정 환경의 보고이므로 자신의 경고도 같은 원인이라고 단정하지는 않는다.

필자는 전체 액세스로 바꾸니 경고가 사라져 작업을 이어갈 수 있었다. 같은 상황이라면 이 경험을 참고하되, 샌드박스를 계속 사용하고 싶다면 bubblewrap 설치 → 일반 터미널에서 시험 → 배포판 보안 정책 확인 순서로 점검해보면 된다.

자료 확인: 2026년 10월 11일. 전체 액세스에서 경고가 사라진 부분은 필자의 경험이며, 추가 해결법은 공식 문서와 링크한 사례를 바탕으로 정리했다. 명령은 해당 문제가 발생한 Linux·WSL 환경에서 실행한다.

Codex·GPT 사용 가이드 더 보기

다른 사용법과 오류 해결 방법은 Codex·ChatGPT 사용 가이드 글 목록에서 확인할 수 있다.