Codex 샌드박스·승인·네트워크를 따로 설정하는 법

하나의 자동 실행 권한으로 묶지 않습니다

작업 전에 세 질문에 답합니다. 답을 모르면 가장 좁은 경계에서 시작합니다.

샌드박스: 어느 폴더를 읽고 쓸 수 있어야 하는가?
승인: 어떤 행동은 매번 사람이 확인해야 하는가?
네트워크: 어느 호스트에 왜 연결하며 무엇을 보내는가?

첫 실행은 읽기 전용으로 경계를 확인합니다

연습 저장소에서 아래 명령으로 시작하면 파일 쓰기와 네트워크가 막힌 상태에서 지침과 저장소 구조만 조사할 수 있습니다. `--ask-for-approval never`만 쓰면 승인을 묻지 않을 뿐 쓰기를 막지 않으므로 샌드박스 옵션을 함께 지정해야 합니다.

편집이 필요한 다음 단계에서는 `--sandbox workspace-write --ask-for-approval on-request`처럼 작업공간 쓰기와 필요 시 승인을 명시할 수 있습니다. 네트워크는 기본적으로 꺼져 있으므로 필요한 호스트를 확인하기 전에는 별도로 열지 않습니다.

# 1단계: 파일을 바꾸지 않는 조사
codex --sandbox read-only --ask-for-approval never

# 2단계: 계획 승인 뒤 작업공간 안에서만 편집
codex --sandbox workspace-write --ask-for-approval on-request

샌드박스는 명령 이후에도 적용되는 경계입니다

샌드박스는 Codex가 시작한 명령이 파일 시스템과 운영체제 자원에 접근하는 범위를 제한합니다. 프롬프트로 “다른 폴더를 건드리지 마”라고 말하는 것보다 실행 경계가 강한 보호 장치입니다.

다만 샌드박스 모드와 지원 범위는 실행 표면과 운영체제에 따라 달라질 수 있습니다. 현재 유효한 모드와 쓰기 가능한 루트를 설정·승인 화면에서 확인하고, 기억한 기본값으로 단정하지 않습니다.

승인은 샌드박스를 대신하지 않습니다

승인은 Codex가 특정 행동을 하기 전에 사람에게 묻거나 정책에 따라 진행하는 절차입니다. 사용자가 한 명령을 승인해도 그 명령이 안전하다는 보증은 아닙니다. 인자, 작업 디렉터리와 예상 출력을 읽어야 합니다.

반대로 샌드박스 안의 저위험 검사까지 모두 같은 방식으로 묻게 하면 반복 작업이 느려집니다. 복구 가능한 로컬 테스트는 좁은 경계 안에서 허용하고, 외부 상태 변경과 경계 확대는 승인 대상으로 남깁니다.

네트워크에는 목적과 전송 데이터를 붙입니다

패키지 레지스트리 조회, 공식 문서 검색과 운영 API 호출은 모두 인터넷 접속이지만 위험은 다릅니다. 호스트 이름만 허용 목록에 넣지 말고 왜 필요한지와 어떤 데이터가 나가는지 기록합니다.

클라우드 작업에서는 환경의 인터넷 접근 설정을 별도로 확인합니다. 인터넷이 켜져 있어도 저장소의 비밀을 전송할 권한이 생기는 것은 아닙니다. 낯선 업로드 주소나 단축 URL은 목적을 확인하기 전까지 허용하지 않습니다.

무해한 세 번의 실패로 경계를 확인합니다

연습 저장소에서 아래 행동을 실제 실행하기 전 Codex에게 예상 결과와 필요한 승인을 먼저 설명하게 합니다. 그 뒤 개인 정보가 없는 임시 경로와 공개 주소로만 시험합니다.

1. 저장소 안의 README 읽기와 임시 파일 쓰기
2. 저장소 밖의 전용 임시 폴더에 파일 쓰기
3. 공식 문서 호스트에 HEAD 요청

각 단계에서 기록:
- 성공/차단
- 적용된 샌드박스 경계
- 승인 요청 여부
- 사용한 네트워크 호스트

경계 확대보다 환경 수정이 먼저입니다

테스트가 캐시 폴더 하나를 필요로 한다면 홈 전체를 열지 말고 전용 캐시 위치를 지정합니다. 의존성 다운로드가 필요하면 공식 레지스트리만 검토합니다. 반복 가능한 초기화 스크립트로 해결할 수 있다면 일회성 전체 권한보다 낫습니다.

Codex가 예상하지 않은 상위 경로, 자격 증명 저장소, 운영 데이터 또는 외부 업로드 호스트를 요구하면 중단합니다. 로그를 읽고 더 작은 대체 경로가 없는지 확인한 뒤 사람이 경계 변경을 결정합니다.