Claude Desktopでstart_sessionがBypassでも確認を出す件と対処

Claude DesktopのCodeタブで権限モードをBypass permissionsにしていても、Claudeが start_session を呼ぶたびに「Allow Claude to start the session?」というダイアログが出ます。ボタンは Deny と Allow once の2つだけで、「常に許可」はありません。2026年10月20日ごろから複数の利用者が報告している挙動で、GitHubのissue #103832がopenのまま追っています。

start_session は、Claudeが別のセッションを立ち上げるためのDesktop内蔵ツール（ツール名は mcp__ccd_session__start_session）です。並列でヘルパーを走らせる運用や、長時間作業の引き継ぎで使われます。ここで確認が挟まると、無人運転の流れがその場で止まります。

どんな条件で、何が起きるのか

issueの再現手順は4ステップです。

initiation は、そのセッションを誰の意思で始めるかを示す引数です。user_asked はユーザーの依頼を受けて始める場合、own_initiative はClaudeが自分で提案する場合に使われます。issueによると、ダイアログはどちらの値でも出ます。

困るのは own_initiative の側です。この呼び出しは、それ自体では何も始めず、提案カードを出すだけです。カードのStartがすでに承認の役目を果たしているので、手前のダイアログは同じ承認をもう1回求めているだけになります。報告者の言い方では「1つのセッションに承認が2回」です。

カードの仕組みはClaude Code Desktopのタスクカードで扱っています。Startは別セッションを起動し、Do it hereは今のセッションに送る、という分担です。

報告から読み取れる時期と範囲

issueの本文によると、最初のダイアログは2026-10-20 16:13Zのログに残っていて、それ以前は同じやり方で毎日セッションを起動できていました。コメントの報告者ovitrifは、10月14日から21日までに約70個のヘルパーがダイアログなしで始まり、21日以降は毎回聞かれると書いています。起点の日付に1日ほどの差がありますが、1〜2週間前までは出なかった点はどの報告も一致しています。

環境は次のとおりです。

macOSだけの話ではありません。issueには platform:macos のラベルが付いていますが、Windowsでも同じダイアログが出ています。Desktopのバージョンが表のとおり大きく離れていても同じ挙動なので、特定の版だけの不具合とは言いにくい状況です。

効かなかった回避策と、効いた範囲

起票者が試した2つと、コメントで報告された1つ、計3つの手段が効きませんでした。

フックは、起票者が deny を返す分岐で動作を確かめています。つまりフックはこのツールに対して実行されます。ところが allow を返しても、ダイアログは消えません。

permissions.allow については、権限モードのドキュメントに「Allow rules have no effect in bypassPermissions」という記述があります。Bypass下でallowルールが意味を持たないのは仕様どおりで、このダイアログも権限システムの外側で出ていると考えるのが自然です。ただし、ダイアログを出している仕組みそのものは、Desktopのドキュメントに書かれていません。別のissue #105099には、この2つのツールが「常に確認」の設定で固定されているように見える、という報告者の推測があります。裏づける記述はないので、推測の域を出ません。

Desktopのドキュメントは、Bypass permissionsを「権限プロンプトなしで動く。ただし、どのモードでも自動承認されない操作と、外部サイトでの安全分類器、セッション削除のようなDesktop固有の操作を除く」と説明しています。例に挙がるのはセッション削除などで、start_session は載っていません。ドキュメントの説明と実際の挙動がずれている、というのがissueの立場です。

効く対処は「通らない呼び出しを先に落とす」だけ

ダイアログそのものを消す手段はありません。効くのは、通らない呼び出しの確認を省くことです。コメントのgeokaoは、ダイアログがアプリ側の入力検証より先に出るため、アプリが拒否する呼び出しでも先に聞かれると報告しています。cwd のフォルダ名に絵文字の異体字セレクタが入っていた例では、1つのセッションを始めるのにダイアログが3回出ました。最初の2回は許可した後で「cwd contains control or invisible characters」と拒否され、cwd を外した3回目だけが通っています。

PreToolUseフックはダイアログより前に走るので、この無駄なクリックは減らせます。構成例は次のとおりです。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "mcp__ccd_session__start_session",
        "hooks": [
          { "type": "command", "command": "python3 .claude/hooks/deny-invisible-cwd.py" }
        ]
      }
    ]
  }
}

