CC for Biz
2026/10/31Claude Code
セキュリティ導入・運用

Claude Codeの作業フォルダ外への書き込みを止める設定

Claude Codeの作業フォルダ外への書き込みを止める設定

「Claude Codeに頼んだのは1つのフォルダの作業なのに、関係のない場所のファイルまで書き換えられていた」「権限の確認を飛ばすモードで回すと、どこまで書かれるのか分からない」——Claude Codeに作業を任せる時間が長くなるほど、こうした不安は大きくなります。

結論から言うと、2026年10月30日公開のClaude Code 2.1.314で permissions.blockWritesOutsideWorkingDirectories という設定が入り、Claude Codeの作業フォルダの外への書き込みを、設定1行で止められるようになりました。止まるのはWrite・Edit・NotebookEditの3つのツールで、権限モードは問いません。ただし、シェル(Bash)からの書き込みと、作業フォルダの中の「ここから下だけ」という線引きは、この設定の外にあります。

株式会社Fyveは、Mac miniで無人のジョブを毎日回しながら、書いてよい場所の線引きを何度か作り直してきました。この記事では、変更履歴(CHANGELOG)の原文を正として設定の中身と書き方を整理し、そのうえで、この設定では止まらないものを、私たちの運用でどう補っているかまでお伝えします。

Claude Codeの作業フォルダ外への書き込みを止める設定とは

まず、何が入ったのかを原文で確認します。2.1.314の変更履歴(GitHubのリリースページ・2026年10月30日公開)の1行目にこう書かれています。

Added permissions.blockWritesOutsideWorkingDirectories: Write, Edit and NotebookEdit refuse paths outside the working directories in every permission mode

訳すと「permissions.blockWritesOutsideWorkingDirectories を追加。Write・Edit・NotebookEditは、どの権限モードでも、作業フォルダの外のパスを拒否する」です。読むべき点は3つあります。

  • 対象は3つのツール: ファイルを新しく作るWrite、既存のファイルを書き換えるEdit、Jupyterのノートブックを書き換えるNotebookEdit。原文に名前が挙がっているのはこの3つだけです
  • 「どの権限モードでも」: 確認を飛ばす bypassPermissions や、AIの判定に任せる auto でも拒否する、という意味です。許可を出すかどうかを聞く仕組みとは別の層で止まります
  • 基準は「作業フォルダ」: Claude Codeを起動したフォルダに加えて、--add-dir・/add-dir・設定の additionalDirectories で足したフォルダも作業フォルダに含まれます(公式ドキュメントの「Working directories」の定義)

3つ目は見落としやすい点です。additionalDirectories に広い場所(たとえばホームフォルダ全体)を入れていると、この設定を有効にしても、その範囲には書けてしまいます。止める範囲は「作業フォルダとして何を足しているか」で決まります。

公式ドキュメントにはまだ載っていない

2026年10月31日に公式の設定リファレンス(settings-reference)を確認したところ、読み取り側の blockReadsOutsideWorkingDirectories は項目として載っていましたが、書き込み側の blockWritesOutsideWorkingDirectories はまだありませんでした。permissions に書けるキーの一覧にも入っていません。

そのため、この記事の設定の説明は変更履歴の1行を正としています。優先順位(組織の管理者の設定とどちらが勝つか)や、細かい例外は、公式ドキュメントに載ってから確かめる必要があります。この記事の時点で書けることと、書けないことを分けて進めます。

読み取り側の設定と対で考える

書き込み側の設定には、先に入っていた読み取り側の兄弟がいます。2.1.257(2026年9月)で入った permissions.blockReadsOutsideWorkingDirectories です。公式の設定リファレンスでは、次のように説明されています。

  • bypassPermissionsを含むどの権限モードでも、作業フォルダの外に対するRead・Grep・Glob・LSPを拒否する
  • 拒否したときは、Claudeに「/add-dir でフォルダを足すよう利用者に頼む」ように伝える
  • スキル・プラグイン・ルールなど、Claude Code自身が必要とするファイルは読める
  • シェルのコマンドは同じやり方では拒否しない

読み取りの許可の出し方そのものは、別の記事で詳しく整理しています。

Claude Codeの作業フォルダ外の読み取り|許可4択の意味
Claude CodeClaude Codeの作業フォルダ外の読み取り|許可4択の意味

読み取りと書き込みを並べると、次のようになります。

読み取り側

書き込み側

設定名

blockReadsOutsideWorkingDirectories

blockWritesOutsideWorkingDirectories

入った版

2.1.257(2026年9月)

2.1.314(2026年10月30日)

止まるツール

