PaPoo
cover

Permission denied が出るときにまず見るところ

Claude Code で Permission denied が出る話は、今回の issue 群だと 2 つの顔があります。ひとつは SSH 越しのセッションが再起動後におかしくなるケース、もうひとつは MCP 経由でページ操作が拒否されるケースです。どちらも同じ文言に見えますが、症状の出方はかなり違います。

SSH 側は #72335 です。報告では、デスクトップアプリで SSH セッションを使っていると、再起動後に過去のセッション履歴が空白になったり、SSH セッションの fork/branch が失敗したりします。報告されている根本原因は、過去セッションを開くときにデスクトップアプリが 2 つの SSH 処理を走らせ、そのうち byte-sync は SSH config のエイリアスを使う一方、tail 側が raw IP に接続してしまう、というものです。こちらは issue 本文が途中で切れているため、tail 側の接続先の詳細は分かりません。少なくとも、報告者は「byte-sync は動くが tail が壊れる」という切り分けをしています。

今回の検証環境で実際に確認できたのは CLI 側の MCP まわりです。Claude Code のバージョンは次のとおりでした。

$ claude --version
2.1.207 (Claude Code)

MCP サーバ管理のサブコマンド自体は存在しました。

$ claude mcp --help
Usage: claude mcp [options] [command]

Configure and manage MCP servers

Options:
  -h, --help                            Display help for command

Commands:
  add [options] <name> <commandOrUrl> [args...]  Add an MCP server to Claude Code.
  
  Examples:
... (以下 33 行省略)

登録済み MCP サーバは、少なくともこの環境では次の 3 つが見えました。

$ claude mcp list
Checking MCP server health…

claude.ai Google Drive: https://drivemcp.googleapis.com/mcp/v1 - ✔ Connected
claude.ai Gmail: https://gmailmcp.googleapis.com/mcp/v1 - ✔ Connected
claude.ai Google Calendar: https://calendarmcp.googleapis.com/mcp/v1 - ✔ Connected

ただし、ここから先の「Permission denied」系の原因を、この出力だけで断定することはできません。#43255 の報告では、Claude in Chrome の MCP ツールで Navigation to this domain is not allowedPermission denied for reading pages on this domain が出ます。最初の 1 ドメインは通るのに、同じセッションで別ドメインへ移ろうとすると、許可プロンプトが出ないまま弾かれる、というコメントが付いていました。つまり、読者の手元で次のような動きなら、#43255 の系統を疑う余地があります。

最初のドメインでは許可が出る。ところが同じセッションで別ドメインに行くと、Permission deniedNavigation to this domain is not allowed が即座に返る。しかも、許可を求める画面が出てこない。

issue コメントでは、一時回避として Cowork モードの承認設定を Ask for approval から Request approvals に変えると動いた、という報告がありました。ただし別のコメントでは、これは Cowork 側に限られるかもしれないとも書かれています。さらに別のコメントでは、CLI 側が permissionMode: "follow_a_plan" を extension に送っており、turnApprovedDomains の状態が残るために他ドメインがブロックされる、という推測も出ています。ここは報告ベースの話で、筆者の環境では確認していません。したがって、現時点で言えるのは「同じ Permission denied でも、SSH のセッション破損と、MCP のドメイン承認拒否は別筋で見るべき」というところまでです。

手元の環境で見えている設定構造は、少なくとも ~/.claude/settings.jsonpermissionseffortLevelvoiceEnabledmodelhooks があることでした。値までは出していませんが、キーの存在だけは確認できています。

[settings_structure]
~/.claude/settings.json:
  permissions: object
    allow: array[73]
    additionalDirectories: array[3]
  effortLevel: str
  voiceEnabled: bool
  model: str
  hooks: object
    Stop: array[1]
      hooks: array[1]
        ...
    PermissionRequest: array[1]
      hooks: array[1]
        ...
    PreToolUse: array[1]
      hooks: array[1]
        ...
      matcher: str
    UserPromptSubmit: array[1]
      hooks: array[1]
        ...
    SubagentStop: array[1]
      hooks: array[1]
        ...
~/git/papoo/newsbot_openai/.claude/settings.json: (存在しない)
~/git/papoo/newsbot_openai/.claude/settings.local.json: (存在しない)

この段階でできる切り分けはかなり単純です。SSH 越しの過去セッションが空白になる、fork が失敗するなら #72335 の系統。MCP の navigateread_page が、最初は通るのに次のドメインで急に Permission denied になるなら #43255 の系統です。どちらも、少なくとも今回の issue 報告では「ユーザー操作で何とかなる」というより、実装側の状態管理に寄っていそうです。


検証環境

claude --version : 2.1.207 (Claude Code)
OS          : Darwin 25.3.0 (arm64)
Python      : 3.14.2
検証日時    : 2026-08-10T12:36:31+09:00

参照した Issue(anthropics/claude-code): #43255, #72335

同じ著者の記事