​

실행 승인

​

적용 위치

• gateway host → Gateway 머신의 openclaw 프로세스
• node host → node runner(macOS 컴패니언 앱 또는 헤드리스 node 호스트)

• Gateway 인증 호출자는 해당 Gateway의 신뢰된 운영자로 간주됩니다.
• 페어링된 node는 그 신뢰된 운영자 권한을 node 호스트까지 확장합니다.
• 실행 승인은 우발적 실행 위험을 줄이지만, 사용자별 인증 경계는 아닙니다.
• 승인된 node-host 실행은 표준화된 실행 컨텍스트에 바인딩됩니다: 표준 cwd, 정확한 argv, 존재하는 경우 env 바인딩, 적용 가능한 경우 고정된 실행 파일 경로.
• 셸 스크립트와 직접 인터프리터/런타임 파일 호출의 경우, OpenClaw는 하나의 구체적인 로컬 파일 피연산자에도 바인딩하려고 시도합니다. 승인 후 실행 전 사이에 그 바인딩된 파일이 변경되면, 변경된 내용을 실행하는 대신 실행이 거부됩니다.
• 이 파일 바인딩은 의도적으로 최선 시도 방식이며, 모든 인터프리터/런타임 로더 경로의 완전한 의미론 모델은 아닙니다. 승인 모드가 바인딩할 정확히 하나의 구체적인 로컬 파일을 식별할 수 없으면, 완전한 보호를 가장하는 대신 승인 기반 실행 토큰 발급을 거부합니다.

• node host 서비스는 system.run을 로컬 IPC를 통해 macOS 앱으로 전달합니다.
• macOS 앱은 승인을 적용하고 UI 컨텍스트에서 명령을 실행합니다.

​

설정 및 저장소

{
  "version": 1,
  "socket": {
    "path": "~/.openclaw/exec-approvals.sock",
    "token": "base64url-token"
  },
  "defaults": {
    "security": "deny",
    "ask": "on-miss",
    "askFallback": "deny",
    "autoAllowSkills": false
  },
  "agents": {
    "main": {
      "security": "allowlist",
      "ask": "on-miss",
      "askFallback": "deny",
      "autoAllowSkills": true,
      "allowlist": [
        {
          "id": "B0C8C0B3-2C2D-4F8A-9A3C-5A4B3C2D1E0F",
          "pattern": "~/Projects/**/bin/rg",
          "lastUsedAt": 1737150000000,
          "lastUsedCommand": "rg -n TODO",
          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"
        }
      ]
    }
  }
}

​

승인 없는 “YOLO” 모드

• OpenClaw 구성의 요청된 실행 정책(tools.exec.*)
• ~/.openclaw/exec-approvals.json의 호스트 로컬 승인 정책

• tools.exec.security: gateway/node에서 full
• tools.exec.ask: off
• 호스트 askFallback: full

• tools.exec.host=auto는 실행 위치를 선택합니다: 가능하면 샌드박스, 그렇지 않으면 gateway.
• YOLO는 호스트 실행 승인 방식을 선택합니다: security=full과 ask=off.
• YOLO 모드에서 OpenClaw는 구성된 호스트 실행 정책 위에 별도의 휴리스틱 명령 난독화 승인 게이트나 스크립트 사전 점검 거부 계층을 추가하지 않습니다.
• auto는 샌드박스 세션에서 gateway 라우팅을 자유 재정의로 만들지 않습니다. 호출별 host=node 요청은 auto에서 허용되며, host=gateway는 샌드박스 런타임이 활성화되지 않은 경우에만 auto에서 허용됩니다. 안정적인 비-auto 기본값이 필요하면 tools.exec.host를 설정하거나 /exec host=...를 명시적으로 사용하세요.

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart

openclaw approvals set --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

openclaw exec-policy preset yolo

• 로컬 tools.exec.host/security/ask
• 로컬 ~/.openclaw/exec-approvals.json 기본값

openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

• openclaw exec-policy는 node 승인을 동기화하지 않습니다
• openclaw exec-policy set --host node는 거부됩니다
• node 실행 승인은 런타임에 node에서 가져오므로, node 대상 업데이트에는 openclaw approvals --node ...를 사용해야 합니다

• /exec security=full ask=off는 현재 세션만 변경합니다.
• /elevated full은 해당 세션에서 실행 승인도 건너뛰는 비상 우회 바로가기입니다.

​

정책 조정 항목

​

Security (exec.security)

• deny: 모든 호스트 실행 요청을 차단합니다.
• allowlist: 허용 목록에 있는 명령만 허용합니다.
• full: 모든 것을 허용합니다(elevated와 동일).

​

Ask (exec.ask)

• off: 프롬프트를 표시하지 않습니다.
• on-miss: 허용 목록이 일치하지 않을 때만 프롬프트를 표시합니다.
• always: 모든 명령에 대해 프롬프트를 표시합니다.
• 유효 ask 모드가 always일 때는 allow-always의 지속적 신뢰가 프롬프트를 억제하지 않습니다

​

Ask fallback (askFallback)

• deny: 차단.
• allowlist: 허용 목록이 일치할 때만 허용.
• full: 허용.

