Cowork group plugin assignment: the admin picks install behavior per group, "Required" locks it, and group targeting is Enterprise only

The question

"Does assigning a Claude Cowork plugin to a user group auto-install it for group members or only add it to their plugin directory, can an admin lock a group-assigned plugin so members can't disable it, and is group-to-plugin assignment available on the Team plan or Enterprise-only?"

Context: open follow-ups 1 and 2 from [[2026-09-15-anthropic-skills-per-role-enablement-scoping]]. The answer decides whether the Organizational Intelligence (OI) role-pack plugins (oi-presales, oi-delivery) can be admin-enforced for phData's ~60 sales users and ~12 engineers, or only default-provisioned with a user opt-out.

What we already know (from the vault)

• The parent brief left enforcement open. [[2026-09-15-anthropic-skills-per-role-enablement-scoping]] found that the plugin is the unit of group scoping in Cowork, and that org-uploaded skills can be switched off by users with "no admin lock" described. It concluded "'Enable narrow' is enforceable. 'Always present' is not." That conclusion was drawn from the skills provisioning article. The plugins article (below) changes it.
• The June brief already had the four levels, but they were never carried forward. [[2026-06-10-claude-code-plugin-private-distribution]] summarized the same Help Center article in June: "Required (auto-deploy, no uninstall), Installed by default (auto-deploy, can uninstall), Available for install (self-service), Not available (hidden). Group-level overrides apply; most-permissive setting wins." It did not record the plan split. The September brief did not cite it. This brief re-verifies the article against its current version (modified 2026-09-04).
• One plugin spans both rails, but org marketplace distribution does not. [[2026-07-09-anthropic-plugin-ecosystem-vs-rdco-brigade-plugins]] found that one plugin format installs in Cowork and Claude Code. The org-marketplace article below scopes distribution to chat and Cowork only. Claude Code enforcement still runs through managed settings (see the parent brief).

What the web says

All quotes are from the current Help Center pages, fetched 2026-09-19.

• Group assignment does not have one fixed behavior. The admin picks one of four installation preferences for each group. "Enterprise admins can override a plugin's organization-wide installation preference for specific groups. For example, you can auto-install a plugin for the Engineering group, make it available for Legal to install on their own, and hide it from everyone else." The four preferences are (Manage plugins for your organization, dateModified 2026-09-04):
  • Installed by default: "Automatically installed for all org members ... The plugin appears in their installed list without any action. Members can uninstall if they choose."
  • Available for install: "Listed in the plugin catalog. Members see it when browsing plugins and can install it themselves."
  • Not available: "Hidden from the catalog entirely. Members can't see or install the plugin."
  • Required: "Automatically installed for all org members without the option to remove it. The plugin appears in their installed list without any action and cannot be disabled or uninstalled."
• A group setting replaces the org-wide setting, and the most permissive setting wins across groups. "When you set a group-level override for a plugin, it replaces the org-wide setting for members of that group. The resolution order is: group setting, then org-wide setting, then marketplace default." And: "If a member belongs to two or more groups with different settings for the same plugin, the most permissive setting applies. The order from most to least permissive is: Required > Installed by default > Available for install > Not available." (same article)
• Group targeting is Enterprise only. The four preferences at org-wide scope are on Team too. "Plugin marketplaces let Team and Enterprise plan owners distribute curated plugins to everyone in their organization." But: "Group-level plugin access is available on Enterprise plans and configurable by Admins and above." Both manually created groups and SCIM-provisioned groups (SCIM is System for Cross-domain Identity Management, the sync from an identity provider such as Okta or Entra) "appear in the group picker and work the same way." (same article)
• Members cannot edit org-managed plugins, and the member-side article confirms the lock. "Members can't edit organization-managed plugins, which prevents conflicting changes to shared tooling." (same article). The member-facing article says: "You can uninstall auto-installed plugins if you don't need them, but required plugins can't be removed." (Use plugins in Claude, dateModified 2026-09-15)
• Scope and prerequisites. "Plugins you distribute appear in both chat (on the web and the Chat tab in Claude Desktop) and Claude Cowork." "Cowork and Skills must both be enabled for your organization before you can use plugin marketplaces." Changes "take effect on each member's next session or plugin refresh." Limits: 100 plugins per manually managed marketplace, 500 per GitHub-synced marketplace, and the GitHub repo must be private or internal. (Manage plugins for your organization)
• Separate mechanism, easy to confuse. Member-to-group sharing ("Share with groups" under Organization settings > Skills > Policy) is a different path. It lets a member share a plugin they built. It is not admin assignment and carries no installation preference. (Use plugins in Claude)

