開発ツール

Destructive Command Guard が Codex を保護する方法: 危険な Git および Shell コマンドを傍受する

dcg が危険な Git および Shell コマンド、インストール検証、コミット前スキャン、およびエージェント フックを介したセキュリティ境界をどのように傍受するかについて説明します。

AI プログラミング エージェントがシェルを実行できるようになった後の最大のリスクの 1 つは、間違ったコードを記述することではなく、間違ったディレクトリで削除、上書き、または Git クリーンアップ コマンドを実行することです。 dcg と呼ばれる Destructive Command Guard は、フック前検査コマンドを呼び出して、リスクの高い操作を実行前に遮断するツールとして使用されます。

プロジェクトのアドレス: Dicklesworthstone/destructive_command_guard

簡単な答え

dcg は、Codex CLI、Claude Code、Gemini CLI、Copilot CLI、Cursor およびその他のツールをサポートします。これは追加の防御線としては適していますが、完全なサンドボックスではありません。エージェントは依然として危険な操作をスクリプトに書き込む可能性があり、実行パスの一部がフックをバイパスする可能性もあります。

Linux、macOS、WSL のクイック インストール:

1

curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/destructive_command_guard/main/install.sh?$(date +%s)" | bash -s -- --easy-mode

最初にリモート インストール スクリプトを確認する必要があります。インストーラーは、有効な既存の JSON を直接上書きするのではなく、対応するプラットフォーム バイナリをダウンロードし、ハッシュを検証し、サポートされているエージェント フック設定をマージします。

Codex での動作方法

フックをサポートする Codex CLI の場合、インストーラーは PreToolUse フックを ~/.codex/hooks.json にマージします。インストールが完了したら、Codex の /hooks インターフェイスを一度開き、信頼性を確認します。

エージェントがコマンドを実行する準備ができると、dcg は次のことを行います。

  1. ツールによって呼び出された JSON を解析します。
  2. シェルコマンドを抽出して正規化します。
  3. 明らかに安全なコマンドを迅速に削除します。
  4. ルールを使用して、削除、上書き、強制リセットなどのリスクを特定します。
  5. 許可、拒否を返すか、手動による確認を要求します。

コミット前スキャンをリポジトリに追加する

リアルタイムのフックに加えて、送信されるスクリプトとワークフローもスキャンできます。

1
2
3

dcg scan install-pre-commit
dcg scan --staged
dcg scan --paths scripts/ .github/workflows/

チームがインポートするときは、まず「重大度の高い失敗」という保守的な戦略を採用し、誤検知を観察してから、Makefile、Dockerfile、その他のシェル スクリプトに拡張することをお勧めします。

インストール後の確認方法

実際の削除コマンドを使用してテストしないでください。明らかに危険なシミュレートされたコマンドをエージェントに解釈させ、実行前にフックがブロック メッセージを出力するかどうかを観察することができます。次に、次のことを確認します。

  • dcg が PATH にあるかどうか。
  • エージェントのフック構成が有効な JSON かどうか。
  • /hooks このフックを表示して信頼するかどうか。
  • 元のフックがまだ存在するかどうか。
  • 通常の読み取り専用コマンドに顕著な遅延がないかどうか。

インストール方法とプラットフォームの違い

シェル インストーラーは、Linux、macOS、および WSL で使用できます。ネイティブ Windows では、リポジトリによって提供される install.ps1 を使用する必要があり、PowerShell に Bash コマンドを強制しないでください。

インストール前の推奨事項:

  1. スクリプトを開いてダウンロード アドレスを確認します。
  2. エージェントのフック構成をバックアップします。
  3. 既存の PATH を記録します。
  4. インストールのバージョンと検証メカニズムを確認します。
  5. 最初にテスト アカウントまたはテスト環境で実行します。
  6. インストール後に設定の違いを確認します。

イージー モードは、サポートされているエージェントを自動的に検出して構成しようとします。チーム環境には、--no-configure を使用して最初にバイナリのみをインストールし、次に各ツールのフック マージを手動で確認する方が適しています。

Codex Hook の完全チェック

