Claude Code와 OpenCode의 허용 설정(allow/ask/deny): 평가 순서 차이 및 사용 시 주의점

AI 코딩 에이전트에게 작업을 맡길 때, 가장 먼저 결정해야 할 것은 '무엇을 확인 없이 실행하게 할지', '무엇은 반드시 확인하게 할지', 그리고 '무엇을 금지할지'입니다. Claude Code와 OpenCode 모두 allow, / ask, / deny의 세 가지로 허용 설정을 하지만, 규칙의 평가 순서가 반대인 등 같은 감각으로 작성하면 의도대로 작동하지 않는 부분이 있습니다.

본 기사에서는 두 도구의 공식 문서를 통해 사양을 확인하고, 연습용 리포지토리를 위한 설정 예시와 필자가 환경에서 실제로 경험한 주의점들을 정리했습니다.

본 기사에서 확인한 버전과 날짜

전제: 허용 설정은 '사고를 줄이는 장치'

먼저 두 도구에 공통되는 전제를 확인하겠습니다.

• 허용 규칙을 강제하는 것은 도구 본체입니다. Claude Code의 공식 문서에는 프롬프트나 CLAUDE.md 등의 지시가 Claude가 무엇을 하려고 하는지에 영향을 주기는 하지만, Claude Code가 무엇을 허용할지는 변경하지 않는다고 명시되어 있습니다. '.env는 읽지 마라'라고 지시 파일에 적기만 해서는 제한이 되지 않습니다. -
• 커맨드 규칙은 보안의 벽이 아닙니다. Claude Code의 Bash 규칙은 Claude가 작성한 커맨드의 문자열을 대상으로 대조됩니다. 예를 들어 Bash(rm *)는 rm -rf build/를 막지만, /bin/rm -rf build/나 bash -c 'rm -rf build/'에는 일치하지 않습니다. Bash(git push *) 역시 git -C . push origin main에는 일치하지 않습니다. OS 레벨에서 제한하고 싶다면 샌드박스 기능이나 컨테이너를 병용해야 합니다.

허용 설정은 '에이전트가 평소 작성하는 커맨드로 인해 발생하는 사고를 줄이는' 용도로 생각하는 것이 안전합니다.

Claude Code: 평가 순서는 deny → ask → allow

규칙의 평가 순서

Claude Code의 규칙은 deny → ask → allow 순으로 평가되며, 가장 먼저 일치한 것이 결과가 됩니다. 규칙의 구체성(세밀하게 작성했는지 여부)에 따라 순서는 바뀌지 않습니다. 즉, allow에 세밀한 예외를 써도, 그것보다 넓은 범위의 deny가 있다면 deny가 우선됩니다.

허용 모드

규칙과는 별개로, 세션 전체의 동작 방식을 결정하는 '허용 모드'가 있습니다 (Shift+Tab으로 전환 가능).

여기서 특히 주의해야 할 점이 3가지 있습니다.

• v2.1.283 이후, 대화형 터미널과 VS Code 세션은 이전에는 플랜에 따라 기본값이 달랐습니다. 확인할 때마다 직접 판단하고 싶다면, auto 모드로 시작합니다. ~/.claude/settings.json에서 `

모드에서는 작업 중인 리포지토리의 브랜치에 대한 push가 기본적으로 확인 없이 실행됩니다 (ask)

규칙으로 Bash(git push *)를 지정합니다.

참고로, deny 규칙은 bypassPermissions를 포함하는 모든 모드에서 유효합니다. ask 규칙에 일치한 작업도 어떤 모드에서도 자동으로 승인되지 않습니다.

설정 예시 (연습용 리포지토리 대상)

.claude/settings.json의 예시입니다. 테스트와 git status / git diff는 확인 없이 실행하고, push는 매번 확인하며, .env 읽기와 rm은 금지합니다.

{
"permissions": {
"allow": [
...

작성 시 핵심 포인트는 다음과 같습니다.

• 끝에 붙이는 * (공백과 별표)는 인수가 없는 명령어에도 일치합니다. Bash(git status *)는 git status에도 일치합니다. - 공백 유무에 따라 의미가 달라집니다.
  Bash(ls *)는 lsof에는 일치하지 않지만, Bash(ls*)는 일치합니다. -
  Read의 deny는 Claude Code의 읽기 도구를 막는 것입니다. 스크립트가 스스로 파일을 여는 경우는 대상이 아니므로, Bash(rm *)와 마찬가지로 '사고를 줄이는 장치'라고 생각하시면 됩니다.

시도해 보니 알게 된 것: 신뢰하지 않는 폴더에서는 allow가 무시된다

작성자의 환경에서 이러한 설정을 막 적용한 연습용 폴더에서 claude -p (print 모드)를 실행하자, 출력 시작 부분에 다음 경고가 표시되었습니다 (경로는 가렸습니다).

Ignoring 3 permissions.allow entries from .claude/settings.json: this workspace has not been trusted. Run Claude Code interactively here once and accept the trust dialog, ...

공식 문서에도 프로젝트의 .claude/settings.json에 있는 permissions.allow는 해당 폴더의 '신뢰 대화 상자'를 승인할 때까지 적용되지 않는다고 쓰여 있습니다. deny와 ask는 제한을 추가하는 것일 뿐이므로, 승인 전부터 적용됩니다.

즉, 막 클론한 리포지토리에 있는 allow 규칙은 모르는 사이에 효력이 발생하지 않습니다. 반대로, 직접 준비한 allow 규칙이 작동하지 않을 때는 한 번 대화형 모드로 시작하여 신뢰 대화 상자를 승인했는지 확인해 보세요.

또한, 프로젝트의 .claude/settings.json이나 .claude/settings.local.json에 `

Claude Code와 OpenCode의 같은 방침을, OpenCode로 작성한 예시입니다.

{
"$schema": "https://opencode.ai/config.json",
"permission": {
...

bash

에서 *": "ask"를 맨 앞에 두고, 예외 규칙을 뒤에 나열했습니다. 순서를 반대로 하면, 뒤의 *가 모두와 일치하여 개별 규칙이 의미를 잃게 됩니다.

시도해 본 것: 삭제는 bash가 아닌 edit에서 막혔다

저의 환경(2026-10-02, OpenCode 1.18.34, GitHub Copilot 경유 gpt-5-mini, --pure로 시작하여 비대화형 opencode run)에서, 위 설정을 적용한 연습용 리포지토리에 다음 4가지를 요청했습니다(요청 내용은 요약입니다).

또한, 에이전트의 보고를 그대로 믿지 말고, 출력과 git status / git diff를 직접 확인합니다. 요청문 마지막에 다음과 같은 보고 형식을 지정해 두면 확인하기 쉽습니다.

작업을 완료했다면, 다음 형식으로 보고해 주세요.
1. 실행한 확인 명령어와 그 출력 (요약이 아닌, 마지막 몇 줄을 그대로)
2. 완료 여부
...

요약

• Claude Code는 deny → ask → allow(가장 먼저 일치하는 규칙) 순서로 작동하며, OpenCode는 마지막에 일치한 규칙이 우선됩니다. - Claude Code는 v2.1.283 이후부터 대화형 세션이 auto 모드로 시작됩니다. acceptEdits에서는 작업 폴더 내의 rm도 자동 승인됩니다. - 명령어 규칙은 문자열 일치 여부일 뿐, 보안 장벽이 아닙니다. 삭제는 파일 편집 도구로도 가능하므로, edit 측 설정도 확인합니다. - 설정을 마쳤다면, 연습용 리포지토리에서 실제로 요청하며 확인해 봅니다.

토론