# Claude Code 2.1.268: deny 규칙과 MCP에서 수정된 사항

> Claude Code 2.1.268–2.1.269에서 권한 문제 4건과 /mcp의 비밀 정보 노출 문제가 수정되었습니다. 영향받는 사용자, 업데이트 방법, 규칙 확인 방법을 알아봅니다.

Source: https://ailoot.ai/blog/ko/claude-code-2-1-268-fixes/
Canonical: https://ailoot.ai/blog/ko/claude-code-2-1-268-fixes/
Language: ko
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-040
Revision: sha256-b550d82e9d66d8618f407874e727fe17d3436ad7a1178acf3a25492a42b01db4


Claude Code 버전 2.1.268은 2026년 9월 10일에 출시되었고, 다음 날 2.1.269가 출시되었습니다. 바로 업데이트해야 합니다. 두 가지 경우에 에이전트가 `.env` 및 서비스 폴더에 접근하지 못하도록 사용하는 deny 규칙이 아무런 알림 없이 적용되지 않았습니다. 또한 `/mcp` 명령이 터미널에 설정 파일의 비밀 정보를 출력할 수 있었습니다.

아래 내용은 원문 자료 작성일인 2026년 9월 17일 당시의 Anthropic 공식 변경 로그와 문서를 바탕으로 합니다. 그 날짜 기준 최신 버전은 2.1.274였습니다. 해당 항목을 바탕으로 오류가 어떻게 작동했는지 설명합니다. 취약한 버전에서 우회가 재현되지는 않았습니다.