Convergences and contradictions

• Contradiction with the parent brief, resolved in favor of the plugins article. The September brief said Cowork has no admin lock. That holds for loose skills uploaded org-wide. It does not hold for plugins distributed through the org marketplace: the "Required" preference "cannot be disabled or uninstalled." The parent brief's "'Always present' is not [enforceable]" should be read as "not enforceable for loose skills; enforceable for plugins."
• Convergence with the June brief. The four-level model and most-permissive-wins rule match what [[2026-06-10-claude-code-plugin-private-distribution]] recorded in June. The plan split (group overrides Enterprise only, "Admins and above") is new in this read.
• Documented, implied, unknown.
  • Documented: four preferences, per-group override (Enterprise), Required = no disable or uninstall at the plugin level, most-permissive resolution, SCIM groups supported, chat + Cowork scope.
  • Implied: a Team org can still lock a plugin with Required, but only for the whole organization. Team has no group override, so role targeting on Team means everyone gets both packs or nobody does.
  • Unknown: whether a member can switch off individual skills inside a Required plugin. The skills provisioning article lets users turn off individual provisioned skills, and neither plugin article says whether that toggle is removed for skills that arrive through a Required plugin. This can only be settled in a live admin console (test plan below).

Synthesis for RDCO

Answers to the three sub-questions. (1) Neither by default: the admin chooses. A group override can set Installed by default (auto-install, removable), Available for install (catalog only), Required (auto-install, locked), or Not available (hidden). (2) Yes. "Required" at the group level means members of that group get the plugin with no option to disable or uninstall it. (3) Group-to-plugin assignment is Enterprise only. Team plan owners can set the same four preferences, but only org-wide.

What this changes for OI. The parent brief's verdict ("build narrow, assign by group") stands, and the enforcement gap it flagged closes at the plugin level. On an Enterprise org, the recommended configuration is: set oi-presales and oi-delivery org-wide to Not available, then add a group override of Required for the sales group on oi-presales and for the engineering group on oi-delivery. Members outside both groups see neither. Because the org-wide default is hidden and the group setting replaces it, the lock applies only where we want it. "Admin-enforced", not just "default-provisioned", is the documented capability.

Two design consequences of the most-permissive rule. First, a person in both groups (a solutions architect who sits in sales and engineering groups, for example) gets both packs locked on. The rule has no "deny wins" option, so a pack cannot be kept off a person through one group while another group grants it. Group membership hygiene is the control, not the plugin setting. Second, "Required" is also the most permissive level, so any group set to Required wins over every other group's setting for that person. Use Required for the one pack per role, and Installed by default or Available for install for optional add-ons, so that stacking memberships stays predictable.

What stays unresolved, and where it bites. The lock is documented at plugin granularity. If individual-skill switches survive inside a Required plugin, a salesperson could still switch off the router skill, and "always present" would hold only for the plugin shell. That is the one point to confirm before we tell phData the packs are enforced. Also, this whole mechanism covers chat and Cowork only. The ~12 engineers on Claude Code still need managed-settings enabledPlugins (which the Claude Code docs also describe as non-disableable) or per-repository settings, as the parent brief laid out. If phData were on Team rather than Enterprise, role targeting would collapse to org-wide Required for both packs, and the July brief's 15-to-20-skill active surface per user would be lost. So the plan tier is a precondition to confirm with the phData admin, not an assumption.

