Claude Media
initialPermissionModeが効かない不具合 — code-serverで承認が復活
Claude CodeTips

initialPermissionModeが効かない不具合 — code-serverで承認が復活

VS Code拡張・code-serverのClaude Codeで、拡張の更新後にinitialPermissionModeやbypassPermissionsが効かず毎回承認を求められる報告の中身と、設定・ログの確かめ方をまとめました。

読了目安 約8分

claudeCode.initialPermissionMode を bypassPermissions にしているのに、VS Code拡張やcode-serverのClaude Codeが毎回ツールの承認を求めてくる。そんな報告が、GitHubのanthropics/claude-codeリポジトリのissue #85077にあります。issueは area:ide ラベル付きで、まだ閉じていません。

先に整理すると、これは設定の書き間違いではなく、拡張側の挙動を疑う報告です。ただし原因の分析は報告者がminify済みのコードを追って出したもので、Anthropicによる確認ではありません。この記事では、報告の中身、公式docsが定める本来の決まり方、手元で切り分ける手順を順に扱います。

issue #85077で報告されている症状

報告者の環境は、code-server 4.115.0、拡張 anthropic.claude-code 2.1.226、Linux x86_64です。~/.claude/settings.json に permissions.defaultMode: "bypassPermissions"、VS Codeの設定に次の2つを入れています。

  • claudeCode.initialPermissionMode: "bypassPermissions"
  • claudeCode.allowDangerouslySkipPermissions: true

拡張が2.1.225から2.1.226に自動更新されたあと、開いたままのタブだけでなく新しいタブでも、全ツール呼び出しで承認を求められるようになったといいます。設定画面の値は変わっていないので、更新後に突然壊れたように見えるのが厄介な点です。

拡張のログ（Claude VSCode.log）には、同じ拡張ホスト・同じ設定でもタブごとに起動時のモードが違う様子が残っていました。

permission mode: bypassPermissions, resume: <sessionA>
permission mode: undefined,          resume: <sessionB>
permission mode: undefined,          resume: undefined

3行目は resume: undefined なので、再開ではない新規会話です。新規でも undefined で起動した、というのが報告の核心です。

報告者が挙げた原因は3つ

issueは、拡張の同梱コードを追った結果として3点を挙げています。いずれも報告者の推測であり、公式の説明ではありません。

仮説

報告者が示した原因の仮説

  • 復元経路で初期値が入らない

    タブを復元・再開する経路では、会話ごとの権限モードが undefined のままになり、initialPermissionMode の値で埋められない。

  • undefinedが明示的に渡される

    起動時のメッセージに permissionMode のキーが空のまま入るため、CLI側が ~/.claude/settings.json の permissions.defaultMode を引く処理も効かなくなる、という見立て。

  • 一度きりの消去処理

    初回起動時に、保存済みの権限モードをglobalStateから一度だけ消す移行処理が走り、その後は設定から再導出されない。報告者の環境では2.1.226への自動更新で初めて動いたとしている。

2つ目には裏付けも添えられています。同じ --setting-sources user,project,local でパッケージ済みの claude バイナリを直接起動し、--permission-mode を付けなければ、bypassPermissions に解決されて承認は出なかったそうです。CLI単体は正常で、拡張がSDK経由で起動する経路だけが怪しい、という切り分けです。

再現手順も短く、bypassPermissions を設定してタブで作業し、ウィンドウの再読み込みかcode-serverの再接続を挟んで戻ると、そのタブで承認が復活する、というものです。タブを裏に回して戻すだけでも起きうるとされています。

公式docsでは起動時のモードがこう決まる

不具合かどうかを判断するには、まず本来の決まり方を知っておく必要があります。権限モードのページによると、VS Code拡張は新しい会話を始めるとき、次の順で最初に当てはまるものを採ります。

  1. claudeCode.initialPermissionMode
  2. モード指示器で最後に選んだモード（Manual・Edit automatically・Autoの場合。PlanとBypass permissionsは、その会話だけに効く）
  3. 管理設定または ~/.claude/settings.json の permissions.defaultMode
  4. プラン・プロバイダ・組織設定に応じた組み込みの既定値

この順に従えば、1つ目が bypassPermissions なら新規会話はBypassで始まるはずです。issueの「新規でも undefined」は、この仕様から外れた挙動に当たります。