Ailoot 사용에 관한 추가 지침은 [문서](https://ailoot.ai/docs/)를 참조하세요.



## Claude Code 2.1.268 및 2.1.269에서 무엇이 수정되었나요?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="섹션 핵심 내용">

핵심 내용

권한 문제가 네 건 수정되었습니다. symlink 경로에서는 deny 및 ask 규칙이 작동하지 않았고, `env -C` 또는 `eval`이 포함된 줄에서는 Read 또는 Edit에 대한 deny가 적용되지 않을 수 있었습니다. “!”가 포함된 규칙은 해당 설정 파일의 범위를 넘어 적용되었습니다. `tee` 명령은 Edit에 대한 deny로 차단되지 않은 채 파일을 기록했습니다. 또한 `/mcp`와 `claude mcp list`가 설정 파일의 비밀 정보를 표시했고, 플러그인 오류는 Git URL의 토큰을 표시했습니다.

</div>

권한 규칙과 관련된 수정은 네 가지입니다.

1.  **symlink 경로에 대한 차단이 작동하지 않았습니다.** symlink가 가리키는 디렉터리(`/etc`, `/tmp`, macOS의 `/var`, Linux의 `/bin`)를 대상으로 작성한 deny 및 ask 규칙은 실제 경로를 지정하면 실행되지 않았습니다. Bash 명령도 symlink를 통한 경로에 작성된 deny 규칙을 무시했습니다.
2.  **`env -C` 또는 `eval`과 함께 사용하면 읽기와 편집 차단이 실패했습니다.** 같은 명령 줄에 권한 검사기가 해석할 수 없는 구문이 있으면 Read 또는 Edit에 대한 deny가 적용되지 않을 수 있었습니다.
3.  **“!”가 포함된 규칙이 의도한 범위보다 넓게 적용되었습니다.** `!`로 시작하는 deny 또는 ask 규칙은 해당 규칙이 작성된 설정 파일의 범위를 넘어 적용되었습니다. 이제 해당 규칙이 작성된 파일 안에서만 적용되며, 단독 부정 기호 `!`는 무시됩니다.
4.  **`tee`가 차단을 우회해 파일을 기록했습니다.** `Edit()`에 대한 deny 규칙과 쓰기 경로 검사는 Bash `tee` 명령으로 만든 파일에 적용되지 않았습니다. `Bash(tee:*)` 권한은 이제 작업 디렉터리 밖의 쓰기를 허용하지 않습니다.

이 버전들에서는 비밀 정보 노출과 관련된 문제 두 가지도 수정되었습니다. WebFetch는 연결을 열린 상태로 유지하는 서버의 응답을 무기한 기다리지 않습니다. 이제 요청은 300초 후 실패하며, `CLAUDE_CODE_WEBFETCH_DEADLINE_MS` 변수로 시간 제한을 설정할 수 있습니다. 장시간 유휴 세션에서 지속적으로 높았던 CPU 사용량도 제거되었습니다.

## Claude Code에서 차단 규칙은 어떻게 작동하나요?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="섹션 핵심 내용">

핵심 내용

규칙은 `settings.json`의 `permissions` 블록에 작성합니다. deny는 차단하고, ask는 확인을 요청하며, allow는 확인 없이 작업을 허용합니다. 검사는 deny, ask, allow 순서로 진행됩니다. 규칙 형식은 `Tool` 또는 `Tool(detail)`입니다. 예를 들면 `Read(./.env)`입니다.

</div>

Claude Code에는 세 가지 규칙 목록이 있습니다. **deny**(항상 금지), **ask**(작업 전에 확인 요청), **allow**(확인 없이 허용)입니다. 에이전트가 작업을 수행하려 할 때 규칙은 엄격히 이 순서대로 검사됩니다. 일치하는 deny 규칙은 같은 작업에 대한 모든 allow 규칙보다 우선합니다. 허용 규칙은 차단 예외를 만들 수 없습니다.

규칙은 세 위치에 저장됩니다. 사용자 규칙은 `~/.claude/settings.json`, 프로젝트 규칙은 저장소 안의 `.claude/settings.json`, 로컬 규칙은 `.claude/settings.local.json`에 저장됩니다. 키가 들어 있는 파일을 읽지 못하게 하는 설정의 예시는 다음과 같습니다.

```json
{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(rm *)"
    ]
  }
}
```

세션에서 `/permissions`를 실행하면 활성 규칙과 각 규칙의 출처 파일을 모두 확인할 수 있습니다. 읽기를 차단하는 규칙이 있으면 차단 메시지에 해당 규칙이 표시되므로 아래 점검에 유용합니다.



## 어떤 오류가 차단 규칙과 규칙의 적용 범위에 영향을 주었나요?

오류는 경로 및 명령 검사와 여러 설정 파일에 작성된 규칙의 적용 범위에 영향을 주었습니다.

**첫 번째 사례: symlink.** macOS에서 `/etc`, `/tmp`, `/var`는 `/private` 아래의 실제 폴더를 가리키는 symlink입니다. Linux에서는 `/bin`이 흔히 비슷한 symlink입니다. 한 가지 경로 표기에 대해 deny 규칙을 작성했지만 에이전트가 다른 표기(예: symlink 대신 실제 경로)를 사용해 접근하면 규칙이 실행되지 않았습니다. Bash 명령도 symlink를 통한 경로에 작성된 차단 규칙을 무시했습니다. 2.1.268에서 두 사례가 모두 수정되어 이제 경로 표기와 관계없이 규칙이 적용됩니다.

**두 번째 사례: 한 줄에 함께 있는 `env -C`와 `eval`.** 권한 검사는 명령을 해석해 접근할 파일을 파악합니다. `env -C` 또는 `eval` 같은 구문은 해석할 수 없습니다. 문제는 이런 구문이 줄에 있으면 Read 또는 Edit에 대한 deny가 적용되지 않을 수 있었다는 점입니다. 그 결과 명령이 보호된 파일의 읽기 또는 편집 차단을 우회할 수 있었습니다.

**세 번째 사례: “!”가 포함된 규칙이 범위를 넘어 적용됨.** `!`로 시작하는 규칙은 해당 규칙이 작성된 설정 파일 안에서만 적용되어야 합니다. 2.1.269 이전에는 다른 설정 출처에도 적용되었습니다. 이제 규칙의 범위는 해당 파일로 제한되며, 단독 `!`로 이루어진 규칙은 무시됩니다.

**네 번째 사례: `tee`를 통한 쓰기.** Bash `tee` 명령은 파일에 쓸 수 있습니다. 쓰기 경로 검사와 `Edit()` deny 규칙은 그 파일에 적용되지 않았습니다. 동시에 `Bash(tee:*)` 권한은 작업 디렉터리 밖의 쓰기를 허용했습니다. 2.1.269에서는 `tee`를 통한 쓰기에도 이러한 검사가 적용되기 시작했습니다. 해당 파일에 대한 차단이 적용되고, `Bash(tee:*)`는 작업 디렉터리 안에서만 쓰기를 허용합니다.

`.env`, 몇몇 서비스 폴더 또는 위험한 명령을 차단하는 등 특정 대상을 지정한 차단 규칙을 사용한다면 그 규칙도 확인해야 합니다. 방법은 아래에 나와 있습니다.

## `/mcp`에서 키가 표시될 수 있었던 이유는 무엇인가요?

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="섹션 핵심 내용">

핵심 내용

MCP 설정의 키는 흔히 `${VAR}` 변수를 통해 전달됩니다. `/mcp`, `/plugin`, `claude mcp list`, `claude mcp get` 명령과 MCP 로그인 오류는 치환된 값, 즉 키 자체를 표시했습니다. 2.1.268에서는 출력이 마스킹됩니다.

</div>

MCP 서버 설정에서는 흔히 환경 변수에 키를 저장하고 `${VAR}`를 통해 참조합니다. 이렇게 하면 비밀 정보를 파일에 넣지 않고도 저장소에 파일을 보관할 수 있습니다. 문제는 조회 명령(`/mcp`, `/plugin`, `claude mcp list`, `claude mcp get`)과 MCP 로그인 오류 메시지가 값이 이미 치환된 설정 내용을 표시했다는 점입니다. 키 자체가 화면에 나타났습니다.

또 다른 수정 사항은 플러그인 및 마켓플레이스 오류와 관련이 있습니다. 오류에 원본 Git URL의 토큰이나 비밀번호가 표시될 수 있었습니다.

이전 버전의 `/mcp` 또는 `claude mcp list` 출력이 스트리밍, 스크린샷, 동료에게 보낸 메시지 또는 컴퓨터 밖으로 나간 로그에 나타났다면, 자동으로 전송된 경우도 포함해 MCP 설정의 키가 노출되었다고 보고 키를 교체하세요. 출력이 컴퓨터 밖으로 나간 적이 없다면 업데이트만 하면 됩니다. MCP 서버와 바로 사용할 수 있는 설정에 관한 별도 가이드도 있습니다. [Claude Code MCP 서버](https://ailoot.ai/blog/ko/mcp-servers-claude-code/)를 참조하세요.

## 이 버전들의 다른 변경 사항

**WebFetch와 아티팩트.** 이전에는 deny 또는 ask에 세부 조건이 없는 `WebFetch` 규칙이 게시된 아티팩트의 읽기와 수정에도 적용되었습니다. 2.1.268부터는 더 이상 아티팩트에 적용되지 않습니다. 아티팩트를 차단하려면 별도의 `Artifact` 규칙이나 `WebFetch(domain:claude.ai)` 같은 도메인 규칙이 필요합니다. 아티팩트 읽기를 막기 위해 일반 WebFetch 차단 규칙에 의존했다면 설정을 다시 확인하세요. 이전 규칙은 더 이상 이 작업을 차단하지 않습니다.

**WebFetch에 시간 제한이 추가되었습니다.** 연결을 열린 채로 유지하고 응답을 끝내지 않는 서버에 대한 요청은 이제 300초 후 실패합니다. 이전에는 이런 요청이 무기한 멈춰 있을 수 있었습니다. `CLAUDE_CODE_WEBFETCH_DEADLINE_MS` 변수로 동작을 설정할 수 있으며, 값을 0으로 설정하면 시간 제한이 비활성화됩니다.

**유휴 세션에서 지속적으로 높던 CPU 사용량이 제거되었습니다.** 장시간 유휴 세션에서 Claude Code의 유휴 루프가 CPU 사용량을 지속적으로 높일 수 있었습니다. 이 버그는 2.1.268에서 수정되었습니다. 세션을 하루 종일 열어 두는 사용자에게도 영향을 줄 수 있었습니다.

**최신 버전을 설치하세요.** 2.1.269에서 새로운 버그가 나타났습니다. 세션을 장시간 실행한 뒤 데이터를 읽기만 하는 Bash Git 명령이 권한을 요청하기 시작했습니다. 이 문제는 2.1.270에서 수정되었습니다. 따라서 최신 버전으로 업데이트하세요. 2026년 9월 17일 기준 최신 버전은 2.1.274였습니다. 2.1.268 또는 2.1.269에서 멈추지 마세요.

## 업데이트하고 차단 규칙이 작동하는지 확인하는 방법

<div class="aside" data-semantic="key-takeaway" role="note" aria-label="섹션 핵심 내용">

핵심 내용

`claude --version`으로 버전을 확인하고 최신 릴리스로 업데이트한 다음, 비밀 정보가 없는 안전한 파일로 테스트하세요. 해당 파일에 deny 규칙을 추가하고 에이전트에게 파일을 읽도록 요청한 후 차단 메시지가 규칙을 가리키는지 확인합니다.

</div>

1.  **현재 버전을 확인합니다.** 터미널에서 `claude --version`을 실행합니다. 위에서 설명한 문제의 수정 사항은 2.1.268 및 2.1.269에서 출시되었습니다. 버전 번호가 2.1.268보다 낮으면 아직 이러한 수정 사항이 포함되지 않았습니다. 다만 각 문제가 적용되는지는 사용하는 경로, 명령 및 규칙에 따라 다릅니다.
2.  **업데이트합니다.** [Claude Code를 최신 버전으로 업데이트하는 방법](https://ailoot.ai/blog/ko/update-claude-code/) 가이드에서 단계별 안내와 문제 해결 방법을 확인할 수 있습니다. 최신 버전을 선택하고 2.1.268에서 멈추지 마세요.
3.  **차단을 테스트합니다.** 실제 `.env` 파일에서 규칙을 테스트하지 마세요. 차단이 실패하면 에이전트가 실제 키를 볼 수 있습니다. 예를 들어 `secret-test.txt`라는 테스트 파일을 만들고 “이것은 테스트입니다” 같은 아무 텍스트나 입력합니다. 프로젝트의 `.claude/settings.json`에 있는 deny 목록에 `"Read(./secret-test.txt)"` 규칙을 추가하고 세션을 다시 시작한 뒤 다음과 같이 요청합니다. “secret-test.txt 파일을 읽고 내용이 무엇인지 말해 줘.” 예상되는 동작은 규칙을 지목하는 차단 메시지입니다. 에이전트가 파일을 읽으면 이 테스트에서 차단이 작동하지 않은 것입니다. 먼저 위 섹션에서 문법을 확인하고 `/permissions`를 열어 활성 규칙과 규칙이 불러온 파일을 확인하세요. 테스트 결과만으로는 원인을 알 수 없습니다. 차단 한 건으로 이 파일에 대한 규칙이 작동한다는 점은 확인할 수 있지만 다른 규칙에 대해서는 알 수 없으므로 같은 방식으로 하나씩 점검하세요.
4.  **해당 경로를 사용하는 경우 symlink 사례를 확인합니다.** macOS에서 `/tmp`, `/etc`, `/var`에 대한 차단 규칙이 있거나 Linux에서 `/bin`에 대한 규칙이 있다면 업데이트 후 이 경로에서도 테스트를 반복합니다.
5.  **“!”가 포함된 규칙을 검토합니다.** 이런 규칙을 사용했다면 각각 의도한 설정 파일에 작성되어 있는지 확인하세요.

차단이 작동하는데도 Claude Code에서 필요한 파일을 볼 수 없다면 별도의 설명인 [Claude Code에서 프로젝트 파일을 볼 수 없는 이유](https://ailoot.ai/blog/ko/claude-code-cant-see-project-files/)를 참조하세요.

## 지금 업데이트할 수 없는 경우

환경을 변경할 수 없거나 컴퓨터가 회사 소유이거나 현재 작업을 끝내야 하는 등 업데이트를 미뤄야 할 때가 있습니다. 업데이트하기 전까지는 다음과 같이 위험을 줄일 수 있습니다.

- symlink 경로와 실제 경로, 두 가지 표기 모두에 deny 규칙을 작성합니다. macOS의 실제 경로는 `/private` 아래에 있습니다.
- 여러 명령을 한 줄에 결합하지 말고, 에이전트에게 실행하도록 요청하는 명령에서 `env -C`와 `eval`을 피합니다.
- `/mcp`, `/plugin`, `claude mcp list` 또는 `claude mcp get`의 출력을 다른 사람에게 보여 주지 말고, 다른 사람의 손에 들어갔을 수 있는 MCP 설정의 키를 교체합니다.
- `tee`는 Edit에 대한 차단을 우회해 씁니다. Bash가 허용되어 있다면 파일이 보호된 것으로 간주하지 마세요.

이 조치들은 특정 우회가 발생할 가능성을 줄이지만 수정 사항을 대체하지는 않습니다. 가능한 한 빨리 업데이트하고 이전 섹션의 테스트를 실행하세요.

## 간단 요약

버전 2.1.268 및 2.1.269에서는 Claude Code의 권한 문제 네 가지가 수정되었습니다. symlink, `env -C`와 `eval`이 포함된 줄, 원래 파일의 범위를 넘어 적용되는 “!” 규칙, `tee`를 통한 쓰기 문제입니다. 별도로 `/mcp` 출력에서 비밀 정보가 노출되는 문제와 플러그인 오류에서 토큰이 표시되는 문제도 수정되었습니다. 버전 번호를 확인하고 최신 릴리스로 업데이트한 다음 위 섹션에서 설명한 테스트 파일로 테스트하세요. 규칙을 지목하는 차단 메시지는 이 테스트에서 차단이 작동했다는 뜻입니다. 설정에 규칙이 있다는 사실만으로는 작동을 확인할 수 없습니다.

<div class="section" role="doc-bibliography" aria-label="출처">

### 출처

- Claude Code 공식 변경 로그(2.1.268, 2.1.269, 2.1.270 항목): <https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md>
- Claude Code 버전의 npm 출시일: <https://www.npmjs.com/package/@anthropic-ai/claude-code>
- Claude Code 권한 문서(deny/ask/allow 문법): <https://code.claude.com/docs/en/permissions>
- Claude Code GitHub 릴리스: <https://github.com/anthropics/claude-code/releases>

</div>





모델을 계속 사용하려면 [Ailoot](https://ailoot.ai/)으로 이동할 수 있습니다.

## Claude Code 2.1.268: deny 규칙과 MCP에서 수정된 사항: 자주 묻는 질문

### 실제 비밀 정보를 노출하지 않고 deny 규칙을 시험하려면 어떻게 하나요?

무해한 문구가 담긴 테스트 파일을 만들고 그 파일의 Read를 거부한 뒤 세션을 다시 시작해 읽기를 요청하세요. 지정한 규칙에 따른 거부가 나와야 합니다. 실패할 수 있는 시험에 실제 .env 파일을 쓰지 마세요.

### 한 번 읽기가 거부되면 모든 권한 설정이 안전한가요?

아닙니다. 시험한 파일과 접근 경로만 확인된 것입니다. /permissions에서 활성 규칙을 검토하고 실제로 의존하는 다른 경로와 상황도 시험하세요. 심볼릭 링크가 관련된다면 그 경로 표기도 포함하세요.


## Ailoot · 회사와 그 프로젝트 포트폴리오

Ailoot는 축적된 운영 경험, 폭넓은 고객 기반, 안정적인 서비스, 지속적인 KPI 관리를 바탕으로 합니다.

회사와 그 프로젝트 포트폴리오: 수백만 고객, 매월 수십억 규모의 매출.

Ailoot는 이러한 운영 경험을 고객의 제품, 에이전트, 애플리케이션, 자동화에서 AI 기능을 이용할 수 있는 API 접근에 활용합니다.