Allow an artifact's audience to be set programmatically when publishing from Claude Code

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

Artifacts published from Claude Code are private at birth, and there is no
programmatic way to change that. The only mechanism is a human opening the
Share dialog on claude.ai, per artifact.

That makes automated publishing a half-capability: an agent can create a page
but can never make it readable by the people it was created for.

Verified on Claude Code 2.1.274:

• The Artifact tool has actions publish / list / read / delete / open / pin /

unpin / quickstart. None sets an audience, and publish has no visibility
parameter.

• ArtifactComments has read / reply / resolve / watch. No sharing action.
• There is no org-level default. Our admin confirmed the setting at

Settings → Capabilities → Artifacts is enabled; its description
("...and share chat and Cowork artifacts with your organization") reads as
though it does more, but it only grants permission to share — a newly
published artifact is still private.

• There is no Claude Code setting or environment variable for it.
• Claude Docs have the same model — the docs connector's own guidance says

"a doc not shared with you → its owner shares it".

Empirically: an artifact published by claude -p read back as private on
publication and was still private three days later, untouched.

The gap is sharpest against a feature Claude Code already ships. Publishing an
artifact arms a watch, and ArtifactComments can read, reply to and resolve
comment threads — a complete automated review loop. But the artifact cannot be
made commentable without a human in a browser, so that loop cannot be entered
automatically.

It is worse for service accounts. An artifact owned by an unattended account
is unshareable by construction: nobody signs in to click Share.

Proposed Solution

A way to set an artifact's audience without a browser. In rough order of
preference:

1. A parameter on Artifact publish — e.g. `audience: "private" |

"organization"`, defaulting to "private" so nothing changes for existing
callers.

Preferred because it is atomic. Any post-publish mechanism leaves a window
where the artifact exists and is unreadable, and an agent that crashes
between the two steps leaves it that way permanently.

1. A share action on the Artifact tool, taking a url and an audience.

Useful on its own for artifacts published earlier.

1. An org-level default — "artifacts created by members of this organization

default to organization-visible", or the same scoped to a named service
account.

Any one of these resolves it. (1) and (3) compose well: an org default with a
per-publish override.

Note that sharing already persists across republishing to the same URL —
"viewers see updates immediately" — so audience only needs to be settable
once per artifact, not per revision.

Alternative Solutions

• Manual sharing via the Share dialog. Works, and is what we do today. Does

not scale past a handful of users, and is impossible for a service account
nobody signs into. At 10–15 people generating documents, somebody becomes a
full-time sharer.

• Publishing the document somewhere else (a repo file, a chat canvas). Solves

visibility, and loses what the artifact is for: arbitrary rendered HTML/SVG,
updates in place at a stable URL, and — the one that matters here — inline
comments that Claude Code can already read and answer.

• Driving the Share dialog with a headless browser, or replaying the internal

request that a manual share fires. Both are brittle against UI or endpoint
changes, both fail silently and in production, neither can be covered by a
test, and non-browser access to claude.ai returns a Cloudflare 403 — so the
second requires satisfying bot protection. It would also put the account the
whole pipeline authenticates with at risk, to save one click.

• Waiting for a human. This is the status quo, and it is why the request

exists.

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

We run an internal Product Manager agent on Claude Code, unattended on an EC2
instance. A colleague tags it in Slack with a feature request; it grounds
itself in the codebase, clarifies in-thread, then publishes a product spec as
an artifact and posts the link back to the thread.

The intended loop is:

request in Slack
→ agent publishes the spec as an artifact
→ reviewers read it and leave comments
→ agent reads the comments, revises, republishes to the same URL
→ repeat until approved

Every step of that exists today except one: reviewers cannot open the spec.
The artifact is private, the agent cannot share it, and the account that owns
it is a service account with no human signed in.

So the loop stops at step 2, and a person has to open a browser, sign in as
the service account, and click Share — for every spec, before any review can
begin. With one agent and 10–15 people using it, that is a person's recurring
job created by a missing parameter.

Additional Context

Verified on Claude Code 2.1.274 (macOS and Linux), against a Claude
organization with the Artifacts capability enabled.

What we checked, so it is not re-derived:

• Artifact and ArtifactComments tool actions — no sharing action on either.
• claude --help, Claude Code settings, and environment variables — no

artifact visibility setting.

• Org admin settings — the Artifacts capability grants permission to share, it

does not default.

• Claude Docs via the docs connector — same ownership model, same limitation.
• Behaviour across republishes — a shared artifact stays shared when the same

URL is republished, and viewers see the new version immediately.

Two details that may be useful if this is picked up:

• A default-private posture is right, and we are not asking to change it. The

ask is an explicit opt-in the publisher can express.

• Because sharing survives republishing, a publish-time parameter is enough —

there is no need to re-assert audience on every update.

Happy to test a preview build against a real automated pipeline if that helps.