권한

권한 프로필을 사용하면 Codex가 사용자를 대신해 실행하는 로컬 명령어에 필요한 최소 권한만 부여할 수 있습니다. 프로필은 이름이 지정된 정책으로, 명령어가 어디에서 읽거나 쓸 수 있는지 정하는 파일 시스템 규칙과 어떤 대상에 연결할 수 있는지 정하는 네트워크 규칙을 결합합니다.

프로필을 사용하면 컴퓨터나 네트워크에 광범위한 접근 권한을 부여하지 않고도 현재 채팅에 필요한 권한을 Codex에 줄 수 있습니다. 예를 들어 읽기 전용 프로필을 사용하면 Codex가 프로젝트를 수정하지 않고 살펴볼 수 있습니다. 쓰기를 허용하는 프로필에서는 수정 가능한 위치를 특정 워크스페이스 루트로 제한할 수 있습니다.

로컬 권한 프로필은 macOS, Linux, WSL 및 네이티브 Windows에서 지원됩니다. 플랫폼별 세부 사항과 주의 사항은 적용 범위 및 방식을 참조하세요.

현재 Codex Cloud의 네트워크 설정은 서비스에 연결을 참조하세요. Codex Cloud(레거시)의 경우 인터넷 접근을 참조하세요.

프로필 정의 및 선택

Codex에는 세 가지 기본 제공 권한 프로필이 있습니다.

• :read-only는 로컬 명령어의 접근 권한을 읽기 전용으로 제한합니다.
• :workspace는 활성 워크스페이스 루트와 시스템 임시 디렉터리 내에서 쓰기를 허용합니다.
• :danger-full-access는 로컬 샌드박스 제한을 해제합니다. 의도적으로 광범위한 접근을 허용할 때만 사용하세요.

[permissions.<name>] 아래에 이름이 지정된 프로필을 만든 다음, 최상위 default_permissions 키에 해당 프로필 이름이나 위의 기본 제공 프로필 중 하나를 지정하세요. 이 예시에서 project-edit는 기본 제공 값이 아니라 사용자가 정의한 프로필 이름입니다.

엔터프라이즈 관리자는 관리형 requirements.toml에서 프로필을 정의하고 사용자가 선택할 수 있는 프로필을 제한할 수 있습니다. allowed_permission_profiles가 있으면 목록에 없는 프로필은 모두 거부됩니다. 목록에서 빠진 기본 제공 프로필과 향후 Codex 버전에서 추가되는 프로필도 마찬가지입니다. 권장 관리형 설정은 사용 가능한 권한 프로필 제어를 참조하세요.

사용자 지정 프로필에서는 다음 두 설정이 서로 연관됩니다.

• [permissions.<name>.workspace_roots]는 해당 프로필에서 워크스페이스 루트로 취급할 디렉터리를 추가합니다.
• [permissions.<name>.filesystem.":workspace_roots"]는 실제로 적용되는 모든 워크스페이스 루트 내에서 Codex가 사용할 파일 시스템 규칙을 정의합니다. 여기에는 현재 세션의 런타임 워크스페이스 루트와 위에서 프로필에 추가한 루트가 모두 포함됩니다.

프로필에도 일반적인 설정 계층 구조가 적용됩니다. 우선순위가 높은 계층에서는 프로필 전체를 다시 정의하지 않고도 같은 이름의 프로필에 항목을 추가하거나 기존 항목을 교체할 수 있습니다.

예를 들어 조직 수준 설정과 사용자 수준 설정에서 같은 프로필을 각각 확장할 수 있습니다.

# /etc/codex/config.toml
[permissions.server.workspace_roots]
"~/code/server" = true

# ~/.codex/config.toml
[permissions.server.workspace_roots]
"~/code/mobile-app" = true

server가 활성화되면 두 워크스페이스 루트 모두 실제 프로필에 포함됩니다.

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit.workspace_roots]
"~/code/app" = true
"~/code/shared-lib" = true

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

