[FEATURE] Programmatic artifact share-with-org + delete from headless/server CLI sessions

Status Closed — not planned
Reported on v2.1.186
Maintainer reply None cached
Activity 4 comments · opened Jun 23, 2026 · closed Aug 26, 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

Claude Code 2.1.186 can publish Artifacts from non-interactive sessions (VPS, CI, autonomous agents), but the two essential post-publish operations — sharing with the organization and deleting — have no programmatic path reachable by the publishing session. Both require either a browser UI or an enterprise Compliance Access Key, neither of which is available in a headless /login (OAuth) setup. An autonomous agent can publish but can never expose its output to the team or clean up stale artifacts without human intervention.

Proposed Solution

Any one of the following would unblock headless sessions:

  1. Publish-time visibility flag — a parameter on the Artifact tool to set org visibility at creation time (e.g. read_mode: "org"), so a headless session can make its output team-visible without a follow-up action.
  1. Session-scoped manage API — allow the standard OAuth session that owns an artifact to change its visibility and delete it, without requiring a separate enterprise Compliance Access Key (self-service for the author, not just admin governance).
  1. CLI subcommands — at minimum, claude artifacts share <id> --org and claude artifacts delete <id> usable non-interactively from the terminal.

Alternative Solutions

  • Expose artifact visibility as an environment variable (e.g. CLAUDE_ARTIFACT_VISIBILITY=org) read at publish time, so headless sessions can configure it without code changes.
  • Allow the standard /login OAuth token to authenticate against the Compliance API for artifacts owned by that session, scoped to read/write/delete on the author's own content only.

Priority

Medium - Would be very helpful

Feature Category

API and model interactions

Use Case Example

Example scenario:

  1. An autonomous Claude Code agent runs on a VPS overnight, generating an HTML dashboard artifact summarizing the day's task activity.
  2. The agent publishes the artifact via the Artifact tool — this works fine today.
  3. The agent then needs to share it with the org so teammates can open it in the morning — currently impossible: the only share option is a button in the browser, which doesn't exist in a headless session.
  4. With this feature, the agent could pass read_mode: "org" at publish time (or call claude artifacts share <id> --org afterwards), and the dashboard would be immediately visible to all org members without any human intervention.
  5. This would save time because the entire report workflow — generate, publish, share, notify via Telegram — would run unattended end-to-end, with no manual step required from the team.

Additional Context

Links to similar features in other tools:

  • GitHub Gists API: PATCH /gists/{gist_id} with {"public": true} — allows programmatic visibility change on owned content via the same token used to create it. Exact analogue to what we're asking for artifacts.
  • Notion API: PATCH /v1/pages/{id} supports sharing/permission updates from the same API key used to create the page.

Technical considerations or constraints:

  • The publishing session already holds a valid OAuth token tied to the artifact's owner — scoping share/delete to "own content only" is a natural trust boundary that avoids any governance concerns.
  • The Compliance API already models read_mode as a field (referenced in earlier internal testing); exposing write access to the owning session would be a minimal surface addition.
  • For the CLI subcommand approach, the artifact ID is already returned/logged at publish time, so it's available to the agent for follow-up calls without additional state management.

Related issues (not duplicates):

  • #61571 — Artifact sharing not working in Claude Cowork integration (UI/Cowork-specific)
  • #54781 — Artifact API proxy strips mcp_servers parameter (different surface)

Internal reference: this scenario was discovered while running Claude Code 2.1.186 as an autonomous agent on a Linux VPS with Team plan /login auth, generating shareable HTML reports for a development team with no browser access on the server.

View original on GitHub ↗

4 Comments

matthewod11-stack · 3 months ago

Strong +1 — this is exactly the gap that blocks unattended report producers. One data point that I think widens the scope of this issue:

For us the publish/Artifact tool itself isn't available headless — not just share/delete. This issue's premise is that 2.1.186 can publish Artifacts from non-interactive sessions and only share/delete are blocked. In our environment the first half doesn't hold: the Artifact tool is absent (NO_TOOL) from every non-interactive surface we tried.

  • Env: macOS, Claude Code 2.1.191 (newer than the 2.1.186 here), /login OAuth, Artifacts capability enabled — we publish fine interactively (an existing claude.ai/code/artifact/<uuid> proves the org capability is on).
  • Verified NO_TOOL three independent ways: a headless claude -p, a scheduled-task routine (the real cron runtime), and a re-test from a clean cd ~ headless session. The tool simply isn't in the toolset in any of them.

So if publish works headless on a Linux VPS at 2.1.186 but not in a macOS claude -p / scheduled-task at 2.1.191, headless availability of the Artifact tool is inconsistent across surfaces/platforms — which means a complete fix probably needs to cover create/publish/update headless, not only the share-with-org + delete operations this issue asks for. (Your proposal #1, a publish-time read_mode: "org" flag, only helps if publish itself is reachable headless.)

Secondary nuance worth flagging: even interactively, a session loaded with a large MCP/skill surface can fail to expose the Artifact tool — launching from a minimal working dir (cd ~ && claude) restores it. So "the tool is missing" has two distinct causes (the non-interactive surface, and an interactive cwd/config trap), which makes it easy to misdiagnose as "artifacts are off."

Use case (same shape as yours): scheduled weekly + Monday "market report" producers that render self-contained HTML and deliver it as an org-shared claude.ai artifact. Because the routine can't self-publish, we had to split it: the scheduled run renders + references the stable artifact URL, and a human does a ~30-second interactive "update the artifact from this file" step before a gated auto-post to Slack. It works, but end-to-end unattended delivery is impossible today — exactly the workflow this issue is trying to unlock.

Happy to provide repro details for the macOS scheduled-task / claude -p NO_TOOL case if useful.

sihil · 3 months ago

+1, with a variant of the use case: this gap bites in interactive sessions too, not just headless ones.

In a Claude Code session today the agent investigated a production bug, raised a PR, generated a commit-by-commit reviewer walkthrough as an artifact, and edited the PR description to lead with the artifact link for the review team. Everything was agent-driven except the final step – the human had to leave the session, open the artifact page and click share before the link at the top of the PR worked for anyone else.

Of the proposed solutions, the publish-time visibility flag on the Artifact tool (option 1) would have covered this cleanly, keeping private as the default and widening only when the user asks. We expect to lean on artifacts heavily in exactly this shape (PR walkthroughs, investigation write-ups, run-books linked from tickets), so this becomes a papercut on every one.

github-actions[bot] · 1 month ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

AdrianJohnsonUK18 · 23 days ago

This was auto-closed as stale, but the underlying gap (no programmatic way to set artifact visibility/org-share or delete) is still unresolved. Re-raised as #95855 so it doesn't get lost — please add support there.