新しい Codex CLI は、~/.codex/hooks.json の PreToolUse フックを使用します。構成が完了したら、次のようにします。

  • JSON が正常に解析できることを確認します。
  • 元のフックが削除されていないことを確認します。
  • Codex で /hooks を開きます。
  • dcg フックを明示的に信頼します。
  • 非破壊的なシミュレートされたリクエストを使用してブロッキング プロセスをテストします。
  • 通常のコマンドがまだ成功するかどうかを確認します。

/hooks が表示されない場合は、保護が有効であると想定しないでください。 Codex のバージョン、機能のサポート、および実際の構成パスを確認します。

どのコマンドが簡単に傍受されますか?

dcg は、再帰的な削除、強制クリーン、履歴の上書き、広範なディレクトリを対象とする危険なコマンドなど、回復不能な損傷を引き起こす可能性のある Git およびシェルの操作に焦点を当てています。実際のルールは更新され、現在のバージョンが優先されます。

コマンドが危険かどうかは、コマンド名だけでなく、パラメーターとターゲットにも依存します。

1
2
3
4

rm file.tmp                 范围明确，可能允许
rm -rf /broad/path          范围宽且不可恢复，应阻止
git status                  只读
git reset --hard            会丢弃修改，应阻止或确认

誤検知を回避するために、コマンドをより微妙なステップに分割しないでください。ルールは改訂されるか、明確な目標を使用するか、人間の実行に委ねられるべきです。

コードベースでのスキャンパターンの使用方法

リアルタイム フックは、エージェントが現在実行準備中のコマンドを保護し、dcg scan は、スクリプト、CI ワークフロー、Dockerfile、Makefile など、リポジトリ内のシェル フラグメントの実行可能性をチェックします。

初めてインポートする場合の提案:

1

dcg scan --staged --fail-on error

信頼性の高い重大な問題のみが送信をブロックするようにしてください。一定期間観察した後、範囲を次のように拡大します。

1

dcg scan --paths scripts/ .github/workflows/

初日にすべての警告を CI の失敗として設定しないでください。そうしないと、誤検知によりチームがツールを直接シャットダウンすることになります。

コミット前のフックと CI の責任

ローカルの事前コミット

フィードバックは高速であり、送信前に新しい危険なコマンドを発見するのに適していますが、ユーザーは --no-verify を使用してフィードバックを回避できます。そうしないと、フックがインストールされていない可能性があります。

CI スキャン

強制的なルールを形成するには、倉庫による一律の実行の方が適しています。 DCG バージョンを CI で修正し、ダウンロードを検証し、上流で結果が変わることを避けるためにこの差分またはパスのみをスキャンする必要があります。

エージェントのプレツールの使用

コマンド実行前にブロックし、現在のワークスペースを保護します。これは、CI によるリポジトリのコンテンツの継続的な検査に代わるものではありません。

3 つのソリューションは異なる時点を持ち、同時に使用できます。

ホワイトリストの管理方法

一部のプロジェクトでは、ビルド ディレクトリのクリーニングやステージング環境のリセットが必要です。 DCG 全体をシャットダウンするのではなく、範囲が明確で検証可能なコマンドに対して最小限の例外を作成します。

  • プロジェクト内の特定の一時ディレクトリのみを許可します。
  • 環境変数を使用して広範なルート パスを結合しないでください。
  • 最初に絶対パスを解析して出力します。
  • 製品カタログに対する永続的な例外はありません。
  • バージョン管理とコードレビューの例外。
  • 不要になったルールは定期的に削除します。

セキュリティ例外の目的は、誤検知を減らすことであり、エージェントが一般的なバイパスを取得できるようにすることではありません。

データを破壊せずにテストする方法

実際のリポジトリに対して git reset --hard または再帰的削除を実行しないでください。一時テスト リポジトリとダミーのコマンド パラメータを使用して、dcg の解析出力を観察できます。テストには少なくとも次のものが含まれます。

  1. 通常の読み取り専用コマンドが許可されます。
  2. 明らかな危険な注文はブロックされます。
  3. 明確なターゲット スコープを持つクリーンアップ コマンドは期待どおりに処理されます。
  4. 違法なフック JSON はサイレントにリリースされません。
  5. タイムアウトまたは判定できない場合は、手動確認を入力します。
  6. 元のフックは引き続き正常に機能します。

