​

Exec 승인

​

적용 위치

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

• Gateway 인증을 통과한 호출자는 해당 Gateway의 신뢰된 운영자입니다.
• 페어링된 노드는 그 신뢰된 운영자 권한을 node host까지 확장합니다.
• Exec 승인은 우발적인 실행 위험을 줄여 주지만, 사용자별 인증 경계는 아닙니다.
• 승인된 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 config의 요청된 exec 정책(tools.exec.*)
• 호스트 로컬 승인 정책(~/.openclaw/exec-approvals.json)

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

• tools.exec.host=auto는 exec가 어디에서 실행될지 선택합니다: 가능한 경우 샌드박스, 아니면 gateway.
• YOLO는 호스트 exec 승인 방식을 선택합니다: security=full + ask=off.
• auto는 샌드박스된 세션에서 gateway 라우팅을 자유롭게 우회할 수 있게 만들지 않습니다. 호출별 host=node 요청은 auto에서 허용되며, host=gateway는 샌드박스 런타임이 활성 상태가 아닐 때만 auto에서 허용됩니다. 안정적인 non-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 approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

• /exec security=full ask=off는 현재 세션만 변경합니다.
• /elevated full은 해당 세션의 exec 승인도 건너뛰는 비상용 단축키입니다.

​

정책 조절 항목

​

Security (exec.security)

• deny: 모든 호스트 exec 요청 차단.
• allowlist: allowlist에 있는 명령만 허용.
• full: 모든 것 허용(elevated와 동일).

​

Ask (exec.ask)

• off: 절대 프롬프트 표시 안 함.
• on-miss: allowlist가 일치하지 않을 때만 프롬프트 표시.
• always: 모든 명령에 대해 프롬프트 표시.
• 실효 ask 모드가 always이면 allow-always의 지속 신뢰도 프롬프트를 억제하지 못합니다.

​

Ask fallback (askFallback)

• deny: 차단.
• allowlist: 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는 이들에 대해 새 allowlist 항목을 자동으로 지속 저장하지 않습니다.

​

Allowlist (agent별)

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

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

​

Skill CLI 자동 허용

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

​

안전한 바이너리(safe bins, 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는 config에서 가져옵니다(tools.exec.safeBins 또는 agent별 agents.list[].tools.exec.safeBins).
• safeBinTrustedDirs는 config에서 가져옵니다(tools.exec.safeBinTrustedDirs 또는 agent별 agents.list[].tools.exec.safeBinTrustedDirs).
• safeBinProfiles는 config에서 가져옵니다(tools.exec.safeBinProfiles 또는 agent별 agents.list[].tools.exec.safeBinProfiles). agent별 프로필 키가 전역 키를 재정의합니다.
• allowlist 항목은 호스트 로컬 ~/.openclaw/exec-approvals.json의 agents.<id>.allowlist 아래에 있습니다(또는 Control UI / openclaw approvals allowlist ...를 통해 관리).
• openclaw security audit는 인터프리터/런타임 바이너리가 명시적 프로필 없이 safeBins에 나타나면 tools.exec.safe_bins_interpreter_unprofiled 경고를 표시합니다.
• openclaw doctor --fix는 누락된 사용자 지정 safeBinProfiles.<bin> 항목을 {}로 스캐폴드할 수 있습니다(이후 검토 및 강화 필요). 인터프리터/런타임 바이너리는 자동 스캐폴드되지 않습니다.

​

Control UI 편집

​

승인 흐름

• node exec 경로는 먼저 하나의 정규화된 계획을 준비합니다
• 승인 레코드는 그 계획과 해당 바인딩 메타데이터를 저장합니다
• 승인되면 최종 전달되는 system.run 호출은 이후 호출자 수정 내용을 신뢰하지 않고 저장된 계획을 재사용합니다
• 승인 요청이 생성된 후 호출자가 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가 활성화되어 있고 해석 가능한 외부 채널이 없으면 전달은 실패 대신 세션 전용으로 강등됩니다.

• command + args
• cwd
• agent id
• 해석된 실행 파일 경로
• host + 정책 메타데이터

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

​

채팅 채널로의 승인 전달

​

Plugin 승인 전달

​

모든 채널에서 같은 채팅으로 승인

​

네이티브 승인 전달

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

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

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

• Slack, Matrix, Microsoft Teams 및 유사한 전달 가능한 채팅은 same-chat /approve에 대해 일반 채널 auth 모델을 사용합니다
• 네이티브 승인 클라이언트가 자동 활성화되면 기본 네이티브 전달 대상은 approver DM입니다
• Discord 및 Telegram에서는 해석된 approver만 승인 또는 거부할 수 있습니다
• Discord approver는 명시적(execApprovals.approvers)이거나 commands.ownerAllowFrom에서 추론될 수 있습니다
• Telegram approver는 명시적(execApprovals.approvers)이거나 기존 owner config(allowFrom, 그리고 지원되는 경우 direct-message defaultTo)에서 추론될 수 있습니다
• Slack approver는 명시적(execApprovals.approvers)이거나 commands.ownerAllowFrom에서 추론될 수 있습니다
• Slack 네이티브 버튼은 승인 id 종류를 보존하므로 plugin: id가 두 번째 Slack 로컬 fallback 계층 없이 plugin 승인을 해석할 수 있습니다
• Matrix 네이티브 DM/채널 라우팅은 exec 전용이며, Matrix plugin 승인은 공유 same-chat /approve와 선택적 approvals.plugin 전달 경로에 머뭅니다
• 요청자는 approver일 필요가 없습니다
• 원래 채팅이 이미 명령과 응답을 지원하면 /approve로 직접 승인할 수 있습니다
• 네이티브 Discord 승인 버튼은 승인 id 종류에 따라 라우팅됩니다: plugin: id는 바로 plugin 승인으로 가고, 그 외는 모두 exec 승인으로 갑니다
• 네이티브 Telegram 승인 버튼은 /approve와 동일한 제한된 exec→plugin fallback을 따릅니다
• 네이티브 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는 빠른 승인을 허용하면서도 사용자를 루프 안에 유지합니다.
• agent별 allowlist는 한 agent의 승인이 다른 agent로 새어나가는 것을 방지합니다.
• 승인은 권한 있는 발신자의 호스트 exec 요청에만 적용됩니다. 권한 없는 발신자는 /exec를 실행할 수 없습니다.
• /exec security=full은 권한 있는 운영자를 위한 세션 수준 편의 기능이며 설계상 승인을 건너뜁니다. 호스트 exec를 강제로 차단하려면 승인 security를 deny로 설정하거나 tool 정책을 통해 exec tool을 거부하세요.

• Exec 도구
• Elevated mode
• Skills

​

관련

• Exec — 셸 명령 실행 도구
• 샌드박싱 — 샌드박스 모드 및 workspace 액세스
• 보안 — 보안 모델 및 하드닝
• 샌드박스 vs Tool 정책 vs Elevated — 각각을 언제 사용할지