코덱스 GitHub Action 사용법: PR 리뷰를 CI에서 안전하게 자동화하기 | DAKER 커뮤니티

Codex GitHub Action은 GitHub Actions 안에서 Codex CLI와 codex exec를 실행해 PR 리뷰, 릴리스 점검, 반복 품질 검사를 자동화하는 공식 액션이다. 지금 중요한 이유는 openai/codex-action@v1 문서가 권한·샌드박스·트리거 제한까지 함께 다루기 때문이다. 이 글에서는 DAKER의 기존 코덱스 작업 계약, Rules, 권한 프로필 글과 연결해 바로 적용할 수 있는 CI 리뷰 구성을 정리한다.

DAKER 코덱스: Codex GitHub Action이 PR 생성부터 리뷰 코멘트까지 이어지는 흐름

PR 리뷰 자동화에서 가장 먼저 막히는 문제는 무엇인가?

한 줄 요약: Codex를 CI에 넣는 일은 “리뷰 자동화”보다 “권한을 어디까지 열 것인가”가 먼저다.

반복되는 PR 리뷰에는 자동화가 잘 맞는다. 하지만 GitHub Actions runner는 저장소 코드, 워크플로 권한, Secret, PR 본문 같은 민감한 입력을 함께 다룬다. OpenAI 공식 문서도 Codex GitHub Action을 소개하면서 API 키 Secret, checkout, prompt 입력, sandbox, safety strategy를 같은 흐름에서 다룬다.

특히 외부 기여자가 많은 저장소라면 PR 제목·본문·커밋 메시지를 그대로 Codex 프롬프트에 섞는 방식은 피해야 한다. 사람이 읽는 텍스트처럼 보여도, 에이전트에게는 지시문으로 작동할 수 있기 때문이다. 먼저 리뷰 기준을 파일로 고정하고, CI가 읽을 입력을 좁히는 방식이 안전하다.

내부에서 먼저 맞춰야 할 기준은 기존 DAKER 글인 AGENTS.md 작업 계약서, Rules 승인 기준, 권한 프로필과 함께 보면 좋다.

Codex GitHub Action이란 무엇이고 언제 써야 하나?

Codex GitHub Action은 openai/codex-action@v1을 GitHub Actions workflow에 넣어 Codex를 CI/CD job에서 실행하는 방법이다. 공식 문서 기준으로 이 액션은 Codex CLI를 설치하고, API 키가 제공되면 Responses API proxy를 시작한 뒤, 지정한 설정으로 codex exec를 실행한다.

핵심 포인트는 세 가지다.

PR 리뷰, 릴리스 준비, 마이그레이션 점검처럼 반복되는 Codex 작업을 워크플로 파일로 고정할 수 있다.
prompt 또는 prompt-file로 작업 지시를 넘기고, output-file과 final-message로 결과를 후속 job에서 사용할 수 있다.
sandbox, safety-strategy, allow-users, allow-bots로 실행 권한과 트리거 주체를 좁힐 수 있다.

개인 로컬 작업은 Codex CLI나 Codex 앱이 더 단순하다. 반대로 팀 저장소에서 “PR이 열릴 때마다 같은 리뷰 기준을 적용한다”면 GitHub Action이 더 적합하다. 화면 검증까지 필요한 변경은 코덱스 in-app browser 웹 QA 글처럼 브라우저 검증 흐름을 별도로 두는 편이 낫다.

Codex GitHub Action을 PR 리뷰에 어떻게 연결하나?

아래는 처음 적용할 때의 최소 흐름이다.

GitHub repository secret에 OPENAI_API_KEY를 저장한다.
.github/codex/prompts/review.md처럼 리뷰 지시 파일을 저장소에 커밋한다.
workflow에서 actions/checkout으로 PR merge ref 또는 검토할 ref를 checkout한다.
openai/codex-action@v1을 실행하고 prompt-file, openai-api-key, output-file을 지정한다.
후속 job에서 final-message가 비어 있지 않을 때 PR 댓글이나 아티팩트로 결과를 남긴다.

짧은 예시는 다음과 같다.

name: Codex PR review
on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  codex:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v5
      - uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt-file: .github/codex/prompts/review.md
          sandbox: read-only
          output-file: codex-output.md

이 예시는 시작점일 뿐이다. 실제 운영에서는 PR에 코멘트를 쓰는 job, 아티팩트 업로드, 승인된 사용자만 실행하도록 제한하는 조건을 더한다. 공식 예시처럼 final-message를 job output으로 넘겨 후속 단계에서 처리하면, Codex 실행과 GitHub 쓰기 권한을 분리할 수 있다.