[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"
"objects.githubusercontent.com" = "allow"
"*.github.com" = "allow"
"tracking.example.com" = "deny"

이 프로필은 다음과 같이 동작합니다.

• 일반적인 개발 도구에 필요한 최소한의 런타임 경로에서 읽기를 허용합니다.
• 현재 세션의 루트와 프로필에 정의한 루트에 동일한 워크스페이스 루트 규칙을 적용합니다.
• 각 루트 아래에서 .devcontainer/ 같은 IDE 관련 설정을 읽기 전용으로 유지합니다.
• glob 규칙과 일치하는 환경 파일에 대한 접근을 거부합니다.
• 설정한 도메인 정책에서 허용하는 대상에만 네트워크 접근을 허용합니다.

활성 프로필에서는 상위 경로에서 읽기나 쓰기를 허용해도 더 좁은 범위의 거부 규칙이 계속 적용됩니다. 예를 들어 워크스페이스 루트에서 쓰기를 허용하면서 규칙에 일치하는 .env 경로는 deny로 설정할 수 있습니다.

프로필 확장

프로필이 기본 제공 프로필이나 이름이 지정된 다른 프로필과 거의 같다면 extends를 사용하세요. 기본 보호 규칙을 이어받을 수 있도록 가능하면 처음부터 새로 정의하기보다 기본 제공 프로필을 확장하세요. 예를 들어 :workspace를 확장하면 규칙을 명시적으로 재정의하지 않는 한 워크스페이스 루트의 .git, .agents, .codex, .aws 경로가 읽기 전용으로 유지됩니다. 상위 프로필은 한 번만 지정하고 달라지는 규칙만 추가하거나 재정의하세요.

default_permissions = "project-edit"

[features]
network_proxy = true

[permissions.project-edit]
description = "Project editing with OpenAI API access."
extends = ":workspace"

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

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

[permissions.project-edit.network.domains]
"api.openai.com" = "allow"

이 프로필은 :workspace를 기반으로 하며 패턴에 일치하는 .env 파일에 대한 접근은 계속 거부하고 api.openai.com으로 보내는 요청은 허용합니다. 프로필은 :read-only, :workspace 또는 이름이 지정된 다른 프로필을 확장할 수 있습니다. :danger-full-access는 확장할 수 없습니다. Codex는 알 수 없는 상위 프로필과 순환 상속도 거부합니다.

설정 명세

파일 시스템 권한

파일 시스템 항목에는 read, write 또는 deny를 사용합니다.

범위가 더 구체적인 항목이 더 넓은 범위의 항목보다 우선합니다. 두 항목이 같은 경로를 대상으로 하면 deny가 write보다 우선하고, write가 read보다 우선합니다.

이 우선순위에 따라 프로필에서 먼저 넓은 작업 영역을 지정한 다음, 읽기를 차단할 파일이나 디렉터리를 따로 지정할 수 있습니다.

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

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

이 예시에서는 워크스페이스 루트에 쓸 수 있지만 .devcontainer/는 읽기 전용입니다. 샌드박스에서 실행되는 명령어는 패턴에 일치하는 환경 파일에 접근할 수 없습니다.

넓은 범위에서 접근을 거부한 뒤 더 구체적인 경로를 지정해 일부 하위 트리에 다시 접근을 허용할 수도 있습니다.

[permissions.project-edit.filesystem]
"~/Documents" = "deny"
"~/Documents/codex" = "write"

지원되는 경로 형식은 다음과 같습니다.

네이티브 Windows에서는 홈 디렉터리 기준 상대 경로에 ~\work처럼 백슬래시도 사용할 수 있습니다.

의도적으로 넓은 범위에 읽기 권한을 부여해야 하는 프로필에만 :root를 사용하세요.

[permissions.audit.filesystem]
":root" = "read"

:workspace_roots 아래에 중첩 항목을 정의하면 워크스페이스 루트를 기준으로 각 하위 경로의 접근 권한을 지정할 수 있습니다.

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"          # each workspace root
"docs" = "read"        # each workspace-root docs directory
"generated" = "deny"   # each workspace-root generated directory

중첩된 하위 경로는 해당 워크스페이스 루트 안에 있어야 합니다. ../other-repo처럼 상위 디렉터리로 이동하는 경로는 거부됩니다.

정확한 경로나 glob으로 읽기 차단

상위 경로에 접근을 허용하는 프로필 규칙이 있어도 Codex가 읽어서는 안 되는 파일이나 하위 트리에는 deny를 사용하세요. ~/.ssh처럼 위치가 일정하면 정확한 경로를 지정하는 것이 좋습니다. 레포지토리마다 위치가 다른 민감한 파일을 한꺼번에 지정하려면 glob 패턴이 더 적합합니다.

:workspace_roots 아래에 glob을 지정하면 Codex는 실제로 적용되는 각 워크스페이스 루트를 기준으로 패턴을 해석합니다. 예를 들면 다음과 같습니다.

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

이 규칙은 각 런타임 워크스페이스 루트 또는 프로필에 정의한 워크스페이스 루트 아래에서 패턴에 일치하는 .env 파일의 읽기를 차단합니다. 워크스페이스에서 일반적인 쓰기 작업은 허용하면서 환경 파일, 생성된 시크릿 또는 이와 유사하게 자격 증명이 포함된 파일의 읽기를 차단하려면 이 규칙을 사용하세요.

Linux와 WSL, 그리고 MXC 또는 elevated를 사용하는 네이티브 Windows에서는 각 샌드박스 프로세스가 시작될 때 읽기 거부 glob에 일치하는 파일 목록을 만듭니다. 이후에 생성된 파일은 패턴에 일치해도 해당 프로세스의 거부 목록에 추가되지 않으므로 다른 권한에서 접근을 허용하면 읽을 수 있습니다. 예를 들어 장시간 실행되는 셸, 스크립트, 파일 감시 도구 또는 개발 서버는 시작 후에 생성된 .env 파일을 패턴에 일치하더라도 읽을 수 있습니다.

이 스냅샷은 개별 샌드박스 프로세스가 종료될 때까지만 유효합니다. 같은 Codex 세션에서도 새 샌드박스 프로세스를 시작하면 일치 항목을 다시 찾지만, 이미 실행 중인 프로세스를 계속 사용하면 해당 거부 목록은 갱신되지 않습니다. 실행 중인 프로세스에서 새로 생성된 파일을 차단하려고 glob에 의존하지 마세요. Windows 관련 제한 사항은 Windows MXC 호환성을 참조하세요.

deny glob 패턴은 읽기 거부 규칙으로 지원됩니다. read 또는 write glob은 Linux, WSL 및 네이티브 Windows 샌드박스에서 이식성이 떨어지므로 가능하면 정확한 경로나 "docs/**" = "read" 같은 하위 트리 규칙을 사용하세요.

Linux, WSL 및 네이티브 Windows에서는 깊이 제한이 없는 ** 읽기 거부 패턴을 샌드박스 시작 전에 정해진 깊이까지 확장해야 할 수 있습니다. glob_scan_max_depth로 스캔 깊이를 설정하세요. "**/*.env" = "deny"처럼 깊이 제한이 없는 패턴을 사용할 때 적용하는 설정입니다.

[permissions.project-edit.filesystem]
glob_scan_max_depth = 3

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

glob_scan_max_depth는 1 이상이어야 합니다. 값이 클수록 샌드박스 시작 전에 더 깊은 디렉터리까지 스캔하므로 Linux, WSL 및 네이티브 Windows에서 시작 시 작업량이 늘어날 수 있습니다. 깊이를 제한해 패턴을 확장하는 방식을 사용하지 않으려면 *.env, */*.env, */*/*.env처럼 깊이별 패턴을 명시하세요.

현재 세션 루트 외의 위치에도 같은 규칙을 적용하려면 재사용할 워크스페이스 루트를 프로필에 추가하세요.

[permissions.project-edit.workspace_roots]
"~/code/app" = true
"~/code/shared-lib" = true

이 프로필이 활성화되면 Codex는 :workspace_roots 규칙을 현재 세션의 런타임 워크스페이스 루트와 프로필에서 정의하고 활성화한 각 워크스페이스 루트에 적용합니다.

네이티브 Windows에서는 D:\work처럼 드라이브 문자로 시작하는 경로와 \\server\share 같은 UNC 경로를 절대 경로로 사용할 수 있습니다.

네트워크 권한

네트워크 접근과 네트워크 필터링은 별도로 설정합니다. permissions.<name>.network.enabled = true를 설정해 명령어의 네트워크 접근을 허용하고 features.network_proxy를 활성화해 프로필의 도메인 규칙을 적용하세요.

[features]
network_proxy = true

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

[permissions.project-edit.network.domains]
"example.com" = "allow"      # exact host
"*.example.com" = "allow"    # subdomains only
"**.example.com" = "allow"   # apex and subdomains
"ads.example.com" = "deny"   # deny wins over allow

두 설정의 조합에 따라 동작이 달라집니다.

• 네트워크가 꺼져 있으면 프록시 기능의 활성화 여부와 관계없이 명령어가 네트워크에 접근할 수 없습니다.
• 네트워크가 켜져 있고 프록시가 꺼져 있으면 명령어가 제한 없이 네트워크에 직접 접근합니다. 권한 프로필의 도메인 규칙은 적용되지 않습니다.
• 네트워크와 프록시가 모두 켜져 있으면 명령어는 프록시를 사용하고 프록시는 프로필의 도메인 규칙을 적용합니다. 실행 중인 프록시에 허용된 도메인이 없으면 외부 대상으로의 연결을 차단합니다.

[permissions.<name>.network.domains]를 추가하거나 permissions.<name>.network.enabled = true를 설정해도 features.network_proxy는 활성화되지 않습니다. 관리자는 다른 방법으로 [experimental_network]를 requirements.toml에 설정해 프록시를 활성화할 수 있습니다. 관리형 설정을 참조하세요.

네트워크 샌드박스 프록시가 활성화되면 기본적으로 로컬 주소에서 연결을 수신합니다.

[permissions.project-edit.network]
enabled = true
proxy_url = "http://127.0.0.1:3128"
enable_socks5 = true
socks_url = "http://127.0.0.1:8081"
enable_socks5_udp = true

특정 런타임과 연동하는 경우가 아니면 리스너 설정은 기본값으로 유지하세요. dangerously_* 네트워크 키는 특수한 환경에서 제한을 우회하기 위한 설정이므로 일반적인 로컬 개발에는 사용하지 마세요.

로컬 및 사설 네트워크

네트워크 프록시가 활성화되어 있으면 Codex는 DNS 리바인딩과 의도치 않은 로컬 서비스 접근을 방지하기 위해 기본적으로 로컬 및 사설 네트워크 보호 기능을 적용합니다. 특정 로컬 대상을 의도적으로 허용하려면 정확한 호스트 이름이나 IP 주소 리터럴을 허용 목록에 추가하세요.

[permissions.project-edit.network.domains]
"localhost" = "allow"
"127.0.0.1" = "allow"

allow_local_binding = true는 허용 목록에 등록된 호스트 이름이 로컬 또는 사설 주소로 해석되고 프로필에서 해당 호스트에 연결해야 할 때만 설정하세요.

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

[permissions.project-edit.network.domains]
"localhost" = "allow"

Unix 소켓

Unix 소켓 프록시를 사용하면 Docker 같은 도구를 위해 로컬 접근 제한을 우회할 수 있습니다. 꼭 필요한 경우에만 사용하세요.

[permissions.project-edit.network.unix_sockets]
"/var/run/docker.sock" = "allow"
"/tmp/old.sock" = "deny"

deny로 소켓 경로에 대한 접근을 거부하세요. 상위 프로필에서 허용한 소켓 경로도 거부할 수 있습니다. 거부된 소켓 경로는 실제 허용 목록에서 제외됩니다.

Unix 소켓을 활성화한 경우 프록시 리스너는 루프백 주소에 바인딩된 상태로 유지하세요.

기존 샌드박스 설정에서 마이그레이션

파일 시스템과 네트워크 동작을 재사용 가능한 프로필 하나에 정의하려면 기존 sandbox_mode와 sandbox_workspace_write 조합을 권한 프로필로 대체하세요. 한 세션에서는 두 방식 중 하나만 사용하세요.

다음 기준으로 프로필을 선택하세요.

• 읽기 전용 워크플로우에는 기본 제공 :read-only 프로필을 사용하거나 필요한 위치에서만 읽기를 허용하는 사용자 지정 프로필을 정의하세요.
• 워크스페이스 편집에는 기본 제공 :workspace 프로필을 사용하거나, :workspace_roots를 통해 쓰기를 허용하고 워크플로우에 필요한 임시 경로나 캐시 경로만 추가한 사용자 지정 프로필을 정의하세요.
• 로컬 실행에 제한을 두지 않으려는 경우, 의도적으로 가장 넓은 로컬 접근 권한을 부여할 때만 :danger-full-access를 사용하세요.

프로필은 세션에 적용할 기본 로컬 권한을 정의합니다. 조직에서 관리하는 요구 사항은 여기에 제약을 추가할 수 있으며 사용자 설정으로 그 제약을 완화해서는 안 됩니다. 관리자가 적용하는 파일 시스템 및 네트워크 제약은 관리형 설정을 참조하세요.

적용 범위 및 방식

Work 클라우드의 로컬 컴퓨터 접근과 환경 정책

Work 클라우드에서 로컬 컴퓨터 접근을 사용하는 각 환경의 정책을 확인하세요.

• 엔터프라이즈 요구 사항: 로컬 접근을 사용하는 Work와 dot의 경우, 관리형 정책을 활성화하면 지원되는 전역 정책이 공유 클라우드 오케스트레이터에 적용됩니다. 연결된 컴퓨터에는 해당 로컬 실행 요구 사항이 적용됩니다.
• 클라우드 실행: Work 클라우드 컨테이너는 기존 Work 클라우드 정책을 사용합니다.
• 로컬 정책 적용 순서: MDM과 기존 관리형 기기 요구 사항이 에이전트 보안 정책보다 우선합니다. 기기의 시스템 요구 사항 파일은 에이전트 보안 정책보다 우선순위가 낮습니다.
• 정책 우선순위: 우선순위가 낮은 정책이 더 구체적이더라도 우선순위가 높은 정책을 적용합니다. 같은 정책 내에서는 특정 운영 체제에 대한 환경별 재정의가 모든 운영 체제에 대한 환경별 재정의보다 우선하며, 전역 설정의 우선순위가 가장 낮습니다.

일부 요구 사항에는 필드별 병합 규칙이 있습니다. 지원되는 필드와 런타임 제한 사항은 관리형 설정과 설정 레퍼런스를 참조하세요. Work 클라우드에서 이 문서의 Codex 권한 프로필을 지원한다고 가정하지 마세요.

권한 프로필은 로컬 샌드박스에서 실행되는 명령어의 접근 범위를 정합니다. 승인 정책과 함께 사용하고, 웹 검색, 커넥터, MCP 서버, 내장 브라우저, 컴퓨터 사용 및 Codex Cloud는 각 기능의 별도 설정으로 제어하세요.

프로필로 제어하는 항목

• 로컬 명령어 실행: 권한 프로필은 사용자 컴퓨터의 샌드박스에서 실행되는 명령어에 적용됩니다. 커넥터, MCP 서버, 브라우저 및 컴퓨터 사용 기능, Codex Cloud 환경 설정, 승인된 권한 상승에는 각각 별도의 제어 방식이 적용됩니다.
• 파일 시스템 쓰기: 쓰기를 허용하는 프로필은 실행이 끝난 뒤에도 남는 변경 사항을 만들 수 있습니다. 스크립트, 빌드 단계, 패키지 관리자 훅, 셸 시작 파일, 공유 디렉터리에 쓰기 권한을 부여할 때는 주의하세요. 나중에 다른 도구나 사용자가 원래 샌드박스 밖에서 해당 파일을 실행할 수 있습니다.
• 아웃바운드 대상: 네트워크 도메인 규칙은 네트워크 프록시가 실행 중일 때만 샌드박스 명령어의 트래픽이 도달할 수 있는 대상을 제한합니다. 규칙이 허용한 대상의 신뢰성까지 보장하지는 않으며, 와일드카드 허용 규칙의 적용 범위는 여전히 넓습니다.
• 로컬 서비스: 실행 중인 네트워크 프록시는 기본적으로 로컬 및 사설 네트워크 대상을 차단합니다. localhost, 사설 IP 또는 Unix 소켓을 허용 목록에 추가하거나 allow_local_binding = true를 설정하면 로컬 서비스에 대한 접근을 명시적으로 허용하게 됩니다.

네트워크 프록시로 제어하지 않는 항목

네트워크 프록시는 샌드박스 내에서 실행되는 로컬 명령어의 트래픽만 필터링합니다. 다음 항목에는 프로필의 도메인 허용 목록이 적용되지 않습니다.

• 웹 검색: 호스팅된 검색 도구는 자체 접근 설정을 사용합니다. web_search로 제어하며, 관리형 클라이언트에서는 allowed_web_search_modes도 사용하세요. tools.web_search.allowed_domains는 검색 결과를 필터링하며 명령어의 네트워크 접근에는 영향을 주지 않습니다.
• 앱 및 커넥터: 커넥터 기반 도구는 자체 서비스 측 연결, 워크스페이스 권한, 앱 또는 도구 설정을 사용합니다.
• MCP 서버: 로컬 및 원격 MCP 서버는 자체 프로세스 또는 전송 방식을 사용합니다. mcp_servers 설정과 관리형 서버 허용 목록으로 제어하세요.
• 브라우저 및 컴퓨터 사용: 브라우저 탐색과 컴퓨터 사용 동작에는 자체 기능 설정과 승인 제어가 적용됩니다.
• Codex 서비스 트래픽: 모델, 인증 및 기타 클라이언트 서비스 요청은 클라이언트의 별도 HTTP 및 시스템 프록시 설정을 사용합니다.
• Codex Cloud: 이러한 작업은 해당 환경의 네트워크 설정을 사용합니다. Codex Cloud(레거시)에는 별도의 인터넷 접근 설정이 있습니다.

이러한 기능을 제한하려면 각 기능을 직접 설정하세요. 명령어용 네트워크 허용 목록은 Codex가 수행하는 모든 동작에 적용되는 전역 네트워크 정책이 아닙니다.

플랫폼별 정책 적용 방식

• macOS에서 Codex는 Seatbelt 샌드박스 프로필을 사용합니다. 플랫폼 샌드박스가 선택한 정책을 적용할 수 없으면 Codex는 샌드박스 없이 명령어를 실행하는 대신 실행을 거부합니다.
• Linux와 WSL에서 Codex는 bubblewrap과 seccomp를 사용해 파일 시스템 제한을 적용합니다. 기존 Landlock 옵션은 App Server의 Unix 소켓을 격리할 수 없어 파일 시스템을 제한하는 정책에서는 거부됩니다. 업그레이드할 때 features.use_legacy_landlock을 비활성화하세요. 필요한 bubblewrap 작업을 차단하는 호스트에서는 이러한 정책을 사용할 수 없습니다.
• Windows에서 MXC는 프로세스를 격리해 파일 시스템 및 네트워크 권한을 적용합니다. 활성화하기 전에 MXC 호환성을 확인하세요. 기존 대체 방식인 elevated는 권한이 낮은 샌드박스 전용 사용자, 파일 시스템 권한 제한 및 방화벽 규칙을 사용합니다. unelevated는 네트워크 격리가 더 약한 기존 대체 방식입니다. 경로별로 읽기와 쓰기를 구분하는 예외 규칙을 모두 적용할 수는 없으므로 지원되지 않는 정책은 거부됩니다. Linux 샌드박스 모델이 필요하면 WSL을 사용하세요.

운영 지침

작업을 완료할 수 있는 범위에서 권한이 가장 적은 프로필을 선택하세요. 특히 쓰기나 아웃바운드 네트워크 접근을 허용할 때는 이 원칙을 따르세요. 승인 정책, 시크릿 처리 방식, 허용 규칙도 해당 접근 수준에 맞추세요.

자주 사용하는 프로필

네트워크 허용 목록을 사용하는 읽기 전용 프로필

default_permissions = "readonly-net"

[features]
network_proxy = true

[permissions.readonly-net.filesystem]
":minimal" = "read"

[permissions.readonly-net.filesystem.":workspace_roots"]
"." = "read"

[permissions.readonly-net.network]
enabled = true

[permissions.readonly-net.network.domains]
"api.openai.com" = "allow"

파일 접근을 워크스페이스로 제한

다음 권한 프로필은 Codex가 워크스페이스 폴더에 쓸 수 있도록 허용하고 파일 시스템의 나머지 영역에서는 읽기를 차단합니다. 단, :minimal로 지정되는 일부 경로에서는 읽기를 허용합니다.

default_permissions = "workspace-only"

[permissions.workspace-only]
# By extending the :workspace profile, you get Codex's safeguards to ensure
# paths such as .git/, .agents/, .codex/, and .aws/ within a workspace root
# are read-only while the rest of the folder is writable.
extends = ":workspace"

[permissions.workspace-only.filesystem]
# By default, deny read access to all files on disk.
":root" = "deny"

# Though in practice, a software agent needs to be able to read folders that
# contain common tools, such as `/usr/bin`, to get work done, so grant access
# to a "minimal" set of files and folders, as determined by Codex.
":minimal" = "read"

# By extending the :workspace profile, :tmpdir and :slash_tmp are "write" by
# default, though you can deny access to them altogether, if desired.
":tmpdir" = "deny"
":slash_tmp" = "deny"

네트워크 접근 없이 워크스페이스 쓰기 허용

default_permissions = "project-edit"

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

[permissions.project-edit.filesystem.":workspace_roots"]
"." = "write"

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

공개 웹 접근과 워크스페이스 쓰기 허용

default_permissions = "workspace-net"

[features]
network_proxy = true

[permissions.workspace-net.filesystem]
":minimal" = "read"

[permissions.workspace-net.filesystem.":workspace_roots"]
"." = "write"

[permissions.workspace-net.network]
enabled = true

[permissions.workspace-net.network.domains]
"*" = "allow"

공개 네트워크 접근을 의도적으로 허용할 때만 전역 "*" 허용 규칙을 사용하세요. 거부 규칙을 추가하면 넓게 지정한 허용 목록의 범위를 좁힐 수 있습니다.