Kiro IDE の Agent Focus セッションが Allow 待ちで止まる問題を permissions.yaml で解消した

Kiro IDE の Agent Focus セッションが Allow 待ちで止まる問題を permissions.yaml で解消した

Kiro IDE の Agent Focus モードで頻繁に表示される「PERMISSION NEEDED」の通知が気になっていたので、permissions.yaml を編集してこの問題を解決した方法を紹介します。
2026.08.27

いわさです。

Kiro IDE の Agent Focus モードをよく使っています。
複数のタスクを並列で進めていて、中には「最初だけ指示して、あとはじっくり進めておいてほしい」というものもあります。

ところが、しばらく放置していると「PERMISSION NEEDED」の通知が表示されていて、セッションが止まっていることがよくあります。
Allow ボタンを押せばすぐ再開するのですが、放置前提で使いたい時には地味に気になります。

Kiro IDE の permissions.yaml をいじることでどうにかしたので紹介します。

permissions.yaml とは

Kiro IDE には capability-based permissions system という権限制御の仕組みがあります。
エージェントが実行しようとする操作を種類(capability)ごとに分類し、それぞれに allow / deny / ask のルールを宣言的に定義できます。

https://kiro.dev/docs/permissions/

設定ファイルの場所は ~/.kiro/settings/permissions.yaml です。
ユーザースコープの設定で、全ワークスペースに適用されます。

Allow ボタンの仕組み

エージェントがツールを使おうとした時に権限が不足していると、チャット上に承認プロンプトが表示されます。

096307E1-5B2F-4A08-99C6-33F75ABD2BD4.png

ボタンの選択肢は以下の通りです。

ボタン 動作
Allow 今回だけ許可(1回限り、永続化されない)
Always allow 永続的な allow ルールを作成(パターン・スコープ選択が開く)
Deny 今回だけ拒否
Always deny 永続的な deny ルールを作成

「Always allow」を選ぶとルールの保存先を選択できます。

保存先 説明
All workspaces ~/.kiro/settings/permissions.yaml に保存
This workspace ~/.kiro/workspace-roots/<hash>/permissions.yaml に保存(リポジトリ外)
This session メモリ上のみ。セッション終了で消える

「Always allow」を繰り返していると、permissions.yaml にどんどん個別ルールが追記されていきます。

放置しておくと膨大なルールが溜まる

私の環境の permissions.yaml は気づいたら 350 行を超えていました。
こういう感じのルールが大量に並んでいます。

rules:
  - capability: shell
    match:
      - npm *
      - python *
      - python3 *
      - sam *
      - npx *
      - git *
      - aws *
      - docker *
      - terraform *
      - kubectl *
      # ... 100個以上のパターン ...
      - AWS_ACCESS_KEY_ID=AKIA****** AWS_SECRET_ACCESS_KEY=****** /usr/local/bin/aws *
      - AWS_ACCESS_KEY_ID=AKIA****** AWS_SECRET_ACCESS_KEY=****** AWS_DEFAULT_REGION=ap-northeast-1 /usr/local/bin/aws *
    effect: allow
  - capability: fs_read
    effect: allow
    match:
      - "**"
  - capability: fs_write
    effect: allow
    match:
      - /Users/iwasa.takahito/**
      - /private/tmp/**
      - "**"
  - capability: mcp
    match:
      - backlog/get_issue
      - backlog/get_wiki_pages
      # ... MCPツールごとに個別列挙 ...
    effect: allow
  - capability: subagent
    effect: allow
    match:
      - ブログ執筆エージェント
      - Backlog運用エージェント
      # ... エージェントごとに個別列挙 ...

特に困るのが、AWS CLI を 1Password CLI プラグイン経由で使っている場合です。
セッションが変わるたびにクレデンシャル付きのコマンドが新しいパターンとして Ask されるので、毎回 Allow を押しても次のセッションではまた聞かれます。
Always allow を選ぶとクレデンシャル文字列がそのまま permissions.yaml に保存されるのも微妙です。

capability: all で全許可にする

個別にパターンを追加していくのはキリがないので、全部許可にしてしまうことにしました。
permissions.yaml を以下の3行に書き換えます。

rules:
  - capability: all
    effect: allow

これで普段の操作はほぼ承認なしで通るようになります。実行してみるとファイル書き込みやシェルコマンド実行など承認がなくなりました。

76ED05AF-EC41-42AB-8469-793A75C64232.png

なお、公式ドキュメントではこの設定は「CI and headless environments」セクションで紹介されています。
対話的な IDE 環境での使用について特に注意書きはありませんが、想定用途としては CI パイプラインでの無人実行が主な対象のようですね。

全許可にしても保護される操作がある

capability: all にしても、Kiro がハードコードで保護しているパスがあります。
これらはユーザーの permissions.yaml でオーバーライドできません。

エージェントから書き込もうとしても deny になるパスは以下の通りです。

  • ~/.kiro/settings/ — 権限設定ファイル自体
  • ~/.kiro/workspace-roots/ — ワークスペース設定
  • ~/.kiro/sandbox-state/
  • ~/.kiro/web-session/
  • ~/.kiro/powers/installed/*/mcp.json

また、以下のパスは毎回 ask が出ます(全許可にしても抑制できない)。

  • .kiro/agents/** — エージェント定義ファイル
  • .kiro/hooks/** — フックファイル
  • .kiroignore
  • .git/**

つまりエージェントが自分の権限設定やエージェント定義を勝手にいじれないようになっていますね。

実際に検証してみると、capability: all に変更した後でも .kiro/agents/ 配下へのファイル書き込みには Ask が表示されました。

BA1B74DB-3ECD-4ED3-A4F3-5B972F49B876.png

また、ローカルスペースのファイル削除操作も Ask が出ました。
ドキュメントには明記を見つけられなかったのですが、削除も保護対象になっているみたいです。

さいごに

本日は Kiro IDE の permissions.yaml を capability: all + effect: allow に書き換えて、Agent Focus モードで Allow が出なくなるか試してみました。

350 行以上あった permissions.yaml が 3 行になり、Agent Focus セッションが Allow 待ちで止まることはほぼなくなりました。
ファイル削除やエージェント定義の編集だけは引き続き確認が出ますが、ここは仕方ないですね。

当然ながら全許可にすることで、意図しないシェルコマンドの実行やファイル上書きのリスクはあります。
今回は個人検証マシンで試しただけなので、このまま常用するかはもう少し様子を見てから判断しようと思います。
チーム開発やお客様環境を触るワークスペースでは、ワークスペース単位の permissions.yaml(~/.kiro/workspace-roots/<hash>/permissions.yaml)で制限をかけるのが良さそうですね。

しばらくこの設定で運用してみて、何か問題が起きたら追記します。

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事