[FEATURE] Team/group-scoped managed settings: per-team CLAUDE.md, permissions, and skills within an org

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 26, 2026

Feature request

Allow enterprise admins to scope managed settings, CLAUDE.md instructions, and skills/plugins to teams or groups within an organization, instead of one org-wide blob.

Problem

Server-managed settings (claude.ai admin console) currently deliver a single configuration to every Claude Code session in the org. That is perfect for universal guardrails (permission deny rules, company writing style), but organizations have teams with very different needs:

  • Engineering needs rich context: architecture tables, repo conventions, infrastructure guardrails, domain skills.
  • Non-engineering Claude Code users (ops, support, sales engineers) should not carry that content in every session. It wastes context tokens and can be confusing or irrelevant.
  • Some instructions should be enforced for one team but not exist for another (for example, production read-only CLI rules for the platform team).

Current workaround

We centralize an engineering CLAUDE.md in a git repo and each engineer adds an @path import line to their personal ~/.claude/CLAUDE.md. This works but is opt-in: membership is defined by who remembered to add the line, there is no enforcement, and a misconfigured machine silently loses the whole layer. Skills have the same problem: they are discovered per-directory, so team-wide skill distribution relies on symlinks or plugin installs that each user must perform.

Proposal

In Admin Settings > Claude Code, allow managed settings entries to target a group/workspace (reusing the existing claude.ai workspace or group concepts):

  • Per-team claudeMd content, layered on top of the org-wide block.
  • Per-team permissions (deny/allow) and hooks.
  • Per-team skill/plugin assignment so members automatically get the team's skills on login, kept up to date.
  • Precedence: org-wide managed > team managed > user/project/local, with deny rules merging across levels.

Impact

This would let enterprises truly enforce differentiated Claude behavior across teams, replace fragile per-user import conventions, and make team onboarding zero-step: log in, get your team's instructions, guardrails, and skills.

Context: we are an industrial IoT platform company rolling out org-wide guardrails via managed settings today; the single-scope limitation is the one gap forcing us to keep a parallel opt-in distribution mechanism for engineering context.

View original on GitHub ↗