설치를 넘기고 claude를 처음 실행하면, 작업 화면이 아니라 질문 하나가 먼저 뜬다. 이 폴더의 파일을 신뢰하겠느냐고 묻는 화면이다. 여기서 습관적으로 엔터를 치면 안 된다. 우리가 실측한 화면에서는 커서가 No, exit에 놓여 있었고, 그 상태의 엔터는 신뢰가 아니라 종료를 선택했다. 도구가 켜지자마자 조용히 닫히는 것처럼 보이는 이유가 이것이다.
먼저 밝혀 둔다. 커서가 어디에 놓이는지는 사람마다 다를 수 있다. 아래 2번 항목에 우리 환경의 조건을 적었으니, 외우지 말고 자기 화면에서 직접 확인하기를 권한다. 이 글에서 공식 문서에서 확인한 내용과 우리가 직접 측정한 내용은 항목마다 구분해 표시했다.
신뢰 화면에서 멈춘 지점
- 1. 켜자마자 폴더를 신뢰하겠느냐는 화면이 떴다 (공식 문서)
- 2. 무엇을 눌러야 하는지 모르겠다 — 커서 위치를 직접 확인하라 (우리 실측)
- 3. 하나를 통과했는데 또 물어본다 (우리 실측)
- 4. 엔터를 쳤더니 그냥 닫혔다 (우리 실측 + 처방)
- 5. 켤 때마다 매번 다시 물어본다 (공식 문서)
- 6. 신뢰한다고 하면 무엇을 허용하는 것인가 (공식 문서)
- 7. 우리 시스템에서는 이것이 최다 장애였다 (우리 실측)
1. 켜자마자 폴더를 신뢰하겠느냐는 화면이 떴다
증상. 설치는 끝났고 claude를 실행했는데, 곧바로 이런 줄이 뜬다.
Do you trust the files in this folder?
왜 그런가. 고장이 아니라 설계다. 공식 보안 문서에 이 절차가 적혀 있다. 문서는 안전장치 목록에서 Trust verification을 이렇게 설명한다. “First-time codebase runs and new MCP servers require trust verification.” 처음 여는 코드베이스와 새로 붙이는 MCP 서버는 신뢰 확인을 거친다는 뜻이다.
즉 이 화면은 그 폴더에서 처음 실행할 때 한 번 물어보는 관문이다. 놀랄 일이 아니고, 답을 하면 지나간다.
확인 명령. 지금 어느 폴더에서 켰는지부터 본다. 질문의 대상이 그 폴더다.
pwd
확인 방법. 답을 하고 나면 평소의 입력 프롬프트가 나온다. 화면이 작업 상태로 넘어가면 관문을 지난 것이다.
2. 무엇을 눌러야 하는지 모르겠다 — 커서 위치를 직접 확인하라
이 항목은 우리가 직접 측정한 것이다. 공식 문서에는 이 화면의 항목 순서나 커서 기본값이 적혀 있지 않다.
증상. 화면에 선택 항목이 두 개 있는데 어느 쪽이 선택된 상태인지 눈에 잘 들어오지 않는다. 보통은 엔터가 안전한 쪽에 놓여 있다고 기대한다.
우리가 측정한 것. 2026년 9월 8일, 우리 작업 폴더에서 여러 좌석을 기동하면서 화면을 그대로 읽었다. 커서는 No, exit에 놓여 있었고, 그 아래에 Yes, I trust this folder 항목이 있었다. 우리 작업 기록에는 그 절차가 이렇게 남아 있다. 화면을 읽어 커서가 No, exit에 있는 것을 확인하고, 아래로 옮겨 Yes, I trust this folder에 커서가 있는 것을 다시 확인한 뒤 확정했다. 맹목적으로 엔터를 치지 않았다.
중요한 조건 — 이것은 우리 환경의 배치다. 우리 작업 폴더의 설정 파일에는 도구 권한 두 건이 미리 허용돼 있었다. 실제 값은 다음 두 줄이다.
"permissions": { "allow": [ "Bash(cys send-key:*)", "Bash(cys read-screen:*)" ] }
우리는 이 사전 허용이 있는 폴더에서 위 배치를 봤다. 다만 사전 허용이 커서 기본값을 그렇게 만든 원인인지는 우리가 프로그램 코드로 확인한 것이 아니다. 조건과 관찰을 함께 적어 두는 것이 정확하다. 그러니 사전 허용이 없는 폴더에서는 기본값이 다를 수 있다.
처방. 기본값을 외우지 마라. 화면에서 지금 커서가 어느 항목에 있는지 보고, 신뢰하겠다는 항목으로 옮긴 뒤 확정한다. 방향키 위아래로 옮기고, 항목 앞의 표시가 옮겨간 것을 눈으로 확인한 다음 엔터를 누른다. 순서를 지키면 기본값이 무엇이든 안전하다.
확인 방법. 확정한 뒤 화면이 입력 프롬프트로 넘어가는지 본다. 창이 닫히면 종료 쪽을 누른 것이니 다시 켜서 4번 항목대로 하면 된다.
덧붙이면, 항목 문면은 도구마다 다르다. 우리가 같은 컴퓨터에서 측정한 다른 CLI 는 항목이 1. Yes, continue와 2. No, quit 두 개였다. 라벨을 외워 두고 위치로 누르는 습관이 위험한 이유다.
3. 하나를 통과했는데 또 물어본다
이 항목도 우리 실측이다.
증상. 폴더 신뢰에 답했는데 화면이 작업 상태로 가지 않고 비슷한 선택 화면이 한 번 더 뜬다.
우리가 측정한 것. 관문은 하나가 아니었다. 우리 기록에는 한 좌석을 기동하면서 폴더 신뢰 관문과 Bypass Permissions 면책 관문 두 건을 연달아 통과시킨 것으로 남아 있다. 그리고 우리 어댑터 설정 파일의 설명문에는, 통과 직후 화면을 다시 관문으로 잘못 읽으면 그 다음 엔터가 면책 창의 No, exit를 누른다는 사고 형태가 적혀 있다. 즉 두 번째 창에서도 엔터가 종료 쪽일 수 있다.
처방. 한 번 통과했다고 방심하지 말고, 두 번째 화면에서도 커서 위치를 같은 방식으로 확인한다. 두 화면은 묻는 내용이 다르다. 첫 번째는 이 폴더를 신뢰하겠느냐이고, 두 번째는 권한 확인을 건너뛰는 모드에 대한 면책이다.
확인 방법. 두 화면을 모두 지나면 입력 프롬프트가 나온다. 중간에서 닫히면 두 번째 창에서 종료를 누른 것이다.
4. 엔터를 쳤더니 그냥 닫혔다
증상. 무언가 눌렀는데 도구가 종료됐다. 오류 메시지도 없다. 설치가 잘못된 것처럼 느껴진다.
왜 그런가. 종료 항목이 선택된 상태에서 확정했기 때문이다. 우리 실측 기준으로 그 항목의 라벨이 No, exit다. 이름 그대로 신뢰하지 않고 나가는 선택이다. 설치나 로그인이 깨진 것이 아니다.
처방. 다시 켜면 된다. 신뢰 질문은 답을 하지 않은 상태로 남아 있으므로 같은 화면이 다시 뜬다. 이번에는 2번 항목의 순서대로 커서를 옮겨 확정한다.
claude
확인 방법. 우리 기록에서는 관문을 통과한 좌석에 온보딩 완료 표시가 남아 재기동 때 다시 막히지 않았다. 우리 환경에서 확인한 값은 hasCompletedOnboarding=true였다. 다시 켰을 때 이 화면이 더 나오지 않으면 통과가 저장된 것이다. 매번 다시 물어보는 경우는 5번 항목을 보라.
5. 켤 때마다 매번 다시 물어본다
증상. 분명히 신뢰한다고 답했는데 다음에 켜면 또 묻는다.
왜 그런가. 공식 보안 문서가 이 상황을 직접 설명한다. 홈 디렉터리에서 바로 실행한 경우다. 문서 표현은 이렇다. “When you start Claude Code directly in your home directory, trust acceptance is held for the current session only and is not written to disk, so the prompt reappears on each launch. There is no setting to persist it. Start Claude Code from a project subdirectory instead, where trust acceptance is saved per directory.”
정리하면, 홈 디렉터리에서 켜면 신뢰 승인이 그 세션에만 유지되고 디스크에 기록되지 않아 켤 때마다 다시 묻는다. 이를 유지시키는 설정은 없다고 문서가 명시한다. 대신 프로젝트 하위 폴더에서 켜면 폴더 단위로 저장된다.
확인 명령. 지금 위치가 홈 디렉터리인지 본다. 아래 두 값이 같으면 홈에서 켠 것이다.
pwd
echo $HOME
처방. 작업할 프로젝트 폴더를 만들고 그 안에서 켠다.
mkdir my-project
cd my-project
claude
확인 방법. 그 폴더에서 한 번 신뢰한 뒤 도구를 닫고 다시 켠다. 같은 폴더에서 질문이 다시 뜨지 않으면 저장된 것이다.
참고로 같은 문서는 비대화형 실행에 대해서도 적어 두었다. “Trust verification is disabled when running non-interactively with the -p flag.” 즉 -p 옵션으로 비대화형으로 돌릴 때는 이 확인 절차가 동작하지 않는다.
6. 신뢰한다고 하면 무엇을 허용하는 것인가
증상. 신뢰하겠다고 누르기가 망설여진다. 무엇을 허락하는 것인지 모르겠다.
공식 문서가 말하는 범위. 신뢰가 곧 모든 권한을 주는 것은 아니다. 문서는 기본 동작을 이렇게 설명한다. 수동 모드에서 Claude Code 는 읽기 전용 권한으로 시작하고, 파일을 고치거나 명령을 실행해야 할 때 사람에게 먼저 물어본다. 원문은 “In Manual mode, Claude Code starts with read-only permissions. When Claude Code needs to edit files, run tests, or execute commands, it asks you first, and you choose whether to approve the action once or allow it from then on.”
작업 범위에도 경계가 있다. 문서 설명으로 수동 모드에서는 실행한 폴더와 그 하위 폴더에만 쓸 수 있고, 상위 폴더의 파일은 명시적 허락 없이 고치지 못한다. 원문은 “In Manual mode, Claude Code can only write to the folder where it was started and its subfolders, and can’t modify files in parent directories without explicit permission.”
문서는 책임 소재도 분명히 적는다. “Claude Code only has the permissions you grant it. You’re responsible for reviewing proposed code and commands for safety before approval.”
처방. 내가 만든 프로젝트 폴더라면 신뢰해도 된다. 내려받은 남의 코드나 출처가 불확실한 폴더라면, 그 폴더에서 켜기 전에 내용을 먼저 살펴보는 편이 낫다. 신뢰 질문은 그 판단을 사람에게 넘기는 지점이다.
확인 방법. 통과한 뒤에도 파일을 고치는 작업에서 확인을 물어오는지 본다. 물어온다면 수동 모드의 기본 동작이 살아 있는 것이다.
7. 우리 시스템에서는 이것이 최다 장애였다
여기서부터는 여러 대의 에이전트를 동시에 돌리는 우리 운영 환경의 이야기다. 혼자 도구를 쓰는 독자에게 그대로 적용되는 내용은 아니지만, 이 관문을 가볍게 보면 어떤 일이 생기는지 보여주는 실제 기록이다.
빈도. 우리 승인 원장을 전수로 집계했다. 2026-09-08 시점에 원장 항목은 82건이었고, 그 가운데 첫 실행 관문 감지가 first_run_gate 24건으로 가장 많았다. 두 번째는 부트스트랩 실패 20건, 세 번째는 승인 대기 18건이었다. 우리 시스템에서 가장 자주 발생한 항목이 바로 이 관문이다.
실제로 벌어진 일. 기록에 남은 형상은 이렇다. 한 좌석은 관문 화면에서 답을 받지 못해 계속 대기했다. 다른 좌석은 로그를 한 줄도 남기지 않고 사라졌다. 부서장 좌석은 첫 기동에서 관문 두 건을 통과해야 했다. 다른 부서의 검토 좌석에서도 같은 형상이 나왔다. 통과는 사람이 화면을 읽고 커서를 옮겨 손으로 처리했다.
자동으로 통과시키는 장치가 있었는데 멈춰 있었다. 우리는 이 관문을 자동 확인하는 설정을 갖고 있다. 그런데 그 설정에는 안전장치가 붙어 있다. 어댑터 설정 파일 agents.json의 설명문에 계약이 적혀 있고, 문면은 이렇다. measured_on은 이 선언을 실측한 claude 버전이며, 정본과 다르면 그 관문의 통과 액션은 보류되고 감지만 한다.
실제 값을 나란히 놓으면 이렇다.
agents.json claude.first_run_gates.measured_on = 2.1.241
설치본 claude --version = 2.1.263 (Claude Code)
agents.json claude.first_run_gates.gates = [] (override 선언 없음)
선언을 실측한 버전과 설치된 버전이 달랐다. 계약대로 통과 액션은 보류되고 감지만 이뤄졌다. 그래서 자동 통과 장치가 있는데도 좌석들이 관문 앞에 멈춰 섰다. 같은 파일에서 다른 CLI 는 measured_on 선언 자체가 없었고, 그 설치본은 codex-cli 0.153.4였다.
이 대비가 이 글에서 가장 값진 대목이라고 생각한다. 안전장치는 제 계약대로 정확히 동작했다. 버전이 다르면 섣불리 자동 응답하지 않는다는 규칙을 지킨 것이다. 문제는 그 보류 상태를 사람이 모르고 있었다는 데 있었다.
부수 결함 하나. 관문을 통과한 뒤에도 우리 데몬의 보류 표시가 남아 있었다. 그 표시를 지우는 별도 명령은 없고, 우리가 시도한 해소법은 듣지 않았다. 상태 신고 명령은 상태만 신고하고 관문 표시를 지우지는 않는다. 다만 정직하게 덧붙이면, 우리 점검기는 이후 각성 시각을 먼저 보도록 바뀌어서 표시가 남아 있어도 생존 판정이 틀리지 않게 됐다. 그래도 원칙은 그대로다. 화면을 직접 읽은 결과가 판정의 정본이다.
정리 — 확인할 것 네 가지
첫째, 이 화면은 고장이 아니다. 공식 문서에 적힌 첫 실행 신뢰 확인 절차다. 둘째, 기본값을 외우지 말고 지금 커서가 어느 항목에 있는지 화면에서 직접 본다. 우리 환경에서는 그 자리가 종료 쪽이었다. 셋째, 관문이 한 번에 끝나지 않을 수 있으니 두 번째 화면에서도 같은 확인을 한다. 넷째, 매번 다시 묻는다면 홈 디렉터리에서 켠 경우이니 프로젝트 폴더를 만들어 그 안에서 켠다.
습관 하나만 바꾸면 된다. 선택 화면에서 엔터를 먼저 치지 말고, 커서를 먼저 보는 것이다. 우리는 이 한 가지를 몰라서 가장 많은 장애를 만들었다.
어디까지 공식 문서이고 어디부터 우리 실측인가
공식 문서에서 인용한 것
- Claude Code 공식 문서, 보안: https://code.claude.com/docs/en/security — 첫 실행 신뢰 확인(Trust verification), 홈 디렉터리에서 신뢰가 저장되지 않는 동작과 프로젝트 하위 폴더 권장,
-p비대화형 실행에서 신뢰 확인이 동작하지 않는다는 설명, 수동 모드의 읽기 전용 시작과 작업 폴더 경계, 권한에 대한 사용자 책임
공식 문서는 이 관문이 존재하는 이유와 저장 규칙까지는 설명하지만, 선택 항목의 순서나 커서 기본값은 적지 않는다. 그 부분은 아래의 우리 실측이다.
우리가 직접 측정한 것 (2026-09-08, 공식 문서의 내용이 아니다)
- 커서 기본값이
No, exit였고 아래 항목이Yes, I trust this folder였다는 것. 우리 작업 폴더에는 도구 권한 두 건이 미리 허용돼 있었다는 조건을 함께 밝힌다. 그 사전 허용이 커서 배치의 원인인지는 코드로 확인하지 않았다 - 폴더 신뢰 다음에
Bypass Permissions면책 관문이 한 번 더 뜨고, 그 창에서도 엔터가 종료 쪽일 수 있다는 것 - 승인 원장 82건 중
first_run_gate가 24건으로 최다였다는 집계 agents.json의measured_on계약 문면과, 그 값2.1.241이 설치본2.1.263과 달라 자동 통과가 보류된 상태였다는 것.gates는 빈 배열이었다- 관문 통과 뒤에도 데몬의 보류 표시가 남고 지우는 명령이 없다는 것. 다만 점검기가 각성 시각을 우선하도록 바뀌어 생존 판정에는 영향이 없다는 정정까지 함께 적는다
커서 기본값은 환경에 따라 다를 수 있다. 이 글의 실측값을 자기 화면의 기본값으로 가정하지 말고, 화면을 직접 읽고 확정하기를 권한다.