import json, sys
 
data = json.load(sys.stdin)
cwd = (data.get("tool_input") or {}).get("cwd") or ""
# 制御文字(Cc)、書式文字の一部(Cf)、異体字セレクタ(U+FE00-FE0F)だけを対象にする
bad = [c for c in cwd
       if ord(c) < 32 or 0x7F <= ord(c) < 0xA0
       or ord(c) in (0x200B, 0x200C, 0x200D, 0x2060, 0xFEFF)
       or 0xFE00 <= ord(c) <= 0xFE0F]
if bad:
    print(json.dumps({"hookSpecificOutput": {
        "hookEventName": "PreToolUse",
        "permissionDecision": "deny",
        "permissionDecisionReason": "cwd に不可視文字が含まれています"}}))

濁点の結合文字などは対象から外してあります。日本語のフォルダ名を誤って弾かないためです。この例は報告された構成に沿ったもので、すべての不可視文字を網羅するものではありません。

運用への影響は「待ち」と「勘違い」

ダイアログが出ている間、セッションは「Needs your input」の状態で止まります。報告から出てくる実害は2種類です。

無人運転が止まります。コーディネーター役のセッションが、タスクごとにワーカーのセッションを起動する構成では、委譲のたびに利用者がアプリに戻るまで先へ進みません。ovitrifは1つのメインセッションあたり10〜20個のヘルパーを走らせていて、ヘルパーごとにクリックが要ると書いています。夜間や外出中に回す構成ほど影響が大きくなります。

始まっていないのに始まったと思い込む問題もあります。起票者は、ダイアログを許可したあとで「セッションが始まった」と思い込み、サイドバーに見当たらず、のちに提案カードが承認待ちのままだと気づきました。own_initiative では、ダイアログを通っただけでは何も起動していません。サイドバーにセッションが出ないときは、チャット内にカードが残っていないかを先に見ると切り分けが早くなります。

Bypass permissionsは、本来は確認を飛ばしてClaudeに任せるためのモードです。その前提で組んだ自動化が、モードの名前から想像する挙動と食い違う。この件の本質はそこにあります。Bypassの設定を信じて放置運転に入る前に、一度 start_session を通して、ダイアログが出るかを確かめておく価値があります。確かめる手間は数十秒で、夜間に全ワーカーが承認待ちで止まる事態を避けられます。

start_sessionをめぐる、もう一つの制約

確認ダイアログとは別に、start_session には「どの手番から呼べるか」の制約もあります。関連するissueが3つ立っています。

拒否されるときのメッセージは、「Start sessions only on the user's own words to you here」で始まります。ユーザー自身の言葉で依頼された手番だけが user_asked で通り、自動の手番では「提案する」（own_initiative）に切り替えるよう案内されます。

つまり、無人運転には2段のハードルがあります。自動の手番では user_asked が拒否されて own_initiative に落とされ、その own_initiative でもダイアログとカードの2回が要ります。#103407の報告者が使っている回避策は、ユーザーがいる手番で必要な数のセッションを先に作って待機させ、SendMessage の合図で動かす方式です。セッション数を事前に見積もる必要があり、余った分は無駄になります。

修正が出るまでの付き合い方

#103832のコメント4件はいずれも利用者の報告か催促で、修正方針を示す回答は付いていません。直る前提では待てないので、運用側で次の3点を決めておくと損が小さくなります。

• 無人運転にしない：start_session を使う作業は、利用者が画面の前にいる時間帯に回す
• 先に作って待機させる：人がいる手番でセッションをまとめて作り、合図で動かす
• 無駄な承認を減らす：入力が不正になりうる引数（cwd など）はフックで先に落とす

直ったかどうかは、Desktopの更新履歴で確かめられます。最新の状態はissue #103832で確かめられます。#105099のように「設定で消せるようにしてほしい」という要望も出ています。Bypassの設定どおりダイアログが出なくなるのか、専用の設定が追加されるのかで、取るべき運用は変わります。

Bypass permissionsの扱いに関しては、Bypass permissionsが無視される原因と直し方も参照してください。こちらはバックグラウンド実行で起きる別の挙動を扱っています。モードを起動時に有効化する仕組みは--allow-dangerously-skip-permissionsの挙動にまとめています。