빠른 설정

# ~/.codex/rules/default.rules

prefix_rule(
    pattern = ["gh", "pr", "view"],
    decision = "prompt",
    justification = "PR 조회는 승인 후 허용합니다.",
    match = [
        "gh pr view 123",
        "gh pr view 123 --json title,body",
    ],
    not_match = [
        "gh pr --repo owner/repo view 123",
    ],
)

decision 기준
- allow: sandbox 밖 실행을 묻지 않고 허용
- prompt: 실행 전 승인 요청
- forbidden: 승인 요청 없이 차단

검토 순서
1. 명령이 정말 sandbox 밖 권한이 필요한가
2. prefix가 너무 넓지 않은가
3. destructive 명령을 allow로 열지 않았는가
4. match와 not_match로 의도한 범위를 검증했는가

정책 구조

Rules는 승인 피로를 줄이되 권한 경계를 넓히는 파일이다

Rules는 Codex가 sandbox 밖에서 어떤 명령을 실행할 수 있는지 제어하는 설정입니다. 자주 반복되는 안전한 조회 명령은 allow로 줄이고, 위험도는 낮지만 확인이 필요한 명령은 prompt로 두며, 절대 허용하면 안 되는 명령은 forbidden으로 막습니다. 이 기능은 실험적일 수 있으므로 팀 공통 정책으로 쓰기 전에는 작은 prefix부터 검증하는 편이 안전합니다.

기본 위치는 활성 config layer 옆의 rules/ 폴더입니다. 예를 들어 사용자 기본 규칙은 ~/.codex/rules/default.rules에 둘 수 있습니다. 저장소 안의 .codex/rules/는 해당 project .codex/ layer가 trusted 상태일 때만 로드되는 점을 감안해야 합니다.

prefix는 정확히 앞부분부터 맞는다

pattern = ["gh", "pr", "view"]는 gh pr view 123에는 맞지만 gh pr --repo owner/repo view 123에는 맞지 않습니다. prefix는 명령의 앞부분을 그대로 비교하므로, 옵션 위치가 자주 바뀌는 CLI에는 너무 좁게 잡으면 매번 승인이 뜨고, 너무 넓게 잡으면 원하지 않는 하위 명령까지 열릴 수 있습니다.

decision이 여러 규칙에 동시에 걸리면 더 제한적인 결정이 이깁니다. 공식 문서 기준 우선순위는 forbidden이 prompt보다 강하고, prompt가 allow보다 강합니다. 따라서 넓은 allow가 있더라도 더 구체적인 forbidden으로 위험 명령을 막는 구조를 만들 수 있습니다.

검증 기준

Rules 파일은 codex execpolicy check로 실제 명령이 어떻게 판단되는지 확인할 수 있습니다. 새 rule을 추가한 뒤에는 한두 개의 성공 예시만 보지 말고, 옵션 순서가 다른 명령과 차단되어야 하는 명령도 같이 확인해야 합니다.

주의할 점

실패 예시
- pattern = ["git"]을 allow로 두어 push, clean, reset까지 모두 열림
- redirection이나 변수 확장이 들어간 shell script를 단순 prefix처럼 취급함
- prompt가 떠서 귀찮다는 이유로 destructive 명령을 allow에 추가함
- not_match 없이 rule을 추가해 옵션 순서 변형을 놓침