Codex Rules 설정 방법: git push는 막고 조회 명령은 승인받는 법

TL;DR

핵심 3줄 요약

이 글에서 다룰 내용

Codex Rules는 무엇이고 언제 쓰면 좋은가

시작 전에 확인할 조건과 기능 경계

공식 문서는 Rules를 experimental로 표시합니다. 문법과 동작이 바뀔 수 있으므로 현재 공식 문서를 확인하고, 기존 규칙 파일은 변경 전 복사본을 남겨야 합니다.

Rules는 sandbox 밖 명령 실행을 통제합니다. sandbox 자체의 읽기·쓰기 범위, Codex의 approval policy, 운영체제 권한을 대신 설정하지 않습니다. 규칙 하나를 추가했다고 파일 접근·네트워크·코드 품질까지 모두 안전해지는 것은 아닙니다.

사용자 레이어 예시는 ~/.codex/rules/default.rules 입니다. Codex는 시작할 때 활성 config layer 옆의 rules/ 폴더를 읽습니다. 프로젝트의 <repo>/.codex/rules/ 는 해당 프로젝트 .codex/ 레이어가 신뢰된 경우에만 불러옵니다. 이 글에서는 프로젝트마다 달라지는 신뢰 설정 대신 사용자 레이어만 사용합니다.

기존 default.rules 가 있다면 덮어쓰지 말고 내용을 먼저 확인합니다. 겹치는 규칙이 있을 수 있으므로 현재 파일과 검증 결과를 기록한 뒤 필요한 두 규칙만 추가합니다.

첫 검증에는 실제 원격 저장소나 민감한 명령을 쓰지 않습니다. execpolicy check 는 전달한 명령을 실행하지 않고 어떤 규칙이 맞는지와 최종 결정을 JSON으로 보여 줍니다.

Rules 파일을 만들고 두 명령을 검증하는 순서

1. 현재 규칙 파일과 승인 경계를 확인합니다

Codex를 종료하기 전에 사용 중인 config layer와 기존 규칙 파일 위치를 확인합니다. 이 글의 대상 파일은 사용자 레이어의 ~/.codex/rules/default.rules 입니다.

파일이 이미 있으면 복사본을 만들고 기존 prefix_rule 의 pattern , decision , justification 을 읽습니다. 특히 git 처럼 넓은 접두사 규칙이 있는지 확인합니다. 기존 규칙의 의미를 모른 채 새 파일로 덮어쓰는 작업은 완료 기준에서 제외합니다.

먼저 정책 목표를 한 줄로 적습니다. 이번 예시는 “Codex가 sandbox 밖에서 git push 를 요청하면 차단하고, git status 는 매번 사람이 승인한다”입니다.

2. 테스트 가능한 prefix_rule 두 개를 작성합니다

~/.codex/rules/default.rules 에 다음처럼 작성합니다. 기존 파일이 있다면 내용을 보존한 채 검토된 위치에 추가합니다.

prefix_rule(
pattern = ["git", "status"],
decision = "prompt",
justification = "저장소 상태 조회도 실행 전에 확인합니다",
match = ["git status", "git status --short"],
not_match = ["git diff"],
)
prefix_rule(
pattern = ["git", "push"],
decision = "forbidden",
justification = "원격 반영은 사람이 직접 수행합니다",
match = ["git push", "git push --force"],
not_match = ["git status"],
)

pattern 은 명령 인자 목록의 정확한 접두사를 뜻합니다. match 와 not_match 는 규칙을 불러올 때 함께 검증하는 인라인 예시입니다. 규칙 의도와 다른 명령이 맞거나 빠지는 실수를 일찍 찾는 데 씁니다.

3. git status 가 prompt 인지 검사합니다

Codex 작업을 시작하기 전에 터미널에서 정책만 검사합니다.

codex execpolicy check --pretty \
--rules ~/.codex/rules/default.rules \
-- git status

출력 JSON에서 decision 이 prompt 인지 확인합니다. matchedRules 에는 git status 접두사와 작성한 justification 이 보여야 합니다. 이 검사는 git status 자체를 실행하지 않습니다.

결정이 없거나 예상과 다르면 파일 경로와 pattern 토큰부터 다시 봅니다. 결과가 맞지 않는데 실제 저장소를 열어 시험하지 않습니다.

4. git push 가 forbidden 인지 검사합니다

이제 같은 규칙 파일로 원격 반영 명령의 판정만 확인합니다.

codex execpolicy check --pretty \
--rules ~/.codex/rules/default.rules \
-- git push --force

