[FEATURE] Let Claude artifacts opt into the Git-backed repo/branch/PR workflow that Claude Code on the web already has

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 in the Claude app (claude.ai / desktop / Cowork) have no durable version control. History lives in a per-conversation version selector, there is no diff, blame or branch, and the only exit is copy or download. Meanwhile, Claude Code on the web, in the same app, already solves this: pick a repo, work on a branch per session, open a PR when done.

Artifacts are increasingly real software, not previews: shared databases, runtime capabilities, comments from teammates, republished many times over weeks. At that point a conversation-scoped version list is not version control. Concretely:

• History dies with the conversation the artifact was created in.
• Two people republishing the same artifact have no merge or conflict story beyond "newer wins".
• There is no way to review a change before it goes live to everyone the artifact is shared with.
• The code cannot be reused in any other pipeline (CI, deploy, audit) without manual export.

The existing GitHub integration does not help here: it is read-only and pulls repo files into context; it never writes back.

Proposed Solution

Let an artifact declare a backing repo and path, and reuse the machinery Claude Code on the web already has:

1. Link: from the artifact (or at first publish), "Connect to repository" using the same repo picker and sandboxed clone that Claude Code on the web uses. The artifact declares repo + path (e.g. acme/internal-tools → dashboards/engagement-health.html).
2. Publish = commit: each publish lands as a commit on a branch, mirroring the per-session branch Claude Code already creates. Supporting files (files, assets) commit alongside.
3. Render at a ref: the artifact viewer renders the file at a Git ref instead of an opaque blob. The version selector becomes the commit log for that path.
4. Create PR from the artifact: the "Create PR" exit ramp that exists at the end of a Claude Code session is surfaced on the artifact itself, so a change can be reviewed before it goes live to viewers.
5. In-page edits round-trip: edits made from inside the page (in-place document edits, capability-driven saves, ArtifactData schema changes if applicable) also land as commits, so the repo and the live page never drift.

Unlinked artifacts keep working exactly as today; this is opt-in.

Alternative Solutions

• Current workaround: keep the HTML in a Git repo in a folder connected to Cowork, have Claude commit there, then publish the artifact from that file. Works, but the artifact has no idea it is backed by a repo: no link back, no PR flow, and any in-page edit or republish from another conversation silently forks from the repo.
• GitHub integration (read-only): pulls repo files into context for chat/Projects but never writes back, so it cannot serve as version control for artifact output.
• Download / copy and commit manually: loses the whole point of artifacts being live and shareable, and nobody does it consistently.
• Use Claude Code on the web instead of artifacts: gets the Git side right but loses the artifact side (hosted URL, sharing, comments, runtime capabilities, in-app editing for non-developers).

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

I run AI consulting for mid-market clients and build internal tools in Cowork as artifacts: an engagement-health dashboard, a client-facing tracker, a costing calculator. These get shared with colleagues and clients and are republished weekly for months.

1. In Cowork, Claude builds engagement-health.html and publishes it as an artifact. I click "Connect to repository", pick botsai/internal-tools, path dashboards/engagement-health.html. The current version is committed to main (or a branch of my choice).
2. Two weeks later, in a different conversation, I ask Claude to add a churn-risk column. The publish lands as a commit on a branch artifact/engagement-health-<session>, and the artifact shows "1 unmerged change · Create PR".
3. I open the PR, a colleague reviews the diff on GitHub (or in the app), and merges. The live artifact URL now serves the file at main.
4. A colleague edits a label directly in the artifact's in-app editor. That edit also lands as a commit, so the repo is never behind the live page.
5. Six months later, I need to know what changed and when for a client audit. git log dashboards/engagement-health.html answers it. Today, that history is scattered across a dozen conversations and mostly lost.

Additional Context

Why now / why this is small: every primitive already exists in the product today - repo selection, isolated clone, branch-per-unit-of-work, PR creation (Claude Code on the web), and artifact publishing with supporting files and version history (Artifact tool). What is missing is the bridge between the artifact storage model and a Git working tree. This is a wiring feature, not a new subsystem, and it turns artifacts from disposable outputs into maintainable ones for the growing share of users who build tools and dashboards in the app rather than in a terminal.

Technical considerations

• Reverse direction is the non-trivial part: artifacts edited in place by viewers, or that save new versions of themselves via runtime capabilities, need those saves to become commits or the repo drifts from the live page. Sequencing question, not a blocker; v1 could be publish-only.
• Conflict handling could reuse the existing publish-conflict path (a publish to an artifact with a newer version is already rejected and hands back the live version) - the same rejection maps naturally onto a non-fast-forward push.
• Permissions: the linked repo should inherit the same GitHub app grant Claude Code on the web uses; no new OAuth surface.

Related: #93802 (bridge Claude Projects and Claude Code, GitHub parity) is adjacent but about Projects context, not artifact output. Existing GitHub integration docs: https://support.claude.com/en/articles/10167454-use-the-github-integration (read-only).