Codex CLI에서 .env 파일을 읽지 못하게 설정하는 방법: 공식 예시의 "**/*.env"만으로는 .env.local과 깊은 계층의

Codex CLI로
.env
파일을 읽지 못하게 하려면, permission profile(Beta)의 deny를 사용합니다. 아무것도 설정하지 않은 상태나 :workspace만 지정한 상태에서도 .env는 그대로 읽혔습니다 (작성자 환경에서 확인). - 공식 문서 예시
"**/*.env" = "deny"
만으로는, 심지어 .env.local까지 읽혔고, glob_scan_max_depth보다 깊은 계층의 .env도 읽혔습니다 (작성자 환경에서 확인). -
.env를 한 번이라도 커밋했다면, deny 설정을 했더라도 (작성자 환경에서 확인), git show HEAD:.env로 내용이 출력되었습니다. - 설정을 마친 후에는 반드시 codex sandbox -- cat .env가 Permission denied가 되는지 확인해야 합니다.

본 기사는 AI 에이전트와 비밀 정보에 대한 이야기의 연속입니다. AI 에이전트에게 .env를 읽히지 않도록, 파일 이름만으로 점검하는 일본어 CLI를 만들었습니다. 이전에는 Codex에 대해 '읽힐 가능성이 있음'이라고밖에 말할 수 없었지만, 이번에는 실제 기기를 통해 이 부분을 채웠습니다. Claude Code 측의 이야기는 다음과 같습니다: Claude Code에서 .env를 읽지 못하게 하는 설정은 settings.json의 permissions.deny에 작성하면 되고, Claude Code의 대화 기록은 ~/.claude/projects/에 평문으로 30일 동안 보관됩니다.

• codex-cli 0.163.0 (npm의 @openai/codex)
• Debian 13, bubblewrap 0.12.0
• 로그인 없이 사용할 수 있는 codex sandbox -- <명령어>
  (도움말 설명은 "Run commands within a Codex-provided sandbox"입니다.)로 확인했습니다. -
  CODEX_HOME을 일회용 디렉터리로 지정하여 평소의 ~/.codex에는 접근하지 않았습니다. - 배치한 파일들은 모두 더미 데이터였습니다 (예: DUMMY_KEY=dummy-not-a-secret). 검증 후 삭제했습니다.

확인되지 않은 사항

• 로그인된 Codex 본체(에이전트의 세션)가 실행하는 명령어에서의 동작. codex sandbox와 같은 메커니즘이라고 생각하지만, 이는 추측입니다. - macOS (Seatbelt)와 Windows. 공식 문서에 따르면 Linux와 WSL에서는 bubblewrap과 seccomp로 제한을 걸고, macOS에서는 Seatbelt를 사용합니다. 메커니즘이 다르므로 결과가 같다고 할 수는 없습니다.

config.toml이 비어있는 상태에서 시도했습니다.

$ codex sandbox -- cat .env
DUMMY_KEY=dummy-not-a-secret
$ codex sandbox -- cat app/.env
...

default_permissions = ":workspace"만 작성한 경우에도, .env와 app/.env는 읽혔습니다. :workspace는 '워크스페이스 내부에 쓰기가 가능하다'는 설정이며, 읽기를 막는 것이 아닙니다 (공식: :workspace allows writes inside the active workspace roots and system temp directories). .gitignore에 작성되어 있는지 여부도 관계없습니다.

# ~/.codex/config.toml
default_permissions = "no-env"
[permissions.no-env]
...

이 설정으로 시도한 결과입니다.

$ codex sandbox -- cat .env
cat: .env: Permission denied
$ codex sandbox -- cat .env.local
...

워크스페이스 내부의 새로운 파일 쓰기는 가능했습니다. 거부되는 것은 패턴에 맞는 파일뿐입니다.

설정할 때 주의사항입니다.

• extends를 작성해 두는 것이 권장됩니다. 공식 문서에서도 built-in 프로파일을 상속받으면 .git, .agents, .codex, .aws

설명하고 있습니다. 필자의 환경에서는 extends

없음으로 독립적인 프로파일을 만들었더니, 샌드박스 자체가 실행되지 않았습니다. 원인은 Codex가 실행하는 데 필요한 경로를 읽을 권한이 없었기 때문이라고 추측합니다. 공식 예시에서는 ":minimal" = "read"

을 작성하고 있습니다. -
sandbox_mode

이나 [sandbox_workspace_write]

과 함께 쓰면 안 됩니다(공식). sandbox_mode

이 어딘가에 설정 파일로 존재하면, default_permissions

이 아니라 오래된 설정이 사용됩니다. -
"**/.env.*"

은 .env.example에도 적용됩니다. 필자의 환경에서도 Permission denied

가 발생했습니다. 샘플 파일을 AI에게 읽게 하려면, 다른 이름으로 지정하는 등의 노력이 필요합니다. -
glob_scan_max_depth

은 숫자를 크게 할수록 실행 전 스캔이 증가합니다(공식).

5단계 깊이는 a/b/c/d/.env입니다. 공식 예시대로 설정하여 시도한 결과는 다음과 같습니다.

$ codex sandbox -- cat .env
cat: .env: Permission denied
$ codex sandbox -- cat .env.local
...

*.env

은

v0.130.0 버전에서는 deny 패턴이 작동하지 않았다는 Issue가 있습니다 (openai/codex #22179, 2026-10-18 시점 기준 open). 0.163.0에서는 이번에 작동했지만, 어느 버전부터 작동하게 되었는지는 확실치 않습니다. 먼저 codex --version을 확인해 주세요.

codex --version
codex sandbox -- cat .env # Permission denied면 OK
codex sandbox -- cat .env.local # 공식 예시만으로는 여기를 읽음
...

• 설정 없음이나 :workspace만으로는 .env는 읽힙니다 (작성자 환경에서 확인). - 공식 예시인 `