출력 JSON의 최종 decision 은 forbidden 이어야 합니다. prompt 가 나오면 승인으로 통과할 수 있으므로 이번 정책 목표를 충족하지 못합니다.

여기서 git push --force 는 정책 검사에 전달하는 문자열일 뿐 실제로 실행되지 않습니다. 운영 저장소와 분리한 비민감 테스트 환경에서 검증하고 검사 명령과 결과 JSON을 변경 기록에 남깁니다.

5. 겹치는 규칙과 대표 변형을 추가로 확인합니다

여러 규칙이 같은 명령에 맞으면 forbidden , prompt , allow 순으로 더 제한적인 결과가 선택됩니다. “더 긴 pattern이 항상 이긴다”고 추정하지 말고 execpolicy check 결과를 기준으로 판단합니다.

git push , git push origin main , git push --tags 처럼 같은 접두사의 대표 변형을 검사합니다. 조회 쪽은 git status 와 git status --short 를 확인합니다. git diff 처럼 이번 규칙에 넣지 않은 명령은 matchedRules 가 비어 있는지도 봅니다.

셸 래퍼와 복합 명령은 따로 봐야 합니다. 공식 문서에 따르면 단순한 명령 체인은 안전하게 나눌 수 있을 때 개별 명령으로 평가합니다. 변수·리디렉션·와일드카드·제어 흐름 같은 고급 셸 기능이 있으면 전체 셸 호출을 하나의 invocation으로 다룹니다. 복잡한 셸 문자열을 허용 규칙으로 넓게 풀지 않습니다.

6. Codex를 재시작하고 실제 승인 흐름을 작은 작업으로 확인합니다

규칙 파일을 추가하거나 바꾼 뒤 Codex를 재시작합니다. 공식 문서는 시작 시 활성 config layer의 rules/ 를 스캔한다고 안내합니다.

비민감 저장소에서 git status 가 필요한 작은 읽기 작업을 요청합니다. sandbox 밖 실행 요청이 발생한다면 승인 화면의 명령, 접두사, justification 을 확인하고 승인 여부를 결정합니다. git push 는 Codex에 실행시키지 않고 앞 단계의 정책 검사 결과만 유지합니다.

검증 기록에는 규칙 파일 경로, 변경자, 검토자, prompt 와 forbidden 결과, rollback 조건을 남깁니다. 예상과 다른 승인 흐름이 보이면 Codex를 종료하고 이전 규칙 파일로 되돌린 뒤 다시 검사합니다.

그대로 복사해 쓸 프롬프트

목표: 내가 제공한 명령 목록을 Codex Rules 초안으로 분류해 sandbox 밖 실행 정책 검토표를 만든다.
허용 입력: 내가 붙여 넣은 명령과 하위 명령, 각 명령의 업무 목적, 영향 범위, 기존 규칙의 pattern·decision·justification.
제외 입력: 실제 저장소 내용, 비밀값, 자격증명, 제공하지 않은 명령, 셸 별칭 추정, 파일 수정, 명령 실행, 원격 전송.
출력 형식: 1) 명령 접두사 2) 제안 decision 3) 근거 4) match 예시 5) not_match 예시 6) 사람 확인 필요 항목 7) rollback 조건 순서의 표와 .rules 텍스트 초안.
완료 기준: 모든 제공 명령이 한 번씩 분류돼 있다. 원격 반영·삭제처럼 되돌리기 어려운 명령은 forbidden 후보로 분리돼 있다. 겹치는 pattern과 검증 명령이 표시돼 있다.
추정 금지: 제공하지 않은 명령, 옵션, 경로, 조직 정책을 만들지 않는다. 위험도를 판단할 정보가 없으면 확인 필요로 표시하고 allow로 두지 않는다.
승인 지점: 먼저 표와 .rules 초안만 보여 준다. 사용자가 pattern·decision·justification을 승인한 뒤에도 파일 저장이나 명령 실행은 하지 않는다. 최종 반영과 execpolicy check 실행은 사람이 한다.

실전 활용 팁

주의할 점

자주 묻는 질문

출처

마무리

Codex Rules를 처음 설정한다면 자동 허용 목록을 크게 만들기보다 서로 다른 두 결정을 검증하는 편이 안전합니다. git status 는 prompt , git push 는 forbidden 으로 나누면 조회와 원격 반영의 승인 경계가 분명해집니다.

작업을 끝내기 전에 codex execpolicy check 결과를 기록하고 Codex를 재시작합니다. Rules가 sandbox와 검수를 대신한다고 가정하지 말고, 원격 반영은 사람이 수행하는 기준을 유지해야 합니다.