권한 요청에 답하기

CLI가 무언가를 해도 되는지 물어오면, 응답자가 결정합니다.

command.onPermission((request) => {
  if (request.subtype === 'can_use_tool') return request.approve();
  return request.deny('user declined');
});

응답은 요청 위에서 만들어집니다. 응답이란 그것이 답하는 request_id와 짝지어질 때에만 의미를 갖고, 그 id는 요청과 함께 도착했기 때문입니다.

제안된 내용 수정하기

호스트는 CLI가 제안한 것을 허용하기 전에 편집할 수도 있습니다. UI가 사용자에게 명령을 실행 전에 고칠 기회를 주는 방식이 바로 이것입니다.

command.onPermission((request) => request.approve({ command: 'ls -la' }));

null을 반환하면 요청이 답 없이 남아 CLI가 멈춰 섭니다. 다른 무언가가 그 요청에 답할 예정일 때에만 그렇게 하세요.

봉투는 두 겹으로 중첩되어 있습니다

CLI에 도달하는 페이로드는 두 겹으로 중첩되어 있고, 그래야만 합니다. 바깥쪽 response는 전달 봉투로서 — 응답이 만들어졌다는 사실과 그것이 어느 요청에 답하는지를 담고 — 안쪽이 결정 자체를 실어 나릅니다.

{
  "type": "control_response",
  "response": {
    "subtype": "success",
    "request_id": "req-7",
    "response": { "behavior": "allow", "updatedInput": { "command": "ls -la" } }
  }
}

위험

이 두 겹을 평평하게 만들면 CLI는 아무 불평 없이 받아들인 다음, error_during_execution으로 턴을 실패시킵니다. 이유를 말해주는 것은 어디에도 없습니다. 응답은 직접 만들지 말고 approve() / deny()로 만드세요.

deny()가 reason을 받는 이유

참고

거부는 사용자의 결정이지 도구의 실패가 아닙니다. CLI는 그 메시지를 도구 결과로 바꾸는데, 호스트가 따로 표시하지 않으면 그 자리에서는 에러처럼 읽힙니다. deny()에 reason을 넘겨야 그 구분이 저장되고 다시 불러온 뒤에도 살아남습니다.

다음으로 볼 것

• 권한 모드 — 다섯 가지 모드, 그리고 모드 변경이 재spawn인 이유.
• 레퍼런스: 이벤트 — PermissionRequestEvent 전체.