빠른 설정

default_permissions = "project-edit"

[permissions.project-edit.filesystem]
":minimal" = "read"
glob_scan_max_depth = 3

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"
".devcontainer" = "read"
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = true

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"
"*.github.com" = "allow"
"tracking.example.com" = "deny"

권한 구조

permission profile은 파일과 네트워크를 한 운영 모드로 묶는다

기존 sandbox_mode와 sandbox_workspace_write 조합은 빠른 설정에는 충분하지만, 반복 운영에서는 파일 접근과 네트워크 접근을 한 이름으로 묶어 두는 편이 명확합니다. permission profile은 :read-only, :workspace, :danger-full-access 같은 built-in profile 또는 사용자가 정의한 [permissions.<name>]으로 선택합니다. default_permissions가 그중 어떤 profile을 기본으로 쓸지 지정합니다.

권한 설계 순서
1. 읽기 전용인지, workspace 쓰기인지, 전체 권한인지 정한다.
2. 반복되는 작업 모드라면 이름 있는 profile로 만든다.
3. workspace root 안에서 read/write/deny를 나눈다.
4. 네트워크가 필요하면 domain allowlist까지 같이 둔다.

파일 권한은 broad write보다 좁은 deny가 더 중요하다

파일 시스템 권한은 read, write, deny로 나뉩니다. 저장소 전체를 쓸 수 있게 하더라도 .env, credential, 생성되면 안 되는 산출물처럼 읽거나 쓰면 안 되는 영역은 좁은 deny로 잘라내야 합니다. 같은 경로에서 충돌할 때는 deny가 가장 강하고, 더 구체적인 규칙이 넓은 규칙보다 우선합니다.

**/*.env 같은 unbounded glob deny를 쓰면 Linux, WSL, native Windows에서 sandbox 시작 전 스캔 비용이 생길 수 있습니다. 이때는 glob_scan_max_depth를 명시하거나 *.env, */*.env, */*/*.env처럼 깊이를 직접 나눠 적는 방식이 더 예측 가능합니다.

네트워크는 켰는지보다 어디까지 열었는지가 더 중요하다

[permissions.<name>.network] enabled = true는 네트워크가 필요한 profile임을 뜻합니다. 운영 profile에서는 여기에 domain allowlist와 deny 규칙을 함께 둬야 실제 의도가 드러납니다. 예를 들어 OpenAI API와 GitHub는 허용하고, 추적 도메인은 거부하는 식입니다.

로컬 개발 서버에 붙어야 할 때도 주의가 필요합니다. Codex는 DNS rebinding과 실수 방지를 위해 local/private network guard를 적용합니다. localhost나 127.0.0.1에 접근해야 한다면 정확한 host 또는 IP literal을 allowlist에 넣고, allow_local_binding 같은 넓은 예외는 정말 필요한 경우에만 씁니다.

어디까지 열까

주의할 점

실패 예시
- workspace 전체 write profile을 만들고 네트워크도 enabled=true 로 둠
- domain allowlist 없이 외부 호출 가능 범위를 검토하지 않음
- 결과: 작업은 통과했지만 외부 접근 경계가 문서화되지 않음
- 대응: 네트워크가 필요한 profile에는 allow/deny 도메인 정책을 함께 둔다