Cowork削除承認はなぜどのモードでも外せないのか

Coworkの承認モードはManual・Auto・Skipの3種類(Pro・Maxの新しい画面ではAutoとManualの2つ)で、選び方によって確認の回数は大きく変わります。ただしファイルの完全削除は別枠です。Skip(承認を省くモード)を選んでいても、Claudeがファイルを完全に削除する前には「Allow」を選ぶ確認が出ます。安全ガイドは「Claude always asks before permanently deleting files, in any mode」と書いています。

この一文は便利ですが、読み違えやすい文でもあります。「削除」と名のつく操作がすべて対象なのか、組織の管理者が設定で外せるのか、定期実行のタスクではどうなるのか。答えはページごとに書かれ方が違い、突き合わせないと見えない部分があります。ここではその境目を、削除の種類ごとに切り分けます。承認の回数が多すぎて困っている場合はCoworkの承認プロンプトが多すぎるときの減らし方が入口です。

確認が必ず出る削除と、出るとは限らない削除

文言は「ファイルの完全削除(permanently deleting any files)」に限られています。Coworkがコネクタ経由で外部サービスのデータを消す場合は、別の仕組みで承認が決まります。

はじめてのCowork解説には、モードとコネクタ側の権限(常に許可・要承認・ブロック)を掛け合わせた表があります。Manualは「常に許可」を承認済み、「要承認」なら確認、「ブロック」なら拒否です。Autoでは、常に許可のツールのうち読み取り専用のものは承認されます。書き込み・削除のツールは、常に許可でも要承認でもClaudeが判断します。ブロックは拒否です。Skipは、ブロック以外をすべて承認します。表の見出しに「write/delete tools」とあるとおり、コネクタの削除は書き込みと同じ列に入っています。

つまりManualという名前でも、コネクタの権限を「常に許可」にしたツールは毎回は聞かれません。削除保護の確認画面が出ることと、業務データの削除が安全に扱われていることは別の話です。ファイルの確認だけを見て安心せず、コネクタ側の権限が3段階のどこにあるかも見ておく必要があります。権限の内訳はClaude CoworkのConnectors一覧にあります。

「削除」が指す3つのもの

Cowork周りの公式ページには、削除に関する記述がほかにも出てきます。似た言葉ですが、削除保護の対象ではありません。

タスクの削除は「タスク履歴から即座に消え、30日以内にバックエンドのストレージからも消える」と説明されています。定期タスクを削除する操作は、Scheduledページから行えます。どちらのページにも、削除保護の確認と同じ画面が出るとは書かれていません。出るかどうかは読み取れないので、本記事では断定しません。

Team・Enterpriseの組織設定は、削除保護に触れるのか

管理者向けの設定は2つあります。「Automatically approve」モードを使えるかを決める設定(初期値はオン)と、コネクタの書き込み系ツールで「常に許可」を使えるかを決める設定(初期値はオフ)です。後者がオフのとき、承認ダイアログの「Allow for all tasks」は灰色になり、保存済みの「常に許可」も無効になります。読み取り専用として注釈されたツールだけは対象外で、注釈のない多くのカスタムコネクタは、全ツールが承認の対象になります。

この2設定はいずれもコネクタのツールとモードの話です。組織の管理ページには、ファイルの完全削除の確認を弱める設定は見当たりません。ここから言えるのは、削除保護がモードの選択とは独立に書かれていて、組織設定が触れる項目としても書かれていないという範囲までです。「管理者が何をしても外せない」と言い切れる根拠は、確認できたページにはありません。

管理者にとって実務上の意味は別のところにあります。組織で「Automatically approve」を許すかどうかを決めるとき、判断材料になるのは主にコネクタ側の承認の挙動です。ファイルの削除確認は、その判断の前提として常に出ると見込めます。承認を減らしたい担当者は、削除ではなく書き込み系のコネクタ権限を見直すほうが効きます。

なぜ削除だけ固定なのか

理由は公式ページに書かれていません。以下は編集側の推測です。

同じ「取り消しにくい」操作でも、メッセージの送信や購入は、訂正の連絡や返金の申請など事後の対処が残ります。安全ガイドは、Manualへの切り替えを勧める場面として「Mistakes would be hard to undo, like sending messages or making purchases」を挙げています。送信や購入の確認はユーザーが選ぶモードに委ねられ、削除の確認は委ねられていません。完全に削除したファイルは、別の場所にバックアップがなければ戻せません。この差が固定ルールの理由だと考えるのが自然ですが、説明としては書かれていない点は押さえておいてください。

同じガイドには、ファイルについての注意もあります。Claudeは接続したファイルを読み、書き、完全に削除できます。専用の作業フォルダを用意し、広い範囲を渡さず、大事なファイルのバックアップを取っておくよう勧めています。確認画面は最後の1回で、フォルダの範囲とバックアップが手前の備えになります。

