처음 연 터미널이 홈 디렉터리이고, 다른 프로젝트의 운영 자격증명도 같은 셸에 있다면 `claude`부터 실행할 때가 아닙니다. 저장소 루트로 이동해 Git 상태를 보고 기본 권한 모드로 시작한 뒤, 읽을 경로와 금지할 데이터를 첫 프롬프트에 적어야 합니다. 안전 설정은 추상적인 경고가 아니라 첫 세션의 순서를 정하는 일입니다.
핵심 처음에는 읽기와 계획 권한만 열고, 변경 대상과 검증 방법이 명확해진 뒤 편집과 명령 권한을 좁게 허용하는 방식이 안전합니다. 모든 승인을 건너뛰는 설정은 별도 격리 환경이 아니면 기본값이 되어서는 안 됩니다.
설치보다 먼저 저장소 상태를 본다
현재 디렉터리, Git 브랜치와 수정 파일을 확인하지 않으면 다른 프로젝트나 사용자의 미완성 변경을 건드릴 수 있습니다. 원격 저장소와 동기화가 필요한 프로젝트라면 작업 전에 최신 상태를 가져오되, 충돌이나 로컬 변경이 있으면 자동으로 덮지 않습니다.
비밀키, 환경변수 파일, 고객 데이터와 운영 덤프는 프롬프트나 커밋에 포함하지 않습니다. 테스트에 데이터가 필요하면 식별정보를 제거한 작은 샘플을 별도로 준비합니다.
현재 권한 모드를 정확히 이해한다
공식 문서는 기본 승인 모드, 파일 편집을 자동 수락하는 모드, 읽기·분석만 가능한 계획 모드를 구분합니다. 파일 편집 승인과 부작용이 있는 셸 명령 승인은 같은 권한이 아닙니다. 작업 성격에 따라 읽기, 편집, 명령 실행을 따로 판단해야 합니다.
권한 우회 모드는 컨테이너나 일회용 작업 공간처럼 실패 범위가 제한된 환경에서만 고려합니다. 개인 컴퓨터나 운영 자격증명이 있는 셸에서 편의를 위해 켜는 것은 위험 대비 이익이 작습니다.
허용 목록은 좁고 구체적으로 만든다
테스트 실행처럼 반복적이고 복구 가능한 명령은 정확한 접두어로 허용할 수 있습니다. 반면 광범위한 셸 권한, 재귀 삭제, 원격 배포와 데이터 변경은 매번 대상과 영향을 확인하는 편이 안전합니다. 거부 규칙은 허용 규칙보다 우선하도록 설계된 현재 권한 체계를 활용합니다.
추가 디렉터리 접근도 필요한 경로만 엽니다. 홈 디렉터리 전체를 접근 대상으로 주는 방식보다 해당 저장소와 필요한 문서 폴더를 명시하는 방식이 검토하기 쉽습니다.
안전한 시작 체크리스트
작업 전에는 목표, 대상 저장소, 브랜치, 변경 허용 범위, 금지 데이터, 테스트 명령과 배포 승인자를 적습니다. 작업 후에는 변경 파일, 정적 검사, 테스트, 사용자 변경 보존과 Git 상태를 확인합니다.
에이전트가 커밋과 배포를 할 수 있더라도 자동으로 해야 한다는 뜻은 아닙니다. 되돌리기 어려운 단계일수록 결과를 먼저 보여주고 명시적 승인을 받는 절차가 필요합니다.
첫 실행에서 홈 디렉터리를 열지 않습니다
예시 세션은 프로필 저장 오류를 조사합니다. 프로젝트 루트에서 기본 권한 모드로 시작하면 읽기는 진행할 수 있지만 편집과 민감한 명령에는 승인이 필요합니다.
pwd
git status --short
claude --permission-mode default
CLAUDE.md와 README.md를 먼저 읽고 현재 브랜치와 변경 파일을 요약하세요.
그다음 src/profile과 관련 테스트만 조사하세요.
.env, 고객 데이터, 홈 디렉터리는 읽지 마세요.
아직 파일을 수정하지 말고 재현 명령과 변경 후보만 반환하세요.승인은 명령마다 영향이 다릅니다
`npm test -- profile`처럼 로컬에서 되돌릴 수 있는 테스트는 정확한 명령을 확인한 뒤 허용할 수 있습니다. 반면 `git push`, 배포 CLI, 운영 DB 접속은 같은 셸 도구라도 영향이 다르므로 이 세션에서는 거부합니다. Claude가 범위를 넘어 공통 인증 파일을 읽어야 한다고 판단하면 이유와 파일명을 먼저 반환하게 합니다.
사람이 계획을 확인한 뒤에는 "`src/profile/save.ts`와 해당 테스트만 수정하세요. 테스트 뒤 `git diff --check`와 `git diff -- src/profile tests/profile`을 보여주세요"라고 이어갑니다. 예상 결과와 다른 디렉터리가 바뀌거나 재현에 운영 계정이 필요하면 즉시 중단합니다. 목적이 보안 점검으로 바뀌면 `/rename`으로 현재 세션을 식별해 두고 새 세션을 엽니다.
다운로드 폴더에서 시작한 한 번의 실수
가상의 예시에서 신규 개발자가 압축 파일을 푼 폴더에서 도구를 실행하고 “결제 오류를 고쳐 달라”고 요청했습니다. 폴더는 Git 저장소가 아니었고 운영 환경 파일 사본과 고객 문의 내보내기가 함께 있었습니다. 계획 없이 편집을 허용했다면 변경 이력도 복구 지점도 없는 상태에서 민감한 파일을 읽을 수 있었습니다.
첫 관찰에서 Git 루트 없음, 원격 없음, 추적되지 않는 환경 파일을 확인하고 작업을 중단했습니다. 올바른 저장소를 새로 받고 개발 브랜치와 깨끗한 상태를 확인한 뒤, 고객 자료가 없는 시험 자료만 남겼습니다. 잘못된 위치에서는 파일을 하나도 바꾸지 않은 것이 첫 번째 성공 결과였습니다.
읽기에서 편집으로 권한을 넓힌 근거
가상 세션에서 계획 모드로 결제 서비스와 관련 테스트를 찾고, 수정 후보가 합의한 범위 안인지 확인합니다. 읽기와 검색은 자동 허용하되 테스트 명령은 정확한 접두어만 승인하고, 환경 파일·상위 디렉터리·원격 명령은 거부했습니다. 수정 후에는 변경 파일 목록이 합의한 범위 안인지 확인하고 비밀 파일은 접근 기록과 변경 차이 모두에 없었습니다.
처음부터 모든 권한을 건너뛰는 선택은 몇 번의 승인 질문을 줄이지만 잘못 연 폴더의 피해 범위를 컴퓨터 전체로 키울 수 있습니다. 이 사례에서는 올바른 저장소, 깨끗한 기준점, 좁은 명령 허용이 각각 관찰 가능한 안전장치로 작동했습니다.
안전 설정만으로 진행할 수 없는 경우
운영 비밀이나 고객 원문이 재현에 필요하다는 결론이 나오면 식별정보를 지운 시험 자료를 준비할 때까지 멈춥니다. 사용자 미완성 변경과 수정 파일이 겹치거나 현재 브랜치의 출처를 확인할 수 없어도 자동 정리하지 않습니다.
재귀 삭제, 운영 DB 쓰기, 커밋·푸시·배포는 읽기와 테스트의 연장이 아닙니다. 정확한 대상과 복구 방법, 사람 승인이 따로 확인되지 않으면 권한 목록에 추가하지 않습니다.
권한 모드와 샌드박스는 서로 다른 안전장치다
현재 권한 모드는 `default`, `acceptEdits`, `plan`, `auto`, `dontAsk`, `bypassPermissions`로 구분됩니다. 권한 규칙은 `deny`, `ask`, `allow` 순서로 평가되므로 넓은 허용보다 정확한 거부 경계를 먼저 두는 편이 예측하기 쉽습니다. Plan Mode는 읽기와 분석을 위한 선택이고, Auto Mode는 안전 분류기를 거쳐 일부 작업을 진행하는 별도 선택입니다.
샌드박스는 승인 화면을 대신하지 않습니다. 파일 시스템과 네트워크에서 명령이 실제로 닿을 수 있는 범위를 줄이는 장치입니다. macOS, Linux, WSL2에서 사용할 수 있고 네이티브 Windows는 지원하지 않습니다. 운영 자격증명이 있는 환경에서는 읽기 거부 경로, 쓰기 허용 경로와 허용 도메인을 따로 설정합니다.
읽고 나서 확인하기
답을 떠올린 뒤 본문의 판단 기준과 비교해 보세요.
- 저장소를 열기 전에 현재 브랜치, 기존 변경과 프로젝트 지침을 확인합니다.
- 읽기·로컬 검사는 좁게 허용하고 푸시·배포·운영 데이터 변경은 별도 승인으로 남깁니다.
- 요청 범위가 바뀌면 기존 승인을 넓혀 해석하지 않고 다시 계획합니다.