Claude Artifacts sharing limits, and what to use when a team needs more

Sharing a Claude Artifact is no longer a choice between only me and anyone with the link. Anthropic’s page on sharing artifacts↗ (opens in a new tab) now lists email invitations, in beta, and on Team and Enterprise plans sharing with named people, with the whole organization or, on Enterprise, with groups. Each person gets Can view, Commenter or Can edit, and link access has its own level. That is a real sharing model, and it is fine for a document or a prototype. What it does not do is turn an Artifact into a list of work, and that becomes a problem when the Artifact has quietly turned into your team’s backlog.

This piece describes that gap fairly, explains when it matters and when it does not, and says what to use when it does. We should be open about our interest: fenbs exists because of this gap. The first test we set ourselves was to move our own backlog off an Artifact and onto a fenbs kanban board, and to stop if the kanban board was not better.

What Artifacts are good at

Artifacts are an excellent way to make something with Claude and look at it straight away: a small app, a chart, a document, a tracker. According to Anthropic’s overview of artifacts↗ (opens in a new tab), some can store data between sessions, shared by everyone who opens them. A lot of people, ourselves included, have ended up with a backlog living in one, because asking Claude to “make me a board for these tasks” works, and the result is pleasant to use. For one person, it can stay that way for a long time; see Claude project sharing permissions for what teammates can access in a project.

Nothing here is a criticism of Artifacts. They were built for making and sharing things, not for running a team’s list of work. Anthropic changes the sharing options, and this post was rewritten when they last changed, so check Claude’s own help pages for the current state before you rely on any description of it, including this one.

What sharing covers today

On Pro and Max plans an Artifact is “Only you” or “Anyone with the link”, and you can invite specific people by email. On Team and Enterprise it can be “Only people invited”, “Anyone at” your organization, or “Anyone with the link” once an Owner allows sharing outside it. The Free plan can only publish legacy artifacts, which are those made in a chat before September 16, 2026; they show Publish or Share & copy link instead of Share. Link sharing is not available for every Artifact: those that use Claude or connect to your apps cannot use it, and on Team and Enterprise nor can docs, yet.

Anthropic’s own pages differ on one point. The help center says everyone needs a Claude account to open a shared Artifact, except a legacy one published from a chat, while the Claude Code documentation↗ (opens in a new tab) says an Artifact published from Claude Code and shared publicly opens with no sign-in. If it matters for your client, try the link with someone who has no account.

What sharing does not make it

Sharing decides who can open the page and what they may do to it as a whole. It says nothing about the work written on the page. If the Artifact is your backlog, none of Anthropic’s pages describes any of the following as part of it:

• Lanes and task states. Whatever columns you see are drawn by the page’s own code, and the next revision can draw them differently or drop them.
• History per task. People can comment on the page, but nothing records who moved one task, or when.
• Test status. Whether a fix was checked, and how, lives on a task only if someone builds a field for it and everyone fills it in.
• A work list an assistant updates over MCP. An Artifact can call your connectors, but it is not itself a set of tasks an assistant reads and changes one at a time; to change the backlog, Claude changes the page.

When it matters, and when it does not

If you work alone and nobody else needs to see or touch the list, you may not need anything else. A private list is a private list.

It starts to matter when any of these become true:

• Somebody other than you finds the bugs, and you want each one to arrive as a task with a kind, a lane and their name on it.
• A client wants to see what moved this week, not only the page as it stands now.
• More than one AI assistant works on the list, and you want to know which one did what.
• An assistant should be able to file and move tasks without being able to rewrite the whole list.
• Someone asks “who moved this to done?” and nobody can answer.

What the missing layer looks like

fenbs is that missing layer, built as a product. It is deliberately small. There are four words to learn: kanban board, task, lane and member. A task is a Feature, an Enhancement or a Bug. A lane is To Do, Next Up, In Progress or Completed. A member is a person, or an AI assistant working on a person’s behalf, holding a role on the kanban board.

People get roles

You add your team, your client, or a friend who is testing for you, and each gets a role. You can give them a smaller one than yours. Roles are your team’s own, and fenbs suggests two for sharing: a Client who can read and comment, and a Reporter who can also create tasks but edit only their own. Whoever runs the workspace holds All Access, and you can add a role for the people who do the work, such as an Editor who can create, edit, move and comment on any task. Take someone off and they stop seeing the kanban board, while what they wrote stays where it is.

Assistants get keys cut from yours

An AI assistant connects by signing in. Your browser opens on fenbs, you tick what it may do (reading the board is always on; adding and changing tasks, and commenting, are yours to choose) and approve. It gets an access token that lasts an hour and a refresh token it trades for a new pair, so you never see or copy either. A client with no browser can use a token you issue by hand under Settings instead: you give it a name, tick its scopes and choose an expiry if you want one, and it is shown once. Either way it acts as you, can never do more than your role allows, and revoking it takes one click without signing you out. The steps are in the connection guide.

Every change is signed

Every change is recorded with who made it, person or assistant, and each task shows its own trail. This is the part a shared page does not give you: an Artifact can know who may edit it, but not who moved which task.

Moving a backlog across

Nobody adopts a tool by retyping a list they already have. On a fenbs kanban board, Add many sits next to + New task. Paste one task per line, or paste a markdown list, which is what a backlog in an Artifact usually looks like when you copy it out. Start a line with bug:, feature: or enhancement: to set that line’s kind. Indented lines under an entry become that task’s note.

## Checkout
- [ ] bug: Search ignores the category filter
      Only at 390px. The chip renders but the query never carries it.
- [ ] Add keyboard shortcuts
      j and k to move between cards.

Everything is previewed before anything is created, so a line that was read wrongly is something you correct rather than clean up afterward. Each task then gets a ref such as BUG-016 that is never reused, even after a delete, so a ref quoted in a commit message or a text to a client keeps meaning the same task.

A fair summary

Keep using Artifacts for what they are good at: making things with Claude and showing them to people. When the thing you made is a list of work that other people and other assistants need to touch, with different rights, and you need to know afterward who did what to which task, you have outgrown a page. That is the point to move the list onto a board. How it works shows the whole of fenbs in five steps. There is a free plan, and paid plans are on the pricing page.