Codex untrusted 승인 정책 폐지: 무엇을 바꿔야 하나

Codex CLI v0.149.0(2026년 8월 20일 stable)은 PR #39630 “Retire the untrusted approval policy”(untrusted 승인 정책 폐지)에서 untrusted 승인 정책을 폐지했습니다.¹ 이 PR은 untrusted를 CLI, 설정 스키마, MCP 도구 인터페이스에서(“from the CLI, configuration schema, and MCP tool interface”) 제거하며, 명시적인 approval_policy = "untrusted" 설정은 이제 “with an actionable error”(조치 가능한 오류와 함께) 실패합니다.⁴ 2026년 8월 25일 0.149.1에서 재현한 결과, 값이 config.toml에 있든 프로필 파일에 있든 -c 오버라이드에 있든 세션 시작은 Error: approval_policy = "untrusted" is no longer supported; remove this setting으로 멈추고, codex 바이너리는 인수 파싱 단계에서 -a untrusted를 거부합니다.⁵ 값을 on-request로 바꾸고 샌드박스 모드는 그대로 두세요. 가장 신중한 구성을 원한다면 --sandbox read-only와 on-request를 짝지으세요.³ 현재 정책 집합은 on-request, never, 그리고 granular 테이블 형식입니다.² npm latest인 v0.149.1(2026년 8월 24일, UTC) 기준으로 최신 내용입니다.¹ {.answer-block}

요약

• 변경 내용: v0.149.0의 전체 변경 로그에는 PR #39630 “Retire the untrusted approval policy”가 실려 있습니다. 릴리스 노트는 그 제목 외에 마이그레이션 안내를 주지 않지만,¹ PR 설명은 줍니다: untrusted는 CLI, 설정 스키마, MCP 도구 인터페이스에서 사라졌고, 명시적 설정은 “now fail with an actionable error”(이제 조치 가능한 오류와 함께 실패)합니다.⁴
• 조치해야 할 사람: ~/.codex/config.toml이나 프로필에 approval_policy = "untrusted"가 있는 모든 사람, 그리고 스크립트, 별칭, CI에서 --ask-for-approval untrusted(또는 -a untrusted)를 넘기는 모든 사람.
• 대체 값: on-request이며 샌드박스 모드는 그대로입니다. read-only와 on-request의 조합이 문서의 “Safe read-only browsing”(안전한 읽기 전용 탐색) 쌍입니다.² 예전의 workspace-write와 untrusted 조합에는 직접적인 후속 조합이 없으며, 명령별 프롬프트는 이제 exec policy 규칙에 있습니다.⁴⁸
• 현재 집합: on-request, never, 또는 범주별 제어를 위한 approval_policy = { granular = { ... } }. 샌드박스 모드는 read-only, workspace-write, danger-full-access 그대로입니다.²
• 조용히 넘어가지 않고 즉시 실패: 남아 있는 approval_policy = "untrusted"는 config.toml, 프로필 파일, -c 오버라이드 어디에 있든 Error: approval_policy = "untrusted" is no longer supported; remove this setting으로 세션을 멈춥니다. codex doctor는 키 이름 없이 설정을 불러올 수 없다고만 보고합니다.⁵

Codex 0.149는 무엇을 바꿨나요?

주요 항목은 codex agents 대시보드, codex queue, 확장된 codex doctor 같은 새로운 표면이고, 승인 정책 변경은 그 아래 전체 변경 로그에 있습니다.¹ PR #39630의 설명에는 릴리스 노트가 생략한 세부 사항이 담겨 있습니다. 세 항목 중 두 개가 여기서 중요합니다: “Remove untrusted from the CLI, configuration schema, and MCP tool interface. Explicit approval_policy = "untrusted" settings now fail with an actionable error.”(CLI, 설정 스키마, MCP 도구 인터페이스에서 untrusted를 제거. 명시적 approval_policy = “untrusted” 설정은 이제 조치 가능한 오류와 함께 실패) 그리고 “Remove the known-safe command allowlist. Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.”(알려진 안전 명령 허용 목록을 제거. untrusted로 표시된 프로젝트는 명시적인 exec policy 규칙이 허용하지 않는 한 이제 모든 명령에 승인을 요청)입니다.⁴ 같은 릴리스의 버그 수정 하나도 같은 독자에게 중요합니다: “Resumed and forked threads now restore their active permission profile instead of silently falling back to current defaults.”(재개되거나 포크된 스레드는 이제 조용히 현재 기본값으로 되돌아가는 대신 활성 권한 프로필을 복원)¹

각 행은 v0.149.0 릴리스 노트를 그대로 인용한 것입니다.¹

누가 무엇을 수정해야 하나요?