Test plan (live admin console, Enterprise org).

1. Create two groups, A and B, and a test plugin with at least two skills. Set the plugin org-wide to Not available. Set a group-A override to Required. Confirm a group-A member sees the plugin installed with no uninstall or disable control, and a group-B member does not see it in the catalog.
2. As the group-A member, open Customize > Skills and check whether individual skills from the Required plugin show an on/off toggle. If they do, switch one off and confirm whether it stops triggering in Cowork and in chat.
3. Add the group-B member to group A as well, with group B set to Not available. Confirm the plugin arrives as Required (most-permissive rule).
4. Change the group-A override from Required to Installed by default while the member has the plugin installed. Record whether it stays installed and whether an uninstall control now appears after the next session or refresh.
5. Repeat step 1 with a SCIM-provisioned group to confirm identity-provider groups behave the same as manual ones.
6. On a Team org (if one is available), confirm the "Custom access" column and "Add groups" control are absent.

Why this is in the vault

This settles what RDCO can promise phData about the OI role-pack rollout: sales and engineering packs can be locked on per group in Cowork on an Enterprise org, but not on Team. It also corrects the "no admin lock" statement in [[2026-09-15-anthropic-skills-per-role-enablement-scoping]] before that statement reaches a deployment plan.

Open follow-ups

• Does Anthropic's Enterprise Admin API (the "Claude Enterprise Admin API reference guide" listed in the Help Center) expose plugin installation preferences and group overrides, so role-pack assignment could be scripted instead of set by hand in the console?
• Does a plugin's org-marketplace installation preference propagate to Claude Code sessions for the same user, or is the documented chat-plus-Cowork scope a hard boundary that forces a parallel managed-settings configuration for engineers?
• When a Required plugin is updated through GitHub sync, can an admin pin members to a version, or does every member get the new version on "next session or plugin refresh" with no staged rollout?

Related

• [[2026-09-15-anthropic-skills-per-role-enablement-scoping]] - parent brief; this closes its follow-ups 1 and 2 and corrects its "no admin lock" statement
• [[2026-06-10-claude-code-plugin-private-distribution]] - first recorded the four installation levels in June; Claude Code managed-settings lockdown
• [[2026-07-09-anthropic-plugin-ecosystem-vs-rdco-brigade-plugins]] - one plugin format across Cowork and Code
• [[2026-07-07-claude-skill-count-degradation-skill-packs]] - the 15-to-20-skill active surface that group targeting protects
• [[2026-07-08-cowork-industry-plugins-vs-caf-delivery]] - Cowork plugin positioning against OI delivery

Sources

• Vault: [[2026-09-15-anthropic-skills-per-role-enablement-scoping]]
• Vault: [[2026-06-10-claude-code-plugin-private-distribution]]
• Vault: [[2026-07-09-anthropic-plugin-ecosystem-vs-rdco-brigade-plugins]]
• Vault: [[2026-07-07-claude-skill-count-degradation-skill-packs]]
• Vault: [[2026-07-08-cowork-industry-plugins-vs-caf-delivery]]
• Web: Claude Help Center - Manage plugins for your organization (https://support.claude.com/en/articles/13837433-manage-plugins-for-your-organization), dateModified 2026-09-04, fetched 2026-09-19
• Web: Claude Help Center - Use plugins in Claude (https://support.claude.com/en/articles/13837440-use-plugins-in-claude), dateModified 2026-09-15, fetched 2026-09-19
• Web: Claude Help Center - Provision and manage skills for your organization (https://support.claude.com/en/articles/13119606-provision-and-manage-skills-for-your-organization), via the parent brief, not re-fetched
• Web: search-result listing only, not fetched - Manage groups and group spend limits on Enterprise plans (https://support.claude.com/en/articles/13799932-manage-groups-and-group-spend-limits-on-enterprise-plans); Cowork and plugins for teams across the enterprise, Anthropic blog (https://claude.com/blog/cowork-plugins-across-enterprise)