仕様側で見落としやすい条件も、docsに書かれています。

  • 拡張は、プロジェクトの .claude/settings.json や .claude/settings.local.json を、開始時の権限モードのために読みません
  • bypassPermissions を使うには、拡張設定のAllow dangerously skip permissionsがオンである必要があります。オフだと、1番や3番の値が bypassPermissions でも会話はManualで始まります
  • claudeCode.claudeProcessWrapper を設定していると、3番と4番は効きません。1番か2番がなければManualで始まります
  • VS Codeは initialPermissionMode をユーザー設定から読み、ワークスペースの値は無視します。v2.1.225より前は既定値が default で、ワークスペースの値も適用されていました

最後の点は見逃しやすく、v2.1.225の前後で挙動が変わっています。報告された不具合は2.1.225から2.1.226への更新で起きたとされます。ワークスペース側に書いていた設定が効かなくなった場合は、この仕様変更が原因かもしれず、別物として切り分けます。設定項目の全体像はVS Code拡張の設定ガイドにあります。

自分の環境で切り分ける

原因が仕様の変更か、報告された不具合かは、次の順に確かめると絞れます。

切り分け

承認が毎回出るときの切り分け

  1. QallowDangerouslySkipPermissions がオンで、initialPermissionMode が「ユーザー設定」にあるか?
    答えがいいえのとき

    ワークスペース設定に書いていないか、Allow dangerously skip permissionsがオフでないかを直します。v2.1.225以降、ワークスペースの値は読まれません。

    答えがはい
  2. QclaudeProcessWrapper を使っていないか?
    答えが使っている

    ラッパー使用時は permissions.defaultMode の経路が効かず、1番か2番が頼りになります。initialPermissionMode を明示します。

    答えがはい
  3. Q新規タブでもログに permission mode: undefined と出るか?
    答えが出ない

    出ないなら、設定側かタブごとの選択の影響です。タブのモード指示器を確認してください。

    答えがはい

issue #85077と同じ症状の可能性

設定が正しいのに新規タブでも undefined なら、報告された不具合に当たります。後述の回避策に進みます。

ログは、拡張ホストごとのディレクトリに Claude VSCode.log として出ます。場所は環境で違うので、探してから permission mode の行を見ます。

find ~ -name "Claude VSCode.log" 2>/dev/null
grep -h "permission mode:" "<見つかったログのパス>" | tail -n 10

パスのホーム以下は、ユーザー名が出る場合があります。ログを貼って報告するときは伏せてください。

見つかっている回避策

issueには、プロジェクト全体で恒久的に直す手段は見つからなかったとあります。報告者が挙げた手立ては、影響を受けたタブごとに、モード指示器からBypass permissionsを選び直すことでした。

Bypass permissionsは、公式docsでも会話単位の扱いが明記されています。モード指示器で選んだBypassは、その会話だけに効きます。つまり選び直しは設定の再読み込みではなく、タブごとの手動の復旧です。

もう一つの補強として、~/.claude/settings.json の permissions.defaultMode も入れておく手があります。3番の経路が生きている環境では、initialPermissionMode が効かないときのバックアップになります。ただしissueの2つ目の仮説のとおりなら、undefined が明示的に渡るタブではこの経路も止まる可能性があります。必ず効く保証は公式にありません。

Bypassを使い続ける場合は、権限の安全側の条件も忘れずに確認してください。公式は、この設定をネットワークのない隔離環境で使うよう案内しています。権限モード全体の考え方はClaude Code権限モデルの変遷に、起動時にモードを固定する方法は--permission-modeの解説にまとめています。

設定が未指定のときの既定値にも注意

更新履歴では、v2.1.284で、権限モードが未指定の対話セッションを「VS Codeを含めてautoモードで開始する」変更が入りました（permissions.defaultMode があればそれが優先）。以前の挙動とは起動時のモードが変わりうるため、設定が空のまま undefined になったタブでの見え方も、バージョンによって違う可能性があります。

状況を報告するときは、拡張のバージョン、initialPermissionMode の置き場所（ユーザー設定かワークスペースか）、allowDangerouslySkipPermissions の値、ログの permission mode: 行をそろえておくと、issueで再現条件を共有しやすくなります。

VS Code拡張で似た「更新後に設定が効かない」系の不具合には、MCP elicitationが自動辞退される件もあります。拡張自体が応答しないときは、応答しないときの切り分け手順が出発点になります。

まとめ

issue #85077は、設定が正しくても、復元や再接続を経たタブで権限モードが undefined になり、承認が復活するという報告です。原因は報告者の分析で、Anthropicの確定情報ではありません。

手元では、まず設定の置き場所とAllow dangerously skip permissionsの状態を確認し、そのうえでログの permission mode: 行を見ます。設定が正しいのに新規タブでも undefined なら、報告と同じ症状です。当面の手立てはタブごとの選び直しで、issueが閉じるまでは、拡張の更新後にモードを見直す習慣が役に立ちます。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →