Search the alley

記事を検索

2文字以上でタイトル・カテゴリ・タグを検索できます。

ZCodeのFull Accessは危険?権限モード・確認ダイアログ・安全な使い方

ZCodeの権限モードを、Default、Confirm Before Changes、Auto Edit、Plan、Full Accessに分けて、許可してよい作業・止めるべき作業を整理します。

公開 2026.07.05 / 更新 2026.07.05

この記事のポイント

  • ZCodeのpermission modesはDefault、Confirm Before Changes、Auto Edit、Plan、Full Accessで確認量が変わる
  • Always AllowとFull Accessは将来の確認を減らすため、trusted contextだけに限定する
  • 秘密情報、外部送信、install、push、deploy、削除、一括置換は人間確認を残す

ZCodeの権限モードを表で見る

モード公式説明の要点向く作業避けたい作業
Default通常の確認挙動日常的なQ&A、軽い開発本番設定や秘密情報を含む作業
Confirm Before Changesfile editやcommand前に確認重要repo、production config、初見repo大量の単純修正を急ぐ作業
Auto Editfile editは自動、commandsは確認小さな反復修正install、外部通信、削除を含む作業
Plan先に計画し、実装前に確認refactor、migration、長時間task即時の小修正だけで足りる作業
Full Access確認を少なく連続実行信頼済みで範囲が狭い作業秘密情報、本番、deploy、課金、未知のscript

Allow / Always Allowを押す前に見ること

  • command、path、file name、外部通信の有無を読む
  • 一度だけならAllow、繰り返し許可するならAlways Allowの影響範囲を見る
  • .env、APIキー、Cookie、秘密鍵を読ませない
  • npm install / pip install / curl sh / unknown scriptは止めて中身を見る
  • git push、deploy、本番DB操作は人間確認を残す
  • MCPは安全装置ではなく権限拡張として扱う
作業ZCodeに任せやすい確認してから止める
調査read-onlyの構造確認、docs要約外部検索やMCP利用秘密情報の表示
編集README、記事、局所CSS複数ファイルの一括置換本番設定の無確認変更
コマンドbuild、lint、testinstall、migration、外部通信不明scriptの実行
Gitstatus、diff、local commit通常pushforce push、reset、clean

よくある質問

Full Accessは使わないほうがいいですか?

全面禁止ではありませんが、信頼済みrepo、狭い作業範囲、戻せる差分、確認済みcommandに限るのが安全です。

Always Allowは何が危険ですか?

将来の同種操作の確認が減ります。最初はAllowで様子を見て、commandやpathが明確なときだけ検討します。

Plan Modeはいつ使うべきですか?

refactor、migration、長時間Goal、料金や外部通信を伴う作業、既存未コミット変更がある作業で有効です。

ZCodeにpushまで任せてもよいですか?

push先、branch、差分、秘密情報、CI、本番反映の有無を確認できる場合だけです。本番環境へ直接反映されるpushは人間確認を残します。

関連記事