승인과 권한: 노브 두 개, 드롭다운 하나

돌릴 수 있는 권한 콘솔입니다. 왼쪽 노브 둘이 각각 한 가지, 오른쪽 드롭다운이 프리셋. 조작을 고르고 「재생」을 눌러 도구 호출이 관문을 넘는 과정을 본 뒤, 노브를 돌리고 프리셋을 바꿔 다시 실행해 같은 조작의 운명이 어떻게 달라지는지 보세요.

결론부터: DSH는 “권한”이라는 큰 말을 서로 안 참견하는 작은 질문 둘로 쪼갭니다. 노브 1 sandbox/mode는 이 명령의 파일 효과가 어디까지 허용되는지 — read-only·workspace-write·danger-full-access — 파일시스템만, 네트워크·프로세스 가시성은 어휘에 없습니다(docs/subsystems/sandbox.zh.md 앞부분 정의). 노브 2 approval/policy는 사람 결정이 필요할 때 물을지 — ask / never.

로그에서도 독립 이벤트 둘입니다: sandbox/mode와 approval/policy. 실행·프롬프트·리플레이는 이 두 노브 이벤트의 접힌 결과만 읽습니다. 직교의 실제 의미: 하나를 돌려도 다른 쪽은 꿈쩍 안 합니다.

그다음이 드롭다운입니다. ctx.permissionPresets가 이름→노브 조합 표를 유지합니다. 기본 표는 두 줄: workspace-write → workspace-write + ask, danger-full-access → danger-full-access + never(permission-presets/src/index.ts 167–176행). 선택 능력이고 agent loop 본선에 없으며 강제 집행권도 없습니다.

프리셋 전환 시? 이벤트 셋, 순서 고정: 먼저 로그만 하는 permission/preset으로 의도를 남기고, 두 노브의 정규 setter로 sandbox/mode·approval/policy를 쓰되 실제 유효 값이 바뀐 쪽만. 현재 프리셋을 다시 고르면? 아무것도 안 붙입니다. 리플레이 때 실행 층은 노브 이벤트만 인정하고, preset 이벤트의 유일한 역할은 같은 조합을 공유하는 프리셋 둘 중 당신이 고른 이름을 기억하는 것입니다.

그리고 custom. 예약어라 표에 그 이름 항목이 있으면 안 되고(플러그인 로드 시 예외). 노브를 표에 없는 조합으로 돌릴 때만 current()가 custom을 파생해 클라이언트에 보여 줍니다. 나가기만: 현재 상태는 될 수 있어도 전환 대상은 영원히 아니고 이벤트 payload에도 안 나옵니다. 데모 드롭다운이 회색 비선택인 이유가 곧 소스 동작입니다.

경계 질문 하나: 승인 서비스가 마운트된 뒤 플러그인이 prepend로 응답자 체인 맨 앞에 전부 허용 응답자를 넣으면 never를 우회할 수 있을까요? 아니요 — never는 체인에서 실행되지 않으니까요. decide() 앞부분을 보세요:

  private async decide(req: ApprovalRequest, session: Session): Promise<ApprovalOutcome> {
    const signal = req.signal
    if (signal?.aborted) return 'cancelled'
    // The 'never' policy is decided HERE, before any dispatch: a listener
    // registered with `prepend: true` after this service mounts would sit
    // ahead of any gate LISTENER, so a listener-shaped gate cannot keep the
    // documented promise that 'never' rejects deterministically regardless
    // of registration order — only the service's own request path can.
    if (this.effectivePolicy(session) === 'never') return 'rejected'

주석이 설계 의도를 끝냅니다: never의 판정점은 서비스 자신의 요청 경로에 있고, 리스너 형태 게이트는 등록 순서와 무관하다는 약속을 지킬 수 없습니다. 317–329행의 ask 폴백도 빈틈없습니다: 체인 무응답 기본값은 unavailable, 예외 응답자는 unavailable로 접히고, 이상한 반환도 unavailable로 정규화됩니다.

“프리셋은 바로가기일 뿐”의 구현 전부가 열네 줄 private apply()입니다. 일 셋, 순서 고정. 1) resolve(name) 표 조회 — 없으면 예외, 알려진 키도 나열. 2) current() 파생 결과와 비교: 고른 이름이 유효 프리셋과 다를 때만 permission/preset을 붙이고, 현재를 다시 고르면 이 단계는 아무것도 안 씁니다. 3) 노브 둘을 검사해 프리셋의 샌드박스 모드가 이벤트 접힌 유효 값(없으면 배포 기본값)과 다르면 setSandboxMode(), 승인 정책도 주입된 setApproval로. 유효 값이 안 바뀐 쪽은 건너뜁니다.

따라서 프리셋 전환에 세 번째 실행 경로나 숨은 상태는 없습니다: 의도 로그 하나와 많아 봐야 정규 setter를 통한 노브 쓰기 두 번 — 로그에 붙인 것이 곧 실행 층이 접는 것입니다. custom 파생은 같은 파일 derive(): 지난 프리셋이 현재 노브와 맞으면 유지, 아니면 선언 순 첫 매칭, 없으면 custom.

출처:packages/interaction/permission-presets/src/index.ts 379–392행(apply()), 309–321행(derive()), 확인일 2026-08-13。

Claude Code는 같은 영토를 단일 permission mode 축으로 만듭니다: default·plan·acceptEdits·bypassPermissions·dontAsk(복원 소스 restored-src/src/utils/permissions/PermissionMode.ts 44–91행, 원고 7장), 여기에 allow/deny/ask 규칙 표를 더하고 Bash(git commit:*) 같은 명령 접두까지 세밀해질 수 있습니다.

나란히 보면 접는 대가가 보입니다. dontAsk ≈ DSH never, bypassPermissions ≈ danger-full-access + never — 하지만 다섯 칸이 한 축이라 샌드박스 조임과 “물을지”가 묶여 팔립니다. DSH 이중 노브는 read-only + ask를 표현할 수 있어요: 샌드박스는 읽기 전용 바닥, 정말 쓰기가 필요할 때 한 번 팝업. CC 모드 축에는 직접 대응하는 칸이 없습니다. 반대로 CC는 이중 노브가 못 하는 것: 도구·명령 접두 세분 규칙 표. DSH 노브는 세션 전역이라 도구 단위 게이트는 hook 층이 필요합니다. 복잡도를 두는 곳이 다릅니다. Grok Build 인가 체인은 또 다른 길(도구 요청→제한 실행 층층이) — Grok 완전 인가 체인을 보세요.