DAKER 코덱스: 프롬프트 인젝션, 권한, Secret, prompt-file 중복을 점검하는 Codex Action 체크리스트

안전한 workflow를 만들 때 무엇을 비교해야 하나?

결정 지점	권장 선택	피해야 할 선택
API 키	GitHub Secret의 `OPENAI_API_KEY`	workflow 파일에 직접 입력
프롬프트	저장소에 커밋한 `prompt-file`	PR 본문을 그대로 실행 지시로 사용
권한	`contents: read`부터 시작	처음부터 광범위한 write 권한 부여
샌드박스	작업 목적에 맞는 `read-only` 또는 `workspace-write`	필요 없이 `danger-full-access` 사용
실행 주체	`allow-users`, `allow-bots`로 제한	누구나 비용과 Secret 접근 경로를 유발
결과 처리	`output-file`, `final-message`로 후속 job에서 게시	Codex job에 모든 권한을 몰아주기

공식 문서의 중요한 경고는 read-only만으로 비밀 보호가 끝나지 않는다는 점이다. runner 권한, sudo 제거, Secret 노출 가능성, 후속 step 권한을 함께 봐야 한다. 그래서 처음에는 “읽기 전용 리뷰”로 작게 시작하고, 패치 적용이나 자동 커밋은 별도 승인 흐름 뒤에 붙이는 편이 낫다.

실무자가 바로 적용할 수 있는 체크리스트는?

prompt와 prompt-file을 동시에 쓰지 않는다. 공식 문서의 troubleshooting 항목에서도 중복 입력은 제거해야 한다.
safety-strategy 기본 동작과 runner OS를 확인한다. Windows runner는 별도 설정이 필요할 수 있다.
PR 제목, 본문, 커밋 메시지, 이슈 본문을 Codex 지시문으로 그대로 합치지 않는다.
OPENAI_API_KEY가 로그, output, artifact에 찍히지 않는지 확인한다.
Codex 실행 job과 PR 댓글 게시 job을 분리해 쓰기 권한을 늦게 부여한다.
allow-users와 allow-bots로 실행 가능한 계정을 제한한다.
실패 시 output-file을 artifact로 남겨 사람이 확인할 수 있게 한다.
리뷰 기준은 AGENTS.md와 prompt-file에 나눠 적는다. 저장소 공통 규칙은 AGENTS.md, 이번 CI job의 목적은 prompt-file에 둔다.

자주 묻는 질문

Codex GitHub Action과 Codex GitHub 코드 리뷰 기능은 같은 것인가?

아니다. Codex GitHub Action은 GitHub Actions workflow에서 openai/codex-action@v1을 실행하는 방식이다. Codex 코드 리뷰 기능은 Codex cloud와 GitHub PR 리뷰 설정을 통해 @codex review나 자동 리뷰를 쓰는 흐름이다.

PR 댓글까지 자동으로 달아도 안전한가?

가능하지만 Codex 실행 job과 댓글 게시 job을 분리하는 편이 안전하다. Codex job은 읽기 권한 위주로 두고, 후속 job에서 final-message를 받아 GitHub 쓰기 권한을 쓰면 권한 범위가 더 명확해진다.

`sandbox: read-only`면 Secret 보호가 끝난 것인가?

아니다. 공식 문서는 read-only가 Codex의 파일 변경을 제한하지만, runner 권한과 Secret 보호를 모두 대체하지는 않는다고 설명한다. safety-strategy, 권한 범위, 후속 step, 로그 노출을 함께 점검해야 한다.

어떤 프롬프트를 prompt-file에 넣어야 하나?

“심각한 버그와 회귀 위험만 보고하라”, “스타일 취향은 제외하라”, “근거 파일과 라인을 포함하라”처럼 리뷰 기준을 작고 검증 가능하게 적는 것이 좋다. 저장소 전체 규칙은 AGENTS.md에 두고, CI 리뷰의 목적은 prompt-file에 둔다.

자동 패치까지 맡겨도 되나?

처음부터 자동 패치까지 열기보다 읽기 전용 리뷰로 시작하는 편이 낫다. 팀이 출력 품질과 실패 모드를 확인한 뒤 workspace-write나 별도 브랜치 패치 흐름으로 넓히는 것이 안전하다.

공식 출처

먼저 읽기 전용 PR 리뷰 workflow로 작게 시작하고, 팀의 리뷰 기준이 안정되면 출력 게시와 패치 적용 범위를 단계적으로 넓혀 보자.