Read・Grep・Glob・LSP

Write・Edit・NotebookEdit

権限モード

bypassPermissionsを含む全モード

全モード(変更履歴の記載)

シェル(Bash)

同じやり方では拒否しないと明記

変更履歴に記載なし

公式ドキュメント

設定リファレンスに項目あり

10月31日時点で項目なし

情報の流れで言えば、読み取りは「外にあるものを見られる」危険、書き込みは「外にあるものを変えられる」危険です。片方だけ有効にしても、もう片方の穴は残ります。2つを同時に入れるのが基本形だと私たちは考えています。

この記事を読んでいるあなたへ無料プレゼントClaudeのこの5つの設定、今すぐ見直した方がいい共有・学習・入力・権限・委任。事故が起きるのはこの5つだけ(全28ページ)
見落としやすい共有リストは3つある(3つ目は画面の下)学習をオフにしても残る、公式の例外条項権限モード6つの違いと、Shift+Tabでの切り替え方
中身のプレビューを見る ↓登録すると、過去の特典もまとめて受け取れます(PDF 19点・合計499ページ + すぐ使えるzip素材 3点)

前はどうやって止めていたか

この設定が入る前にも、作業フォルダの外への書き込みを止める手段はありました。ただ、どれも一長一短でした。

denyルールで書き込み先を指定する