네 곳에 이 값이 있을 수 있습니다. 먼저 전부 찾으세요. 메인 파일을 고쳐도 프로필이나 셸 별칭이 예전 정책을 다시 적용하기 때문입니다.

레거시 테이블 실패는 요란합니다. 0.149.1에서 config.toml에 [profiles.safe] 테이블이 남아 있는 상태로 codex exec --profile safe "hi"를 실행하면 Error loading config.toml: --profile `safe` cannot be used while .../config.toml contains legacy `profile = "safe"` or `[profiles.safe]` config; move those settings into .../safe.config.toml ...으로 멈추므로, 팀원의 --profile safe는 Codex가 승인 값을 읽기도 전에 실패합니다.⁵

각 쪽마다 grep 하나씩:

# Config and profiles: match the key, not the bare word
grep -rnE 'approval_policy\s*=\s*"untrusted"' ~/.codex/*.toml .codex/config.toml 2>/dev/null

# Scripts, aliases, CI
grep -rn --exclude-dir=node_modules \
  -e "ask-for-approval untrusted" -e "ask-for-approval=untrusted" \
  -e "-a untrusted" -e "approval_policy=untrusted" \
  ~/.zshrc ~/.bashrc . 2>/dev/null

# CI directories: read every bare hit, because YAML can split a flag from its value
grep -rn --exclude-dir=node_modules "untrusted" .github .gitlab-ci.yml .circleci 2>/dev/null

첫 번째 grep이 단어 하나가 아니라 키를 매칭하는 데에는 이유가 있습니다. trust_level = "untrusted"는 다른 설정이니 그대로 두세요. 설정 참조 문서는 projects.<path>.trust_level을 “a project or worktree as trusted or untrusted”(프로젝트나 워크트리를 신뢰됨 또는 신뢰되지 않음으로) 표시하는 키로 정의하며, 신뢰되지 않는 프로젝트는 “skip project-scoped .codex/ layers, including project-local config, hooks, and rules.”(프로젝트 로컬 설정, 훅, 규칙을 포함한 프로젝트 범위 .codex/ 계층을 건너뜀)⁷ PR #39630은 이 키가 아니라 신뢰되지 않는 프로젝트가 명령을 다루는 방식을 바꿉니다: “Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.”⁴ untrusted를 무작정 찾아 바꾸면 이 키가 망가집니다.

프로필 파일은 문서화된 프리셋 메커니즘이므로(~/.codex/<name>.config.toml, codex --profile <name>으로 선택), 메인 설정이 무엇이든 팀원의 프로필이 폐지된 값을 다시 들여올 수 있습니다.²

현재 승인 정책 집합은 무엇인가요?

Codex의 보안은 두 계층에서 나옵니다: 샌드박스 모드는 Codex가 기술적으로 무엇을 할 수 있는지 정하고, 승인 정책은 Codex가 언제 멈추고 물어야 하는지 정합니다.² 이번 폐지는 두 번째 계층만 건드립니다.

granular 형식은 다섯 가지 프롬프트 범주를 다룹니다: sandbox_approval, rules(execpolicy 프롬프트), mcp_elicitations, request_permissions, skill_approval.² 이 중 어느 것도 untrusted를 재현하지 못하는데, 이는 프롬프트 범주 필터가 아니라 명령 분류 규칙(알려진 안전한 읽기는 자동 실행, 상태를 바꿀 수 있는 것은 프롬프트)이었기 때문입니다.²

workspace-write와 untrusted의 조합, 즉 문서의 “Automatically edit but ask for approval to run untrusted commands”(자동으로 편집하되 신뢰되지 않는 명령 실행 전에는 승인 요청) 행에는 직접적인 후속 조합이 없습니다.² workspace-write와 on-request는 샌드박스 안에서 실행되는 명령에 대해 더 이상 묻지 않고, read-only와 on-request는 명령뿐 아니라 편집에 대해서도 묻습니다.² PR #39630은 “the known-safe command allowlist”(알려진 안전 명령 허용 목록)를 제거했고, 명령별 프롬프트를 위해 남은 메커니즘을 지목합니다: “Projects marked untrusted now request approval for every command unless an explicit exec policy rule allows it.”⁴ exec policy 규칙은 granular 테이블의 rules 범주 뒤에 있는 것과 같은 메커니즘으로, 승인 페이지가 나열하는 “execpolicy-rule prompts”입니다.² 쓰기 가능한 워크스페이스에서 untrusted에 의존하던 보안 담당자는 이 규칙을 만들어야 합니다. 규칙 문서는 이를 샌드박스 바깥에서 실행되는 명령으로 한정하며, decision = "prompt"를 가진 prefix_rule은 “before each matching invocation”(일치하는 호출마다 그 전에) 프롬프트를 띄웁니다:⁸

# ~/.codex/rules/default.rules
prefix_rule(pattern = ["git", "push"], decision = "prompt")

읽기 전용 샌드박스는 변경을 아예 차단하는 무딘 대안으로 남아 있습니다.³

정확히 무엇을 수정해야 하나요?

매핑은 한 줄입니다: untrusted는 on-request가 되고, 샌드박스 모드는 있던 그대로 둡니다.³

메인 설정(프로필 파일도 동일하게 수정합니다):

# ~/.codex/config.toml (before)
approval_policy = "untrusted"
sandbox_mode    = "read-only"

# ~/.codex/config.toml (after)
approval_policy = "on-request"
sandbox_mode    = "read-only"

스크립트:

# before
codex --sandbox workspace-write --ask-for-approval untrusted "$@"

# after
codex --sandbox workspace-write --ask-for-approval on-request "$@"

-a/--ask-for-approval 쌍은 codex TUI 바이너리의 것입니다. codex exec에는 그런 플래그가 없습니다: 0.149.1에서 codex exec --ask-for-approval untrusted "hi"는 error: unexpected argument '--ask-for-approval' found로 실패합니다.⁵ codex exec에서는 정책을 설정에 두거나 인라인으로 넘기세요:

# non-interactive run, policy set inline
codex exec --sandbox workspace-write -c approval_policy=never "$@"

판단이 필요한 사항이 둘 있습니다. 첫째, 아무도 프롬프트에 답할 수 없는 환경에서 on-request로 실행되는 대화형 codex 바이너리는 첫 승인에서 멈춥니다. 문서화된 비대화형 쌍은 --sandbox read-only --ask-for-approval never이고, codex exec --sandbox workspace-write가 문서화된 비대화형 진입점입니다.² 둘째, “모든 권한을 주되 매번 묻기” 위해 untrusted를 danger-full-access와 짝지었다면, 그 특성은 교체 후에 살아남지 않습니다. 문서가 드는 on-request 프롬프트의 두 예시는 샌드박스를 벗어나는 것과 네트워크를 쓰는 것인데, danger-full-access는 두 트리거를 모두 없앱니다.² granular 테이블의 나머지 네 범주에서 오는 프롬프트는 전체 접근 상태에서도 여전히 뜹니다: decision = "prompt"인 exec policy 규칙, MCP elicitation, 스킬 승인, request_permissions 프롬프트입니다.²⁸ 선택 설정인 approvals_reviewer = "auto_review"는 대상 프롬프트를 리뷰어 에이전트로 보내며, 대화형 정책에만 적용되므로 마이그레이션 후에도 계속 쓸 수 있습니다.²

변경이 적용됐는지 어떻게 확인하나요?

1. codex doctor를 실행하세요. 폐지된 값이 설정에 남아 있으면 config 줄은 ✗ config config could not be loaded로 시작하고 상세 줄은 · failed to load Codex config라고 나오며, doctor는 문제의 키 이름을 알려주지 않습니다. 키 이름이 담긴 오류는 codex나 codex exec를 실행할 때 나옵니다. doctor 줄이 깨끗하면 값이 사라진 것이고, 실패했다면 어느 키인지 보려면 여전히 세션을 시작해야 합니다.⁵ 값이 config.toml에 있든, --profile로 선택한 프로필 파일에 있든, -c approval_policy=untrusted 오버라이드에 있든 실행 오류는 동일합니다.⁵ 플래그 형식은 더 이른 인수 파싱 단계에서 실패합니다: codex -a untrusted --version은 error: invalid value 'untrusted' for '--ask-for-approval <APPROVAL_POLICY>'에 이어 [possible values: on-request, never]를 출력합니다.⁵
2. 임시 디렉터리에서 일회용 세션을 시작하고 /status를 실행하세요. Permissions 줄에 활성 정책이 표시되며, on-request는 거기서 “Ask for approval”로 표시됩니다.⁵ /permissions는 활성 모드를 보고하는 대신 프리셋 메뉴를 열므로 /status를 읽으세요.⁵ /status는 워크스페이스 디렉터리도 나열합니다.²
3. 예전 스레드 하나를 재개하세요. PR #39153 “Restore permission profiles when resuming threads”는 이제 “the latest persisted approval policy, approvals reviewer, and active permission-profile ID when resuming or forking a thread”(스레드를 재개하거나 포크할 때 마지막으로 저장된 승인 정책, 승인 리뷰어, 활성 권한 프로필 ID)를 복원합니다.⁶ 저장된 정책이 untrusted인 재개 스레드는 테스트하지 못했습니다. 직접 열어보기 전까지는 알 수 없는 경우로 취급하세요.

문서 자체에 대한 주의 사항 하나. 공식 “Agent approvals & security” 페이지는 2026년 8월 24일에 캡처하고 8월 25일에 다시 확인한 시점에도 조합 표에 여전히 --ask-for-approval untrusted를 보여주고, “With --ask-for-approval untrusted, Codex runs only known-safe read operations automatically,”로 시작하는 문단을 여전히 싣고 있으며, config.toml 예시에 여전히 approval_policy = "untrusted"를 쓰고 있습니다.² 설정 참조의 approval_policy 항목은 타입 유니온에서 untrusted를 첫 번째로 나열하면서 설명에서는 다른 값을 폐지됨으로 표시합니다: “on-failure is deprecated; use on-request for interactive runs or never for non-interactive runs.”(on-failure는 지원 중단됨; 대화형 실행에는 on-request, 비대화형 실행에는 never 사용)⁷ PR과 바이너리가 권위 있는 기록이고, 문서는 그보다 뒤처져 있습니다. 문서의 예시 블록을 값을 바꾸지 않은 채 새 0.149 설치에 그대로 복사하지 마세요.

자주 묻는 질문

Codex에서 approval_policy = "untrusted"를 무엇으로 대체하나요?

approval_policy = "on-request"이며, 기존 sandbox_mode는 그대로 둡니다. 가장 신중한 조합을 원한다면 sandbox_mode = "read-only"를 함께 설정하세요.³

어느 Codex 버전에서 untrusted 정책이 폐지되었나요?

2026년 8월 20일 stable로 나온 v0.149.0이며, 전체 변경 로그의 PR #39630을 통해서입니다. v0.149.1(2026년 8월 24일, UTC)이 현재 npm latest입니다.¹

config.toml에 untrusted를 그대로 두면 어떻게 되나요?

Codex가 세션 시작을 거부합니다. 0.149.1에서 codex exec는 Error: approval_policy = "untrusted" is no longer supported; remove this setting으로 멈추고, 프로필 파일과 -c approval_policy=untrusted에서도 같은 오류가 나오며, codex doctor는 설정을 불러올 수 없다고만 보고합니다.⁵ PR #39630은 이 동작을 “with an actionable error”(조치 가능한 오류와 함께) 실패하는 것으로 설명합니다.⁴

on-request는 예전 untrusted보다 덜 안전한가요?

workspace-write 안에서는 그렇습니다: untrusted는 상태를 바꿀 수 있는 모든 명령 전에 물었고, on-request는 샌드박스 안 명령을 묻지 않고 실행합니다.² 샌드박스 계층이 그 여유의 일부를 되찾아 줍니다: read-only는 정책과 무관하게 쓰기를 막고, on-request는 여전히 모든 권한 상승 전에 묻습니다.³ 쓰기 가능한 워크스페이스에서 명령별 프롬프트가 필요하다면 PR #39630이 지목한 메커니즘인 exec policy 규칙을 작성하세요.⁴⁸

샌드박스 모드도 바꿔야 하나요?

아니요. 이번 폐지는 승인 정책에만 영향을 미치므로, read-only, workspace-write, danger-full-access는 있던 그대로 두세요.³

핵심 요약

개별 개발자라면: - ~/.codex/*.toml에서 (단어 하나가 아니라) approval_policy = "untrusted"를 grep하고, 각 항목을 on-request로 바꾸고, sandbox_mode와 trust_level = "untrusted"는 그대로 두세요. - codex doctor를 실행한 뒤 임시 세션에서 /status를 실행하고, 예전 스레드 하나를 재개해 0.149가 무엇을 복원하는지 확인하세요.

공유 프로필과 스크립트를 관리하는 팀이라면: - 프로필 파일과 인라인 오버라이드를 config.toml과 같은 커밋에서 고치세요. 레거시 [profiles.<name>] 테이블은 ~/.codex/<name>.config.toml로 옮기기 전까지 --profile을 완전히 막습니다.⁵ - 무인 작업은 codex 바이너리에서 --sandbox read-only --ask-for-approval never로, 또는 codex exec --sandbox workspace-write -c approval_policy=never로 전환하세요. on-request 상태의 대화형 codex 바이너리는 아무도 답하지 않을 프롬프트에서 멈추고, codex exec에는 --ask-for-approval 플래그가 없습니다.⁵

보안 담당자라면: - untrusted 분류기(안전한 읽기는 자동 실행, 변경 시 프롬프트)에는 granular 대응물이 없습니다. PR #39630은 명령별 프롬프트를 위해 exec policy 규칙(“unless an explicit exec policy rule allows it”)을 지목하며,⁴ 이는 ~/.codex/rules/default.rules에 decision = "prompt"인 prefix_rule로 작성하고,⁸ 읽기 전용 샌드박스는 변경을 아예 차단합니다. - 리뷰어 에이전트가 대상 프롬프트에서 사람을 대신할 수 있는 곳에서는 approvals_reviewer = "auto_review"를 고려하세요.

참고 자료