​

인라인 인터프리터 eval 강화 (tools.exec.strictInlineEval)

• python -c
• node -e, node --eval, node -p
• ruby -e
• perl -e, perl -E
• php -r
• lua -e
• osascript -e

• 이 명령들은 여전히 명시적 승인이 필요합니다.
• allow-always는 이들에 대해 새 허용 목록 항목을 자동으로 지속 저장하지 않습니다.

​

허용 목록(에이전트별)

• ~/Projects/**/bin/peekaboo
• ~/.local/bin/*
• /opt/homebrew/bin/rg

• id UI 식별에 사용하는 안정적 UUID(선택 사항)
• 마지막 사용 시각 타임스탬프
• 마지막 사용 명령
• 마지막 확인 경로

​

Skills CLI 자동 허용

• 이것은 수동 경로 허용 목록 항목과는 별도의 암묵적 편의 허용 목록입니다.
• Gateway와 node가 같은 신뢰 경계에 있는 신뢰된 운영자 환경을 위한 기능입니다.
• 엄격한 명시적 신뢰가 필요하다면 autoAllowSkills: false로 유지하고 수동 경로 허용 목록 항목만 사용하세요.

​

안전한 bin(stdin 전용)

• grep: --dereference-recursive, --directories, --exclude-from, --file, --recursive, -R, -d, -f, -r
• jq: --argfile, --from-file, --library-path, --rawfile, --slurpfile, -L, -f
• sort: --compress-program, --files0-from, --output, --random-source, --temporary-directory, -T, -o
• wc: --files0-from

​

safe bin과 allowlist 비교

• safeBins는 구성에서 가져옵니다(tools.exec.safeBins 또는 에이전트별 agents.list[].tools.exec.safeBins).
• safeBinTrustedDirs는 구성에서 가져옵니다(tools.exec.safeBinTrustedDirs 또는 에이전트별 agents.list[].tools.exec.safeBinTrustedDirs).
• safeBinProfiles는 구성에서 가져옵니다(tools.exec.safeBinProfiles 또는 에이전트별 agents.list[].tools.exec.safeBinProfiles). 에이전트별 프로필 키가 전역 키를 재정의합니다.
• allowlist 항목은 호스트 로컬 ~/.openclaw/exec-approvals.json의 agents.<id>.allowlist 아래에 있습니다(또는 Control UI / openclaw approvals allowlist ...를 통해 관리).
• openclaw security audit는 인터프리터/런타임 bin이 명시적 프로필 없이 safeBins에 나타나면 tools.exec.safe_bins_interpreter_unprofiled 경고를 표시합니다.
• openclaw doctor --fix는 누락된 사용자 지정 safeBinProfiles.<bin> 항목을 {}로 스캐폴딩할 수 있습니다(이후 검토하고 더 엄격하게 조정하세요). 인터프리터/런타임 bin은 자동 스캐폴딩되지 않습니다.

​

Control UI 편집

​

승인 흐름

• node exec 경로는 먼저 하나의 표준화된 plan을 준비합니다
• 승인 레코드는 해당 plan과 바인딩 메타데이터를 저장합니다
• 승인되면 최종 전달되는 system.run 호출은 나중에 수정된 호출자 입력을 신뢰하지 않고 저장된 plan을 재사용합니다
• 승인 요청이 생성된 뒤 호출자가 command, rawCommand, cwd, agentId, 또는 sessionKey를 변경하면 gateway는 승인 불일치로 해당 전달 실행을 거부합니다

​

인터프리터/런타임 명령

• 정확한 argv/cwd/env 컨텍스트는 항상 바인딩됩니다.
• 직접 셸 스크립트 및 직접 런타임 파일 형식은 최선 시도로 하나의 구체적 로컬 파일 스냅샷에 바인딩됩니다.
• 여전히 하나의 직접 로컬 파일로 해석되는 일반적인 패키지 관리자 래퍼 형식(예: pnpm exec, pnpm node, npm exec, npx)은 바인딩 전에 언래핑됩니다.
• OpenClaw가 인터프리터/런타임 명령에 대해 정확히 하나의 구체적인 로컬 파일을 식별할 수 없으면 (예: 패키지 스크립트, eval 형식, 런타임별 로더 체인, 또는 모호한 다중 파일 형식) 승인 기반 실행은 지원 범위를 가장하는 대신 거부됩니다.
• 이러한 워크플로에는 샌드박싱, 별도의 호스트 경계, 또는 운영자가 더 넓은 런타임 의미를 수용하는 명시적 신뢰 allowlist/full 워크플로를 권장합니다.

​

후속 전달 동작

• 유효한 외부 전달 대상이 있으면(전달 가능한 채널 + 대상 to) 후속 전달은 해당 채널을 사용합니다.
• 외부 대상이 없는 webchat 전용 또는 내부 세션 흐름에서는 후속 전달이 세션 전용으로 유지됩니다(deliver: false).
• 호출자가 해결 가능한 외부 채널 없이 엄격한 외부 전달을 명시적으로 요청하면 요청은 INVALID_REQUEST로 실패합니다.
• bestEffortDeliver가 활성화되어 있고 외부 채널을 해결할 수 없으면 전달은 실패하는 대신 세션 전용으로 낮춰집니다.

• 명령 + 인수
• cwd
• 에이전트 ID
• 해석된 실행 파일 경로
• 호스트 + 정책 메타데이터

• Allow once → 지금 실행
• Always allow → allowlist에 추가하고 실행
• Deny → 차단

​

채팅 채널로의 승인 전달

​

Plugin 승인 전달

​

모든 채널에서 동일 채팅 승인

​

네이티브 승인 전달

• 호스트 실행 정책은 여전히 실행 승인이 필요한지 여부를 결정합니다
• approvals.exec는 승인 프롬프트를 다른 채팅 대상으로 전달할지 제어합니다
• channels.<channel>.execApprovals는 해당 채널이 네이티브 승인 클라이언트로 동작할지 제어합니다

• 채널이 네이티브 승인 전달을 지원함
• 승인자를 명시적 execApprovals.approvers 또는 해당 채널의 문서화된 대체 소스에서 확인할 수 있음
• channels.<channel>.execApprovals.enabled가 설정되지 않았거나 "auto"임

• Discord: channels.discord.execApprovals.*
• Slack: channels.slack.execApprovals.*
• Telegram: channels.telegram.execApprovals.*

• Slack, Matrix, Microsoft Teams 및 유사한 전달 가능한 채팅은 동일 채팅 /approve에 일반 채널 인증 모델을 사용합니다
• 네이티브 승인 클라이언트가 자동 활성화되면 기본 네이티브 전달 대상은 승인자 DM입니다
• Discord와 Telegram에서는 확인된 승인자만 승인 또는 거부할 수 있습니다
• Discord 승인자는 명시적일 수 있고(execApprovals.approvers) commands.ownerAllowFrom에서 추론될 수도 있습니다
• Telegram 승인자는 명시적일 수 있고(execApprovals.approvers) 기존 소유자 구성(allowFrom, 지원되는 경우 direct-message defaultTo)에서 추론될 수도 있습니다
• Slack 승인자는 명시적일 수 있고(execApprovals.approvers) commands.ownerAllowFrom에서 추론될 수도 있습니다
• Slack 네이티브 버튼은 승인 ID 종류를 유지하므로 plugin: ID가 두 번째 Slack 로컬 대체 계층 없이 Plugin 승인을 해결할 수 있습니다
• Matrix 네이티브 DM/채널 라우팅과 반응 바로가기는 exec 승인과 Plugin 승인을 모두 처리합니다; Plugin 권한 부여는 계속 channels.matrix.dm.allowFrom에서 가져옵니다
• 요청자는 승인자일 필요가 없습니다
• 시작된 채팅이 이미 명령과 응답을 지원하면 해당 원본 채팅에서 /approve로 직접 승인할 수 있습니다
• 네이티브 Discord 승인 버튼은 승인 ID 종류에 따라 라우팅합니다: plugin: ID는 곧바로 Plugin 승인으로 가고, 나머지는 모두 exec 승인으로 갑니다
• 네이티브 Telegram 승인 버튼은 /approve와 동일한 제한된 exec→Plugin 대체 경로를 따릅니다
• 네이티브 target이 원본 채팅 전달을 활성화하면 승인 프롬프트에 명령 텍스트가 포함됩니다
• 대기 중인 exec 승인은 기본적으로 30분 후 만료됩니다
• 어떤 운영자 UI 또는 구성된 승인 클라이언트도 요청을 수락할 수 없으면 프롬프트는 askFallback으로 대체됩니다

• Discord
• Telegram

​

macOS IPC 흐름

• Unix 소켓 모드 0600, 토큰은 exec-approvals.json에 저장됩니다.
• 동일 UID 피어 확인.
• 챌린지/응답(nonce + HMAC token + request hash) + 짧은 TTL.

​

시스템 이벤트

• Exec running(명령이 실행 중 알림 임계값을 초과하는 경우에만)
• Exec finished
• Exec denied

​

승인 거부 동작

​

의미

• full은 강력하므로 가능하면 allowlist를 선호하세요.
• ask는 빠른 승인을 허용하면서도 사용자를 흐름 안에 남겨 둡니다.
• 에이전트별 allowlist는 한 에이전트의 승인이 다른 에이전트로 새어 나가는 것을 방지합니다.
• 승인은 권한 있는 발신자의 호스트 실행 요청에만 적용됩니다. 권한 없는 발신자는 /exec를 실행할 수 없습니다.
• /exec security=full은 권한 있는 운영자를 위한 세션 수준 편의 기능이며 설계상 승인을 건너뜁니다. 호스트 실행을 강제로 차단하려면 승인 security를 deny로 설정하거나 도구 정책에서 exec 도구를 거부하세요.

• Exec tool
• Elevated mode
• Skills

​

관련 문서

• Exec — 셸 명령 실행 도구
• Sandboxing — 샌드박스 모드와 워크스페이스 접근
• Security — 보안 모델과 하드닝
• Sandbox vs Tool Policy vs Elevated — 각각을 언제 사용할지