[BUG] Artifact share links should be able to track "Latest" version
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Summary
A shared artifact link is bound to a specific version rather than to the
artifact. There is no "Latest" option. For any artifact that is republished on a
schedule or by CI, this makes the share link go stale the moment it is created,
and the owner has to re-share after every republish.
Separately, the pin does not actually hold: the version the link serves drifts
away from the version that was pinned, and the Share dropdown reports a version
number that disagrees with what the link serves. So today the link is neither
reliably pinned nor reliably latest.
Why "Latest" should exist
An artifact is a published document with an audience. The whole point of the
link is to hand it to people once. If it resolves to a frozen version, every
update requires re-distributing a new URL — which defeats having a stable URL at
all.
Concrete case: I publish a CI/CD dashboard that scripts/build-shipping-log.py
rebuilds and republishes on every push to main. Recipients hold one link.
They should see the current dashboard. Instead they see whatever version
happened to be selected when the link was created — which, for a dashboard whose
entire value is freshness, is worse than useless.
A "pin to specific version" mode is legitimate and should stay (frozen views for
citations, review snapshots). It just should not be the only mode, and it
should not be the default for a link the owner is publishing broadly.
Observed behaviour (Claude Desktop + Chrome incognito, Aug 2026)
- The pin drifts. With version
557cb08pinned, opening the share link in
a clean incognito window served a page stamped BUILD 4e39bcc — a
different, later build. So the link is not a stable snapshot either.
- The dropdown disagrees with the link. The Share dropdown displayed
"Version 19 — 18 minutes ago" while the latest published version was 20. On
other occasions after republishing it showed Version 1, then Version 13, then
Version 14, with no republish in between to explain the change. The number in
the dropdown is not a reliable statement about what a recipient will see.
- Version numbers are reused. The history appears to hold ~20 slots. As new
versions are published, old ones roll off and the numbers are reassigned to
new content. "Version 13" therefore does not identify a fixed artifact state
over time — which undermines pinning as a concept, since the thing being
pinned to is not stable.
Points 2 and 3 are why I am filing this as a bug as well as a request: even a
user who wants a frozen link cannot currently get one, and the UI actively
misreports which version is behind the link.
Requested behaviour
- Add "Latest" as a share-link target, and make it the default for public
links. The link resolves to the current published version at load time.
- Keep "pin to version N" as an explicit opt-in for frozen snapshots.
- Make the Share dropdown show what the link will actually serve. If it says
Version 19, a recipient opening it must get version 19.
- Give pinned versions stable identifiers that survive history rollover, or
state plainly in the UI that pins expire once the version ages out of history.
Impact
Anyone publishing a living document through Artifacts — dashboards, status
pages, changelogs, running notes, anything rebuilt by automation. Right now the
guidance I have to give people is "don't trust the version behind this link,"
which is not a reasonable thing to say about a published URL.
What Should Happen?
Requested behaviour
- Add "Latest" as a share-link target, and make it the default for public
links. The link resolves to the current published version at load time.
- Keep "pin to version N" as an explicit opt-in for frozen snapshots.
- Make the Share dropdown show what the link will actually serve. If it says
Version 19, a recipient opening it must get version 19.
- Give pinned versions stable identifiers that survive history rollover, or
state plainly in the UI that pins expire once the version ages out of history.
Error Messages/Logs
Steps to Reproduce
- Create a new Artifact
- share the link
- Modify the artifact so it publishes a new version
- Shared link should point to new version, or "Latest"
Claude Model
None
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
2.1.251 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
_No response_