[FEATURE] Artifacts: share with a group (IdP/SCIM group, HRIS team, or admin-defined org group) instead of adding individuals

Status Open
Maintainer reply None cached
Activity 2 comments · opened Sep 11, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

On Team and Enterprise plans, the artifact share dialog offers exactly two in-organization audiences: specific people or everyone in the organization (docs). There is no way to share with a group.

For a team that publishes artifacts constantly (in our case a security detection & response team producing on-call briefs, incident timelines, and coverage dashboards from Claude Code), this means:

  • Every new artifact requires adding each teammate by hand, one at a time. The same ten-or-so names get typed into every share dialog.
  • Access drifts. A new hire sees none of the existing artifacts until someone remembers to add them to each one; a leaver keeps access until someone removes them from each one.
  • "Everyone in the organization" is not an acceptable shortcut for security-sensitive content, so the choice is between over-sharing and repetitive manual work.

Enterprise role-based access control lets an Owner scope who may publish artifacts to roles, but nothing scopes who may view a given artifact to a group.

Proposed Solution

Let a group be a share principal in the artifact share dialog, alongside individual people, with the same viewer/editor role choice. Membership should be resolved when the page is viewed, so joiners and leavers are handled automatically without touching each artifact.

Any of these group sources would solve it, roughly in order of preference:

  1. Identity-provider groups via SCIM. Enterprise already supports SCIM provisioning. Groups pushed from Okta (or any SCIM IdP) should be selectable in the share dialog, so an Okta group or role maps directly to an artifact audience.
  2. HRIS-derived teams or departments. Where the org syncs people data from an HRIS such as Rippling, expose department or team as a selectable audience.
  3. Admin-defined groups. An org Owner or admin creates named groups in claude.ai admin settings (for example under Settings > Members, or a new Groups page) and members share artifacts with them. This needs no external integration and would cover Team plans too.

Nice-to-haves that fall out of the same model: the claude_artifact_* audit-log events record the group id when a group is added or removed, and "Shared with me" surfaces artifacts shared via a group the viewer belongs to.

Alternative Solutions

  • Share with everyone in the organization. Too broad for anything sensitive.
  • Keep adding individuals. Works, but scales with (artifacts x teammates) and drifts as membership changes. There is also no API for artifact sharing, so this cannot be scripted (the Compliance API lists and deletes artifacts but does not manage audience).
  • Publish elsewhere. Move the content to a tool with group-based access control, which defeats the point of artifacts.

Related but distinct requests: https://github.com/anthropics/claude-code/issues/70254 (programmatic share-with-org from headless sessions, closed as stale) and https://github.com/anthropics/claude-code/issues/84586 (external read-only viewers).

Priority

High - Significant impact on productivity

Feature Category

Other (Artifacts sharing on claude.ai)

Use Case Example

  1. An Owner maps the Okta group sec-detection-response into claude.ai (or creates an equivalent admin-defined group).
  2. A team member has Claude Code publish an on-call brief as an artifact.
  3. In the share dialog they add the group sec-detection-response as viewers. One action, done.
  4. A new analyst joins the Okta group the following week and can open every artifact already shared with the group. An analyst who leaves the group loses access to all of them at once.

Additional Context

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