1つ目は、設定ファイルの permissions.deny に Edit(...) のルールを書く方法です。公式ドキュメントの説明では、ファイルの書き込みの許可は Edit(path) のルールだけで判定され、Write(path) や NotebookEdit(path) と書いたルールは「受け付けるが一致しない」とされています。つまり Write(~/Documents/**) と書いても効かず、気づかないまま穴が残ります。この罠は別の記事でも取り上げました。

Claude Codeの権限ルールの罠|黙って効かない指定
Claude CodeClaude Codeの権限ルールの罠|黙って効かない指定

もう1つの弱点は、denyは「止めたい場所を列挙する」方式だという点です。守りたい場所を全部書き出す必要があり、書き忘れた場所は守られません。今回の設定は逆に「作業フォルダ以外は全部止める」方式なので、列挙の漏れが起きません。

PreToolUseフックで書き込み先を検査する

2つ目は、ツールが動く直前に呼ばれるPreToolUseフックで、書き込み先のパスを自前のスクリプトで検査する方法です。自由度は高い一方で、パスの正規化(~ の展開、シンボリックリンクの解決、.. を含む相対パス)を自分で正しく書く必要があります。ここを間違えると、すり抜けが起きます。

困りごとはIssueにも上がっていた

「作業フォルダの外のファイルに触れてしまう」という報告は、GitHubのIssueにも上がっていました。たとえば2026年4月24日に立った #52988 は、ワークツリー(git worktree)の外のファイルにアクセスした、という報告です(現在はクローズ済み)。今回の設定は、こうした困りごとに対して、denyやフックを書かずに済む標準の手段を用意したものと読めます。

設定の書き方と、効いているかの確かめ方

手順1:版を確かめる

この設定は2.1.314以降でしか効きません。まず手元の版を確かめます。

claude --version

2026年10月31日にnpmの配布の区分(dist-tag)を確認したところ、latest は2.1.316、stable は2.1.309でした。stableの区分で更新している人には、10月31日の時点でこの設定はまだ届いていません。古い版では、設定ファイルに書いても何も起きないまま静かに無視される可能性が高いので、版の確認を最初に置いています。

実際、私たちのMac miniのClaude Codeは、この記事の時点で2.1.296でした。そのため、この記事の時点で手元では確かめていません。以下の手順は、変更履歴の記載にもとづく手順として読んでください。

手順2:設定ファイルに書く

設定ファイルの permissions に1行足します。読み取り側と対で入れる場合は次のようになります。

{
  "permissions": {
    "blockWritesOutsideWorkingDirectories": true,
    "blockReadsOutsideWorkingDirectories": true
  }
}

書く場所は、すべてのプロジェクトに効かせたいならユーザー設定(~/.claude/settings.json)、特定のプロジェクトだけならそのプロジェクトの .claude/settings.json です。設定ファイルの置き場所と優先順位の考え方は、こちらで整理しています。

Claude Code settings.jsonの書き方|settings.local.jsonとの違いと実務設定例
Claude CodeClaude Code settings.jsonの書き方|settings.local.jsonとの違いと実務設定例

なお、読み取り側の設定は「どのスコープから true にしても、管理者の設定が false でも有効になる」と公式ドキュメントに書かれています。書き込み側も同じ扱いになるかは、10月31日の時点ではドキュメントに記載がありません。組織で管理者の設定(managed settings)を配っている場合は、ドキュメントの更新を待ってから前提にしてください。

手順3:わざと外に書かせて、拒否されるのを見る

設定は、書いただけでは効いているか分かりません。テスト用のフォルダでClaude Codeを起動し、作業フォルダの外にファイルを作るよう頼みます。

mkdir -p ~/cc-write-test && cd ~/cc-write-test
claude
# Claude Codeの中で次のように頼む
# 「~/Desktop/outside-test.txt に hello と書いたファイルを作って」

Writeツールが拒否されれば、設定は効いています。権限モードを bypassPermissions に切り替えて同じ依頼をし、それでも拒否されるかも見ておくと安心です。「どの権限モードでも」という記載が、手元で本当にそう動くかを確かめる手順です。

手順4:シェル経由の書き込みも試す

同じテストで、今度は「echo hello > ~/Desktop/outside-test2.txt をシェルで実行して」と頼みます。ここで何が起きるかが、次の章の話です。

この設定で止まらないもの

この設定は便利ですが、「設定1行で全部守れる」わけではありません。止まらないものは大きく2つあります。

Claude Codeの書き込みを止める3つの層:ファイルツールは設定、シェルはサンドボックス、作業フォルダの中の決まりは終わった後の差分の検査で止める

止まらないもの1:シェル(Bash)からの書き込み

変更履歴で対象として名前が挙がっているのは、Write・Edit・NotebookEditの3つだけです。Bashは挙がっていません。読み取り側の設定は、公式ドキュメントで「シェルのコマンドは同じやり方では拒否しない」と明記されています。書き込み側も同じ作りである可能性が高く、少なくとも「Bashも止まる」と前提にする根拠はありません。

シェルからの書き込みには、別の仕組みがあります。公式ドキュメントでは、> file のような出力のリダイレクトと tee の書き込み先は、Editのルール・保護されたパス・作業フォルダと照らして確認される、と説明されています。ただし、これは「承認を求める」仕組みです。承認の確認を飛ばす bypassPermissions では、確認そのものが飛ばされます。また、実行したスクリプトの中で行われる書き込みは、コマンドの文字列には現れないため、実行前の確認では捉えきれません。

シェルの書き込みを確実に囲うなら、サンドボックスを使います。公式ドキュメントによると、サンドボックスの中で動くコマンドが書き込めるのは、既定で作業フォルダ・利用者ごとの一時フォルダ・足したフォルダだけで、これはOSの水準で強制され、子プロセスにも及びます。外に書く必要がある道具には sandbox.filesystem.allowWrite で個別に場所を足します。

書き込みの経路

今回の設定

補う手段

Write・Edit・NotebookEdit

止まる(全モード)

—

シェルのリダイレクト・tee

記載なし

承認の確認(bypassPermissionsでは飛ぶ)/サンドボックス

シェルで実行したスクリプトの中

記載なし

サンドボックス

作業フォルダの中の決まり

対象外(中は全部書ける)

終わった後の差分の検査

止まらないもの2:作業フォルダの「中」の決まり

もう1つは、作業フォルダの中の線引きです。この設定は「外か、中か」しか見ません。たとえばリポジトリのルートで起動した場合、リポジトリの中なら設定ファイルでも、他の人が管理しているフォルダでも、全部「中」です。「このジョブは出力用のフォルダの下だけに書いてよい」という決まりは、この設定では表せません。

中の決まりは、denyルールで個別の場所を止めるか、次に書くように「終わった後の差分」で検査するかのどちらかになります。

私たちの運用:書いてよい場所を、指示ではなくシェルで決める

ここからは、私たちが実際にどう線引きしているかです。私たちはMac mini(常時起動のマシン)で、情報収集や記録の整理といった無人のジョブを毎日回しています。どのジョブも、共通のシェルスクリプトを経由して claude -p(対話なしでClaude Codeを1回動かすコマンド)を呼びます。

このとき、書いてよい場所は「無人のジョブ専用の出力フォルダの下だけ」と決めています。この決まりを守らせているのは、AIへの指示ではなく、ジョブを包むシェルスクリプトです。

  1. ジョブが終わったら、git status --porcelain で変更のあったファイルを一覧にする
  2. 出力フォルダ以外の変更が1つでもあれば、名前を挙げてSlackに知らせる
  3. コミットするのは出力フォルダの下だけ(git add の対象を出力フォルダに限る)
  4. 出力フォルダの外の変更は、次のジョブの開始時にリポジトリを最新の状態へ戻すときに消える

指示に「ここだけに書いて」と書いても、AIは守ることもあれば守らないこともあります。シェルの検査は、AIが何を考えたかに関係なく、結果の差分だけを見ます。2026年7月には、古い場所に記録を書き続けていたスクリプトを、この検査で見つけました。AIが間違ったのではなく、人が書いた道具の側の置き忘れでした。どちらが原因でも同じ検査で拾えるのが、差分で見る利点です。

無人のジョブの書き込みを2段で守る流れ:実行中は外への書き込みを設定で拒否し、終わった後に中の決まりを差分で検査する

この仕組みでも漏れた経路があった

ただし、この仕組みには前提があります。「そのシェルスクリプト経由で動いたジョブにしか効かない」ことです。2026年7月には、同じMac miniの上で人が直接開いたClaude Codeのセッションが、出力フォルダの外を書き換えて、そのまま共有のリポジトリに反映してしまったことがありました。シェルの検査を通らない経路だったため、素通りしています。後から取り消して直し、今はそのマシンで対話のセッションを開かない、という運用の決まりで塞いでいます。

この件は、今回の設定でも防げません。そのセッションはリポジトリの中で作業しており、書き換えた場所も作業フォルダの「中」だったからです。外を止める設定と、中の決まりを守らせる検査は、役割が違います。

今回の設定は、どこに効くか

では、私たちの運用で今回の設定はどこに効くか。答えは「差分の検査では見えない場所」です。差分の検査はgitが追っているリポジトリの中しか見ません。ホームフォルダの設定ファイルや、デスクトップのファイルが書き換えられても、リポジトリの差分には出てきません。リポジトリの外への書き込みを実行中に止めるのが今回の設定、リポジトリの中の決まりを終わった後に確かめるのが差分の検査、という分担になります。

無人で回すときのdenyルールの考え方は、こちらにまとめています。今回の設定と組み合わせて使う前提です。

Claude Codeのdeny設定の書き方|無人運用の事故防止
Claude CodeClaude Codeのdeny設定の書き方|無人運用の事故防止

今日から組める、書き込みの守り方

ここまでを、読者の環境で組める手順に落とします。

  1. 版を上げる: claude --version で2.1.314以降かを確かめる。stableの区分で更新している場合は、届くのを待つか、区分を切り替えるかを決める
  2. 2つの設定を入れる: blockWritesOutsideWorkingDirectories と blockReadsOutsideWorkingDirectories をユーザー設定に入れる
  3. 足しているフォルダを見直す: additionalDirectories に広すぎる場所が入っていないか確かめる。ホームフォルダ全体などが入っていると、設定の意味が薄れる
  4. わざと外に書かせて試す: Writeが拒否されるか、bypassPermissionsでも拒否されるかを見る
  5. シェルはサンドボックスで囲う: 無人で回す、またはbypassPermissionsで回すなら、サンドボックスを有効にして、外に書く道具だけ allowWrite で足す
  6. 中の決まりは差分で見る: 無人のジョブなら、終わった後に git status --porcelain で決めた場所以外の変更を探し、見つかったら知らせる。コミットの対象も決めた場所に限る

6つ目は、cronやlaunchdで回しているなら、ジョブの最後に数行足すだけで始められます。

# ジョブの最後に足す例(output/ 以外の変更を探す)
OUTSIDE="$(git status --porcelain | cut -c4- | grep -v '^output/' || true)"
if [ -n "$OUTSIDE" ]; then
  echo "決めた場所の外に変更があります: $OUTSIDE"   # ここを通知の処理に置き換える
fi
git add output/

同じ2.1.314で変わったこと

同じ版では、無人の運用に関わる修正がほかにも入っています。変更履歴から2つ挙げます。

  • claude -p の起動失敗が終了コード1に: これまでは、起動に失敗しても終了コード0のまま何も出さずに終わることがありました。2.1.314からは、エラーを表示して終了コード1で終わります。cronやlaunchdで「失敗したら知らせる」を終了コードで判定している場合、これまで拾えなかった失敗が拾えるようになります
  • 長く放置した会話の要約(idle compaction): VS Codeの拡張機能とClaude DesktopのCodeタブで、20万トークンを超えて放置された会話を要約しておき、プロンプトのキャッシュが切れていれば次のメッセージでその要約を使う仕組みが入りました

1つ目について補足すると、終了コードで拾えるのは「起動に失敗した」場合です。起動はしたが中身が空だった、という失敗は終了コード0のままなので、ログの中身を見る検査は引き続き必要です。

よくある質問

Q1. この設定を入れれば、bypassPermissionsで回しても安全ですか

ファイルツール(Write・Edit・NotebookEdit)による外への書き込みは止まります。ただし、シェルからの書き込みは変更履歴の対象に入っていません。bypassPermissionsで回すなら、サンドボックスを併用してください。

Q2. 作業フォルダの外に書く必要があるときはどうしますか

その場所を作業フォルダに足します。セッション中なら /add-dir、毎回なら設定の additionalDirectories です。足したフォルダは「中」として扱われます。必要な場所だけを狭く足すのがポイントです。

Q3. 読み取り側の設定だけ入れていれば十分ですか

十分ではありません。読み取り側は外のファイルを「見る」ことを止める設定で、「書く」ことは止めません。2.1.314以降なら、書き込み側も一緒に入れてください。

Q4. 古い版で設定を書いたらどうなりますか

2.1.314より前の版は、この設定を知りません。書いても効かない可能性が高いです。設定を書く前に版を確かめ、書いた後は手順3のように、わざと外に書かせて拒否されるのを確かめてください。

Q5. この記事の内容は、手元で検証されていますか

この記事の時点で、私たちの手元のClaude Codeは2.1.296で、この設定を確かめていません。設定の中身は2.1.314の変更履歴(2026年10月30日)を、読み取り側の設定・リダイレクト・サンドボックスの説明は公式ドキュメント(2026年10月31日に確認)を正としています。

まとめ

  • Claude Code 2.1.314(2026年10月30日)で permissions.blockWritesOutsideWorkingDirectories が入り、Write・Edit・NotebookEditが、どの権限モードでも作業フォルダの外のパスを拒否するようになった
  • 作業フォルダには、--add-dir・/add-dir・additionalDirectories で足したフォルダも含まれる。足す範囲が広いと、止まる範囲は狭くなる
  • 読み取り側の blockReadsOutsideWorkingDirectories(2.1.257〜)と対で入れるのが基本形
  • 止まらないのは、シェル(Bash)からの書き込みと、作業フォルダの中の決まり。前者はサンドボックス、後者は終わった後の差分の検査で補う
  • 10月31日の時点で、公式の設定リファレンスには未掲載、npmのstableの区分にも未着。版の確認と、わざと外に書かせる確認を最初に置く

AIに任せる範囲を広げるほど、「どこまで書いてよいか」を決める仕組みの重みは増します。株式会社Fyveは、指示で頼むのではなく、設定とシェルで先に決めておく作り方を、自社の運用で試しながらお伝えしていきます。

この記事を読んでいるあなたへ無料プレゼント

Claudeのこの5つの設定、今すぐ見直した方がいい

共有・学習・入力・権限・委任。事故が起きるのはこの5つだけ(全28ページ)

2026年7月、Claudeの共有チャットがGoogle検索から読める状態になっていました。原因は設定そのものではなく、自分が過去に共有したものを覚えていないことでした。共有リンクの棚卸しから、学習をオフにしても残る例外条項、Claude Codeの権限モードまで、今日30分で確認できる形にまとめています。

  • 見落としやすい共有リストは3つある(3つ目は画面の下)
  • 学習をオフにしても残る、公式の例外条項
  • 権限モード6つの違いと、Shift+Tabでの切り替え方
  • 私が実際に禁止しているコマンド23行を全文公開

メールアドレス登録で他にも様々な資料を閲覧できます

「GPT-6.1 Terra」を、実務で比べてみた。仕事でAIを使う人が「絶対に」知っておくべき Claude Codeスキル TOP10「Sonnet 5.5」を、実務で比べてみた。Codexを使い始める前に、「絶対に」見直してほしい5つのこと「Opus 5.5」を、実務で比べてみた。Jevで得する仕事、損する仕事Astra と Fable 5.1、ベンチマークでは分からない「使い分け」。Fable 5.1、賢さは「どこ」に出たか。Workにしかできない仕事は、2つだけ+10

PDF 19点・合計499ページ + すぐ使えるzip素材 3点

どれも登録後の受け取りページから、まとめてダウンロードできます。

毎週配信の無料ニュースレター「AIネイティブ超研究」の購読特典です。メール登録後すぐ、受け取りページのご案内が届きます。そこにはこの資料に加えて、過去の特典もすべてまとめて置いてあります。あわせて、AI活用に関するお知らせやお役に立てそうなご案内をお送りすることがあります。解除はいつでも1クリック。

← 記事一覧に戻る

御社の業務に合わせたClaude Code導入支援

「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。

無料AI活用診断を受ける料金とサービス一覧を見る →
© 2025 Fyve Inc. All rights reserved.