coworkplugins
Guide

Claude Cowork plugin permissions: what they access

A Cowork plugin's access is not one switch. What connectors, local components and permissions each part can reach.

By Arun BabuBeginner

Installing a plugin is not handing over one key. What a plugin can actually touch is the sum of its components plus the permissions you grant, and those are different for every package. This guide breaks down the access layer by layer, using Anthropic's current docs and a real official package we inspected. Sources at the end.

Layer one: skills are instructions, not access

A skill is text that tells Claude how to do a task. Anthropic's official marketing plugin, for example, ships eight skills: brand-review, campaign-plan, competitive-brief, content-creation, draft-content, email-sequence, performance-report and seo-audit. On their own, those skills can only work on material you put in front of Claude. A skill describing how to write a performance report cannot read your analytics account by itself.

If a plugin were only skills, its access would be: nothing beyond the conversation.

Layer two: connectors reach your services

Connectors are where real access starts. The same marketing plugin includes an .mcp.json file pre-configuring MCP servers for Slack (with OAuth sign-in), Canva, Figma, HubSpot and Amplitude, among others. Its CONNECTORS file explains the model: plugins are tool-agnostic, written against categories like "marketing automation" or "SEO", and the included servers are defaults - any MCP server in the category can take their place.

What this means for access:

  • Each connector is a separate decision. The plugin suggests HubSpot; you choose whether to connect HubSpot, and you sign in yourself.
  • In Cowork, connectors reach services through Anthropic's cloud, so a custom connector must be reachable from Anthropic's IP ranges over the public internet.
  • On Team and Enterprise plans, an admin can require per-task approval for write-capable connector tools, and can disable auto-approve entirely.

A connected account still only exposes what that service's permissions allow.

Layer three: local components run on your computer

Some plugins bundle local MCP servers instead of cloud connectors. Those are different in kind, not degree: a local component executes on your machine through the Claude Desktop app (macOS or Windows), and Anthropic lists plugins with local MCP servers as desktop-only. A local component can potentially reach things a cloud connector cannot, like files on that computer.

This is the layer to inspect most carefully, especially in community packages: a manifest tells you a component exists, not what it does. The official repository being open source helps here - you can read the package before installing.

Layer four: Cowork's own powers

Separate from any plugin, Cowork itself can act. Anthropic's docs are direct about it: Claude has access to the local files you grant it permission to access, and can take real actions on your behalf, which is why you review planned actions before allowing them. Local file access, browser use and computer use all require the desktop app open and connected.

Plugins sit on top of that. A plugin's skill can ask Claude to use powers you have already granted Cowork, which is another reason the permission prompts deserve a read instead of a reflex click.

How to check a package before installing

  1. Read the inventory. Which skills, commands, connectors, sub-agents, hooks or local MCP servers are inside. Our plugin pages list components per package.
  2. Open the manifest. For packages with public source, plugin.json shows the name, version and author; .mcp.json lists the connectors it expects. The official repository is public for exactly this kind of check.
  3. Prefer known publishers for anything with local components. Official plugins are Anthropic-maintained; community packages vary. See official vs community.
  4. Connect services one at a time. Test the workflow on synthetic notes first, then connect only the service the task needs.
  5. Watch the first run's permission prompts. They show what the plugin actually asks for, which is the truth over any README.

Our plugin security guide goes deeper on malicious-package signals, and plugins vs skills vs connectors explains the component types themselves.

Sources

Read more