[FEATURE] Live artifacts: allow sidebar display name to be renamed independently of id slug

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

In Cowork, a live artifact's display name in the sidebar (and in the "Pinned"
section) is auto-derived from the kebab-case id slug passed at creation.
For example, an artifact created with id: "doc-tv-morgen-cockpit" always
appears in the sidebar as "Doc Tv Morgen Cockpit". Once created, that name
cannot be changed.

I verified this end-to-end: calling update_artifact with a modified HTML
that updates the embedded cowork-artifact-meta JSON ("name" field), the
<title> tag, and the <h1> tag inside the rendered page does change what
is shown INSIDE the artifact, but does NOT change what is shown in the
sidebar. list_artifacts confirms the manifest name field is still
derived from the original slug. This suggests that the sidebar display name
is stored separately from the artifact HTML metadata, or at least is not
updated from it.

The practical consequence is that any live artifact a user keeps pinned and
uses daily is locked into whatever name the user happened to choose at
creation time — including any typos or unfortunate Title Case artifacts.
There is no supported way to rename it after the fact.

Proposed Solution

Introduce an explicit display_name parameter on create_artifact and
update_artifact, decoupled from the id slug:

• id remains the stable, immutable, kebab-case identifier used in URLs,

filesystem paths, and external references. Same constraints as today.

• display_name is a free-form Unicode string used wherever the name is

shown to the user: sidebar entries, the "Pinned" section, file listings,
notification text. Default = the current auto-derived Title Case if not
specified, to preserve backward compatibility for existing artifacts.

• update_artifact accepts display_name so a user can rename an artifact

at any time without recreating it and without losing version history,
pin state, createdAt timestamp, or external references.

This mirrors the standard pattern in any system that distinguishes a stable
identifier from a user-facing label (filename vs. inode, route slug vs.
page title, etc.).

Alternative Solutions

The only workaround I found is lossy:

1. Call create_artifact with a new id (e.g. "slot-di-oggi").
2. Manually remove the old local artifact folder from

~/Documents/Claude/Artifacts/<old-id>/. No programmatic delete is
exposed; allow_cowork_file_delete cannot reach that path because the
Artifacts folder is not mounted into the Cowork sandbox.

Recreating in this way loses:

• the full version history (every prior versions/*.html);
• the original createdAt timestamp;
• the pinned status;
• any external references keyed on the old id.

So the workaround works, but is destructive enough that I would not use it
for an artifact I use daily.

Priority

Low - Nice to have

Feature Category

Other

Use Case Example

1. I create a Cowork live artifact called "doc-tv-morgen-cockpit" — a

daily-use dashboard that pulls the TV schedule of some tv channels
and shows the documentary slots relevant to my
production work, with auto-translated Italian synopses. I pin it.

1. After a few weeks of daily use, I decide the original German-mixed name

is awkward and I want to rename it to "Slot di oggi".

1. I edit the HTML metadata, <title>, and <h1>. Inside the artifact

everything updates correctly.

1. The sidebar still shows "Doc Tv Morgen Cockpit". update_artifact

provides no display_name parameter, and list_artifacts confirms the
manifest name is unchanged.

1. The only way out is to delete the old artifact (losing all version

history and pin state) and recreate it under a new id — and even then,
the auto-derived Title Case produces "Slot Di Oggi" with the Italian
article "di" wrongly capitalized, because the id slug accepts only
[a-z0-9-_] (based on what I observed in testing).

With a display_name parameter, step 4 would be a one-line update call
preserving everything else.

Additional Context

A secondary pain point: even when the user accepts recreation, the
auto-derived display name is forced to Title Case on every hyphen-separated
token. There is no way to express sentence case, mixed case, or non-ASCII
characters in the sidebar name through the id alone, because, in my
testing, artifact ids appear to be restricted to [a-z0-9-_]. A separate
display_name field would also solve this, since it could accept arbitrary
Unicode strings.

Environment:

• Claude desktop app, Cowork research preview
• macOS
• May 2026