`--dangerously-skip-permissions` does not bypass plugin file edit confirmation prompt

Description

When running Claude Code headlessly with --dangerously-skip-permissions, editing plugin source files under ~/.claude/plugins/cache/ triggers a separate confirmation prompt that is not suppressed by the flag. This causes the process to hang indefinitely in non-interactive environments.

Steps to reproduce

1. Set up Claude Code as a systemd service with --dangerously-skip-permissions
2. Configure a Discord channel plugin (--channels plugin:discord@claude-plugins-official)
3. Set "skipDangerousModePermissionPrompt": true in settings.json
4. Wait for Claude to attempt an edit to a plugin source file (e.g., ~/.claude/plugins/cache/claude-plugins-official/discord/0.0.1/server.ts)

Expected behavior

The edit is auto-approved, consistent with all other tool permissions being bypassed by --dangerously-skip-permissions.

Actual behavior

A blocking confirmation prompt appears:

Do you want to make this edit to server.ts?
1. Yes
2. Yes, and allow Claude to edit its own settings for this session
3. No
Esc to cancel  Tab to amend

Since no interactive input is possible, the process hangs permanently. The Discord bot goes offline with no error logged — the service appears healthy (active (running)) but is unresponsive.

Environment

• Claude Code version: 2.1.81
• OS: Ubuntu 24.04.3 LTS
• Node.js: 20.20.1
• Launch command: /usr/bin/claude --channels plugin:discord@claude-plugins-official --dangerously-skip-permissions
• Settings: {"skipDangerousModePermissionPrompt": true, "enabledPlugins": {"discord@claude-plugins-official": true}}
• PTY wrapper: script -qec (required to avoid --print mode fallback)

Verification

• Launch Claude Code with --dangerously-skip-permissions and trigger a plugin file edit (e.g., via a prompt asking to modify server.ts in the plugin cache)
• The edit should proceed without any interactive prompt
• journalctl output should show no "Do you want to make this edit" prompt

Additional context

• The prompt text ("Yes, and allow Claude to edit its own settings for this session") suggests this is a distinct permission path from the normal tool permission system — likely a self-modification guardrail that doesn't check the --dangerously-skip-permissions flag.
• This is a significant reliability issue for any headless/daemon deployment. There is no way to detect or recover from the hang without external monitoring and service restarts.
• Workaround: instruct Claude via CLAUDE.md not to edit plugin files, but this is fragile.