Hook が完全なサンドボックスではない理由

フックは、認識したツール呼び出しのみを検査できます。次のパスは引き続きバイパスされる可能性があります。

  • エージェントがスクリプトを作成し、他のプロセスによってそれを実行します。
  • IDE またはプラグインは、接続されていないターミナル インターフェイスを使用しています。
  • プログラムは API を通じてクラウド リソースを削除します。
  • コンテナ内のコマンドは、マウントされたホスト ディレクトリに影響を与えます。
  • 資格情報が侵害された後、別のマシンで操作します。
  • ユーザーは --no-verify を積極的に使用します。

したがって、OS の権限、コンテナーのマウント、クラウド IAM、バックアップ、承認が引き続き存在する必要があります。

更新とロールバック

利用可能:

1

dcg update

チームは、計画なしにすべての開発マシン上のルールを自動的に更新しないでください。まず、テスト リポジトリで新しいバージョンの誤検出と互換性を検証し、バッチでアップグレードします。ロールバックには、古いバージョン番号と構成のバックアップを保持する必要があります。

トラブルシューティング マトリックス

現象 考えられる原因 治療
dcg が見つかりません PATH が更新されていません 新しいターミナルを開いて、インストール ディレクトリを確認します。
Codex がフックを呼び出していない バージョンまたは hooks.json パス エラー /hooks と構成を確認してください。
元のフックが消えます 合併例外 バックアップを復元して手動でマージする
通常のコマンドはインターセプトされます。誤検知のルール コマンドの範囲を狭めてケースを報告する
危険なスクリプトは傍受されません 実際の実行パスは表示されません。スキャン、権限、サンドボックスを追加
CI の結果が不安定です フローティング バージョンの使用 修正された DCG バージョンとルール

解決しないもの

フックはオペレーティング システムのアクセス許可の境界ではありません。また、当局者は、エージェントが最初にスクリプトを作成してから実行することができ、コーデックスの統合実行パスの一部は完全に傍受されない可能性があることにも注意を促しています。したがって、引き続き協力が必要です。

  • 非管理者アカウント。
  • 作業ディレクトリを制限します。
  • Git ブランチまたは作業ツリー。
  • 重要なデータのバックアップ;
  • 削除およびプッシュ操作の手動承認。
  • コンテナまたは仮想マシンの分離。

よくある質問

インストーラーはフックを上書きしますか?

公式実装はマージを試みます。既存の JSON が無効であるか、異常な構造を持っている場合、元のファイルは保持され、エラーが報告されます。インストール前に構成をバックアップする必要があります。

危険なコマンドがブロックされないのはなぜですか?

コマンドがサポートされているフック パスを使用しているかどうかを確認します。エージェントが操作をスクリプト、アプリケーション内部ツール、または対象外の実行インターフェイスにカプセル化する場合、dcg は最終的なコマンドを認識できない可能性があります。

dcg は各コマンドの速度を大幅に低下させますか?

プロジェクトは高速フックとして設計されており、処理時間に絶対的な上限を設定します。実際の遅延は、やはり独自の端末とルールセットで測定する必要があります。速度の低下が顕著な場合は、ログやその他のフックを確認してください。

開発マシンではなく、CI にのみインストールできますか?

リポジトリの内容をスキャンすることはできますが、ローカル エージェントはコマンドが実際に実行される前にコマンドをインターセプトできません。高権限のエージェント環境では、PreToolUse フックを設定することをお勧めします。

緊急事態における誤った傍受にどのように対処するか?

コマンドを手動で実行する前、または最小限の一時的な例外を作成する前に、コマンドの目的と回復可能性を確認してください。エージェントが自動的にバイパスを見つけることを許可しないでください。

概要

dcg は、エージェントが危険な Git および Shell コマンドを誤って実行する可能性を減らすことができ、Codex または Claude Code がすでにターミナルを実行できる環境に特に適しています。しかし、それは安全ベルトではなく、安全ベルトとして見なされるべきです。本当に信頼できるソリューションは、やはり最小限の権限、ディレクトリの分離、バックアップ、手動承認の組み合わせです。