규칙을 사용하면 Codex가 샌드박스 밖에서 어떤 명령어를 실행할 수 있는지 제어할 수 있습니다.
규칙 파일 만들기
Work 클라우드에서 로컬 컴퓨터에 액세스할 때는 에이전트 보안 설정의 rules TOML 필드에서 지원되는 관리형 명령어 규칙을 설정하세요. 이 규칙은 로컬 실행기에 적용됩니다. Work 클라우드 컨테이너에는 기존 Work 클라우드 정책이 적용됩니다.
아래의 로컬 .rules 파일 설정 방법은 Codex에 적용됩니다. Work 클라우드에서 로컬 컴퓨터에 액세스할 때도 로컬 규칙 파일을 읽는다고 가정하지 마세요. 관리형 Work 환경의 요구 사항은 관리형 설정과 설정 레퍼런스를 참고하세요.
-
.rules파일을 활성 설정 레이어와 같은 디렉터리의rules/폴더에 만드세요(예:~/.codex/rules/default.rules). -
규칙을 추가하세요. 다음 예시에서는 샌드박스 밖에서
gh pr view를 실행하기 전에 승인을 요청합니다.# Prompt before running commands with the prefix `gh pr view` outside the sandbox. prefix_rule( # The prefix to match. pattern = ["gh", "pr", "view"], # The action to take when Codex requests to run a matching command. decision = "prompt", # Optional rationale for why this rule exists. justification = "Viewing PRs is allowed with approval", # `match` and `not_match` are optional "inline unit tests" where you can # provide examples of commands that should (or should not) match this rule. match = [ "gh pr view 7888", "gh pr view --repo openai/codex", "gh pr view 7888 --json title,body,comments", ], not_match = [ # Does not match because the `pattern` must be an exact prefix. "gh pr --repo openai/codex view 7888", ], ) -
Codex를 다시 시작하세요.
Codex는 시작할 때 모든 활성 설정 레이어의 rules/ 폴더를 확인합니다. 여기에는 팀 설정 위치와 사용자 레이어의 ~/.codex/rules/가 포함됩니다. <repo>/.codex/rules/에 있는 프로젝트 로컬 규칙은 해당 프로젝트의 .codex/ 레이어가 신뢰 대상으로 설정된 경우에만 로드됩니다.
TUI에서 허용 목록에 명령어를 추가하면 Codex가 해당 규칙을 사용자 레이어의 ~/.codex/rules/default.rules에 저장합니다. 그러면 이후 실행 시 승인 요청을 건너뛸 수 있습니다.
스마트 승인이 활성화되어 있으면(기본값) Codex가 권한 상승을 요청할 때 prefix_rule을 제안할 수 있습니다. 수락하기 전에 제안된 접두사를 주의 깊게 검토하세요.
관리자는 제한을 두는 prefix_rule 항목을 requirements.toml에서 강제 적용할 수도 있습니다.
규칙 필드 이해하기
prefix_rule()은 다음 필드를 지원합니다.
pattern(필수): 일치 여부를 확인할 명령어 접두사를 정의하는 목록입니다. 비워 둘 수 없으며 각 요소는 다음 중 하나입니다.- 문자열 리터럴(예:
"pr"). - 리터럴의 합집합(예:
["view", "list"]). 해당 위치의 인수가 나열된 값 중 하나와 일치하면 됩니다.
- 문자열 리터럴(예:
decision(기본값"allow"): 규칙이 일치할 때 수행할 동작입니다. 여러 규칙이 일치하면 Codex는 가장 엄격한 결정을 적용합니다(forbidden>prompt>allow).allow: 승인을 요청하지 않고 샌드박스 밖에서 명령어를 실행합니다.prompt: 일치하는 명령어를 실행할 때마다 승인을 요청합니다.forbidden: 승인을 요청하지 않고 실행 요청을 차단합니다.
justification(선택 사항): 규칙을 둔 이유를 사람이 이해할 수 있도록 설명하는 문자열입니다. 값을 지정할 때는 빈 문자열을 사용할 수 없습니다. Codex는 승인 요청이나 거부 메시지에 이 설명을 표시할 수 있습니다.forbidden을 사용할 때 적절한 대안이 있다면 설명에 함께 적으세요(예:"Use \rg` instead of `grep`.“`).match와not_match(기본값[]): Codex가 규칙을 로드할 때 검증하는 예시입니다. 규칙이 적용되기 전에 오류를 찾아내는 데 사용하세요.
Codex는 명령어 실행 여부를 판단할 때 명령어의 인수 목록을 pattern과 비교합니다. 내부적으로는 execvp(3)에 전달되는 인수 목록과 같은 형태로 명령어를 처리합니다.
셸 래퍼와 복합 명령어
일부 도구는 다음과 같이 여러 셸 명령어를 하나의 호출로 묶습니다.
["bash", "-lc", "git add . && rm -rf /"]이런 명령어는 문자열 하나에 여러 동작을 숨길 수 있으므로 Codex는 bash -lc, bash -c와 이에 해당하는 zsh 및 sh 호출을 별도로 처리합니다.
Codex가 스크립트를 안전하게 분리할 수 있는 경우
Codex는 셸 스크립트가 다음 두 조건을 모두 충족하는 일련의 명령어로 구성되어 있는지 확인합니다.
- 각 명령어는 단순한 단어로만 구성됩니다(변수 확장이나
VAR=...,$FOO,*등의 구문을 사용하지 않음). - 명령어는 안전한 연산자(
&&,||,;,|)로만 연결됩니다.
이 경우 Codex는 tree-sitter로 스크립트를 파싱하고 개별 명령어로 분리한 뒤 규칙을 적용합니다.
위 스크립트는 다음 두 명령어로 나뉩니다.
["git", "add", "."]["rm", "-rf", "/"]
Codex는 각 명령어에 규칙을 적용하고 그중 가장 엄격한 결과를 따릅니다.
pattern=["git", "add"]를 허용해도 Codex가 git add . && rm -rf /를 자동으로 허용하지는 않습니다. rm -rf /를 별도로 평가하기 때문입니다.
이렇게 하면 안전한 명령어에 위험한 명령어를 끼워 넣어 실행하는 것을 막을 수 있습니다.
Codex가 스크립트를 분리하지 않는 경우
스크립트에서 사용하는 고급 셸 기능의 예는 다음과 같습니다.
- 리디렉션(
>,>>,<) - 치환(
$(...),...) - 환경 변수(
FOO=bar) - 와일드카드 패턴(
*,?) - 제어 흐름(
if,for, 변수 할당과 함께 쓰는&&등)
이런 기능이 있으면 Codex는 스크립트를 해석하거나 분리하려고 하지 않습니다.
이 경우 전체 호출을 다음과 같은 형태로 처리합니다.
["bash", "-lc", "<full script>"]규칙은 이 단일 호출에 적용됩니다.
따라서 안전하게 분리할 수 있는 스크립트는 명령어마다 규칙을 검사하고, 그렇지 않은 스크립트는 전체를 하나로 평가해 보수적으로 처리합니다.
규칙 파일 테스트하기
codex execpolicy check를 사용하면 특정 명령어에 규칙이 어떻게 적용되는지 테스트할 수 있습니다.
codex execpolicy check --pretty \
--rules ~/.codex/rules/default.rules \
-- gh pr view 7888 --json title,body,comments이 명령어는 가장 엄격한 결정과 일치한 모든 규칙을 JSON으로 출력합니다. 일치한 규칙에 justification 값이 있으면 이 값도 포함됩니다. 여러 파일을 함께 검사하려면 --rules 플래그를 여러 번 지정하세요. 출력을 읽기 쉽게 정리하려면 --pretty를 추가하세요.
규칙 언어 이해하기
.rules 파일 형식은 Starlark를 사용합니다(언어 명세 참고). 문법은 Python과 비슷하며 안전하게 실행할 수 있도록 설계되었습니다. 규칙 엔진은 파일 시스템에 접근하는 등의 사이드 이펙트 없이 규칙을 실행할 수 있습니다.