Claude Codeにも固定ルールはあるが、範囲が違う

Claude Codeの削除の扱いは「分類器が文脈で判断する」と説明されがちですが、実際は二層です。分類器の判断とは別に、rmとrmdirが特定のパス(クリティカルパス)を対象にするときだけ働く固定ルールがあります。クリティカルパスの主なものは、ファイルシステムのルート、ルート直下のディレクトリ、ホームディレクトリ、作業ディレクトリとその親です。Windowsではドライブルートとその直下(C:\、C:\Windowsなど)も入ります。追加した作業ディレクトリは、その直下をglobで消す場合だけ対象になります。

Claude Codeのモード別の結果は次のとおりです。

CoworkのSkipに近いのは、Claude CodeのbypassPermissionsです。ほとんどの確認を飛ばすモードでも、クリティカルパスへのrmだけは承認が要ります。この意味では、Coworkの削除保護と発想は同じです。違うのは範囲で、Claude Codeは壊れたときの被害が桁違いに大きいパスに絞り、Coworkは「ファイルの完全削除」全体を対象にしています。

autoとbypassPermissionsの「制限時間」は具体的な数字です。ターミナルの確認画面には2分のカウントダウンが出て、答えないと拒否になります。応答のないまま3回時間切れになると、それ以降のクリティカルパスの削除は確認を出さずに即座に拒否されます。新しいメッセージを送るとカウントはやり直しです。画面にキーを押すとカウントは止まります。VS Code拡張のチャット画面、Desktopアプリ、-pによる非対話実行、Agent SDKのセッションでは、autoは確認画面を出さずに拒否し、Claudeには「削除したい対象を報告して、削除はユーザーに任せる」よう伝えます。確認する人がいない環境では、確認待ちで止まらず拒否に倒れる設計です。

ここまでがクリティカルパスの話です。それ以外の削除は、autoでは分類器が見ます。分類器はセッション開始前から存在したファイルの不可逆な破棄、クラウドストレージの大量削除、作っていない状態つきリソースの削除などを、既定でブロックします。一方で、Claude自身がそのセッションで作ったジョブの削除は既定で通ります。ただし分類器は既定で、クリティカルパスへのrmとrmdirを見ません。前者の固定ルールと後者の分類器が、別々の網として重なっています。

手元のclaude(v2.1.285)で確認できる範囲では、claude --helpに次の行が出ます。

$ claude --help
  --permission-mode <mode>   Permission mode to use for the session
                             (choices: "acceptEdits", "auto",
                             "bypassPermissions", "manual",
                             "dontAsk", "plan")

選べるモードは6つです。クリティカルパスの挙動をモデル呼び出しなしで確かめる方法はないため、表の結果はドキュメントの記述に基づくもので、実機では検証していません。分類器の判断基準の全体像はClaude Codeのauto mode分類器は何を止めているか、全体の機能はClaude Codeの完全ガイドにあります。

削除を伴うタスクを任せる前に

削除確認が「立ち止まる機会」でしかないことを前提に、任せる前の手順を並べます。

確認画面の限界と、定期タスクで起きること

確認画面は、内容を読まずに「Allow」を押せば機能しません。プロンプトインジェクション(悪意ある指示を紛れ込ませる攻撃)で無関係なファイルの削除を許可するよう誘導される可能性も、理屈のうえでは残ります。安全ガイド自身、対策を講じても攻撃の可能性はゼロではないと述べています。

定期タスクについては、公式ページから確実に言えることが限られます。安全ガイドは、定期タスクがクラウドで動き、ユーザーが見ていない間に動く点を注意しています。Scheduledページで過去の実行を確認できることも書かれています。一方、削除の確認待ちで止まった定期タスクがどう表示されるかは、確認できたページには書かれていません。そのため、削除を含む定期タスクは、まず手動で実行して挙動を見てから、頻度と承認モードを決めるのが順当です。組み方はCowork Scheduled Tasksで定型レポートを自動化する実践パターンにあります。

クラウド上のタスクは、ローカルのファイルを直接触りません。Webやモバイルで動くタスクは、アカウントに保存されたファイルとコネクタで動き、ローカルのフォルダに届くのは、Claude Desktopが開いていて、そのフォルダを接続している場合だけです。同じページには、定期タスクはローカルのフォルダに結び付けられないと書かれています。「削除の確認は誰の画面に出るのか」を考えるとき、この実行場所の違いが効いてきます。

削除の扱いを決める前に

承認モードごとの全体設計はCowork自動承認モードとはとCowork Approval Gatesを部門ごとに設計する考え方が、どの操作をManual承認に固定するかの判断はCoworkの取り消せない操作をどう見極めるかが扱っています。

削除確認は、モードの設定では外せない最後の1回です。持ち帰る判断は、確認画面の有無ではなく、確認画面の手前にある備え(フォルダの範囲とバックアップ、コネクタ権限)を先に決めておくことです。