The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Manage Claude Code plugins as executable code, not just add-ons: check their source and components, limit the permissions they can use, and review the settings that apply to each session. Plugins can include hooks that run commands and MCP servers that connect to external services; Anthropic’s warning is direct: “what the plugin runs, it runs as you.”
Understand what a plugin adds to a session
A Claude Code plugin is a directory of components installed and loaded as a unit. Its manifest is .claude-plugin/plugin.json. Depending on the plugin, it can include skills, agents, hooks, and MCP servers: skills provide instructions, agents define subagents, hooks run commands at lifecycle events, and MCP servers connect Claude Code to tools and services. See Anthropic’s plugin documentation.
An enabled plugin affects every session, not only the task that led you to install it. Its skill, agent, and command names and descriptions use context; configured MCP servers run alongside sessions; and hooks run when their events occur. Review the components before enabling a plugin, with particular attention to commands and network-connected integrations. Disable plugins you no longer need.
Do not treat marketplace availability as a security endorsement. The official marketplace is added by default in ordinary interactive terminal use unless managed policy blocks it, but third-party marketplaces and local plugin folders are also possible. Check the origin of each plugin and inspect what it installs.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
Review and narrow Claude Code permissions
Run /permissions to see the active rules and the settings file each rule came from. Claude Code supports allow, ask, and deny rules. Its evaluation order is deny, then ask, then allow, so a narrower allow does not override a matching deny. Use the permissions reference to check the current syntax and behavior for your version.
Prefer a rule for the exact operation or resource needed over allowing an entire tool. For example, Bash(npm run build) matches a specific command, Read(./.env) matches a file, and WebFetch(domain:example.com) matches a domain. A bare Bash deny removes that tool from Claude’s context; a scoped rule such as Bash(rm *) leaves the tool available while blocking matching calls.
Rank #2
Permission rules—not prompt text or CLAUDE.md instructions—enforce tool access. Instructions can shape requests, but they do not grant or restrict access in place of permission rules. After approving an action with “Yes, and don’t ask again,” check /permissions: the approval may have created a persistent allow rule in project-local settings. Review saved approvals periodically, especially after changing plugins.
Choose a permission mode for the environment
Permission modes change how Claude Code handles actions. They do not make an untrusted plugin trustworthy. Choose a mode based on the work and the consequences of actions in the current environment.
| Mode | What it does | Practical consideration |
|---|---|---|
default |
Asks before first use of each tool. | Provides prompts at tool use; assess each request in context. |
acceptEdits |
Automatically accepts file edits and common filesystem commands within the working directory or additional directories. | Use only where automatic edits in those locations are acceptable. |
plan |
Allows read-only exploration without editing source files. | Useful when exploration is wanted but source edits are not. |
auto |
Runs without routine prompts, with a background classifier checking actions such as shell commands and network requests when this mode is available. | Availability and behavior are version-sensitive; confirm in the current documentation. |
dontAsk |
Automatically denies actions that would otherwise prompt, while retaining permitted actions. | It is not the same as granting broad access without prompts. |
bypassPermissions |
Skips permission prompts. | Anthropic recommends it only in isolated environments such as containers or VMs where Claude Code cannot cause damage. Managed settings can disable it. |
The CLI flag --dangerously-skip-permissions is equivalent to --permission-mode bypassPermissions. Avoid it on a developer machine or sensitive working tree just to reduce prompts. See the CLI reference and permission mode documentation.
Put settings at the right scope
Claude Code reads settings from user, project, and managed scopes. Choose the scope according to who needs the policy and whether it should be shared or enforced. The settings documentation describes the files and precedence.
Rank #4
| Scope | File or source | Use it for |
|---|---|---|
| User | ~/.claude/settings.json |
Preferences and rules for one user across projects. |
| Shared project | .claude/settings.json |
Team policy intended to be committed and shared, including permissions, hooks, plugins, and required environment settings. |
| Project-local | .claude/settings.local.json |
Personal settings for one project; keep it uncommitted. |
| Managed | Deployed by the organization | Organization-wide security or compliance policy. Local files generally cannot override managed settings. |
For team settings, commit only what the team intends to share and review the changes like code. Repository settings take effect in the context of workspace trust. Keep personal credentials out of shared project configuration. Use /status to check policy sources.
Assess MCP servers as external access
An MCP server can expose tools connected to external services, databases, or APIs. A plugin may configure a server that runs whenever the plugin is enabled. Before trusting one, review its publisher, code or endpoint, requested credentials, and available operations; grant only the access needed. Anthropic says it has not verified the correctness or security of every third-party MCP server and warns about prompt injection when servers retrieve untrusted content. Read the MCP documentation alongside the plugin’s own details.
A project-scoped server declared in .mcp.json is intended to be shared with a repository. Claude Code prompts for approval before using it in an interactive session, but non-interactive and certain bypass-mode sessions cannot show the same prompt. Review the committed file and the policy for automated runs rather than relying on an interactive approval prompt to protect every use.
Quick Recap
Use this review sequence before enabling a plugin
- Identify its origin. Determine whether it comes from the official marketplace, another marketplace, or a local directory; marketplace presence alone is not a security guarantee.
- Inspect the manifest and components. Read
.claude-plugin/plugin.jsonand identify its skills, agents, hooks, and MCP servers. - Examine actions and connections. Read hook commands and inspect MCP endpoints, requested credentials, and exposed operations.
- Enable only what is needed. Install or enable components for the task and disable plugins that are not in use.
- Check effective rules. Set narrowly scoped
allow,ask, anddenyrules, then run/permissionsto review the result and its source. - Set policy at the right scope. Put reviewed team rules in shared project settings or use managed settings for enforced organizational policy; keep personal settings local.
- Reserve bypass mode for isolation. Use
bypassPermissionsonly in a container or VM isolated from anything Claude Code should not be able to affect.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
