기본 패턴
toml
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = true설명
- 샌드박스는 "어디까지 할 수 있는가"를 정합니다. 승인 정책은 "그 행동 전에 사용자에게 물어볼 것인가"를 정합니다.
- 로컬 CLI와 IDE 기본값은 보수적이며, 공식 문서는 기본적으로 네트워크가 꺼져 있고 쓰기 권한도 작업 공간 안으로 제한된다고 설명합니다.
read-only는 읽기 중심 대화와 계획에 적합하고,workspace-write는 저장소 안 수정과 테스트에 적합하며, 전체 권한은 꼭 필요한 경우만 써야 합니다.approval_policy = "on-request"는 실행 전 확인을 거치게 만들고,never는 승인 없이 계속 진행하게 만듭니다.- 세션 중에는
/permissions로 권한 수준을 바꿀 수 있으며, 공식 가이드는 보통 가장 좁은 권한에서 시작해 점진적으로 넓히는 방식을 권합니다.
짧은 예제
text
상황별 선택
- 코드 설명만 듣고 싶다 -> read-only
- 저장소 안 파일 수정과 테스트는 필요하다 -> workspace-write
- 네트워크 접근도 필요하다 -> workspace-write + 명시적 network_access
- 무인 자동화라 승인 대화가 없어야 한다 -> 정책 검토 후 never빠른 정리
| 항목 | 의미 |
|---|---|
sandbox_mode | 기술적으로 허용된 파일/명령/네트워크 범위 |
approval_policy | 실행 전에 사용자 승인 여부 |
read-only | 수정 없이 읽기와 계획 중심 |
workspace-write | 작업 공간 안 수정과 검증 가능 |
/permissions | 세션 중 권한 프리셋 전환 |
주의할 점
승인 정책만 좁히고 샌드박스를 넓게 열면 생각보다 강한 권한이 남을 수 있습니다. 반대로 샌드박스만 좁히고 승인 정책을 풀어도 필요한 작업이 계속 실패합니다. 두 축을 항상 같이 봐야 안전합니다.
참고 링크
3 sources