Can Claude Projects Be Shared With Others?

Yes, with limits. According to Anthropic’s help centre, project visibility and sharing↗ (opens in a new tab) are features of the Team and Enterprise plans, and they work inside your organisation: you add colleagues by name or email and give each one Can view or Can edit. What they get is the project’s knowledge and instructions. What they do not get is your chats, which stay private unless you share them one at a time. If you are on a personal plan, you can share a chat, but the help centre describes no way to share the project itself.

Everything below describes the help centre as it reads today. Anthropic changes Claude often, so check those pages before you rely on a detail, including this one.

Who can share a Claude project

Projects themselves are on every plan; the help centre’s overview of projects↗ (opens in a new tab) says free accounts can create up to five. Sharing is narrower. It needs a Team or Enterprise plan, and it assumes your organisation’s owners have left it switched on. The people you share with must be members of the same organisation.

• Free, Pro and Max: projects, but no project sharing described. You can share individual chats (below).
• Team and Enterprise: share a project with named colleagues, or make it visible to the whole organisation.
• Enterprise only, in beta: share a project with a group, so access follows group membership.

The two permission levels

When you open a project and click Share, you pick one of two levels for each person you add. The help centre defines them like this:

• Can view: they see the project’s contents, knowledge and instructions, and can chat within the project, but cannot edit it.
• Can edit: they can change the instructions and the knowledge, update member settings, and contribute to the project.

Note what Can view means. It is not read-only in the sense of “look but do not touch”; a viewer can start their own chats against your knowledge and instructions. It is read-only for the project’s setup. Can edit is close to co-ownership: the help centre says an editor can open the Share menu and remove other members.

Taking access away is done from the same menu: click the role next to the member’s name and choose Remove access, after which they can no longer open the project or its content. Archiving does not do it for you. An archived project keeps its members, permission levels and knowledge, and gets them all back when it is unarchived.

Public and private projects inside an organisation

On Team and Enterprise, a project also has a general access setting. Public means everyone in the organisation can find it on the Organization tab and start a chat in it. Private, shown as “Only people invited”, means only you and the members you add. You can switch either way at any time from the Share button next to the project name.

Owners control both from organisation settings. Anthropic’s page on controlling project sharing↗ (opens in a new tab) says that turning sharing off stops new shares but leaves existing ones in place, and turns every public project private. If the Share menu tells you project sharing is turned off by your administrator, that is where it was decided.

What a shared project does not share

The part people most often get wrong: sharing a project shares its setup, not its conversations. Your chats inside a shared project, and inside a public one, remain private to you unless you share them. A colleague who opens the project sees your knowledge files and instructions, and starts from a blank chat.

The same holds between chats. The help centre notes that context is not shared across chats within a project unless it is added to the project knowledge. So a decision you reached with Claude on Monday is invisible to your colleague’s chat on Tuesday, and to your own, until someone writes it into a knowledge file.

Sharing a single chat instead

If what you want to hand over is a conversation, share the chat. The help centre’s page on sharing a chat with specific people↗ (opens in a new tab) says this works on every plan: you invite people by email, and each invite only opens for the address you entered.

• It is a snapshot. Messages you send afterwards stay private until you click Update shared chat.
• It is view only. Recipients cannot reply, continue the conversation or copy it into their account.
• They do not see raw data from connectors or MCP tool calls, only Claude’s final responses.
• On Team and Enterprise, invitations stay inside your organisation’s domain.
• Turn off in the share dialog stops it for everyone at once.

The newer projects in Claude Code are not shareable

Anthropic is also rolling out a new kind of project, in beta, starting in Claude Code: one conversation in which Claude runs parallel threads in the cloud. The Claude Code documentation on Projects↗ (opens in a new tab) is plain that such a project belongs to one user and cannot be shared with another user, nor can its threads. It is on Pro and Max for now, not Team or Enterprise. If you searched this question because of that feature, the answer today is no.

When sharing a project is not enough

A shared project is a good way to give a team the same briefing: the same reference documents, the same instructions, the same tone. It is not built to be the team’s record of work. The help centre describes knowledge, instructions and chats; it does not describe a task list, an owner per piece of work, or a history of who changed what in a project. Three situations tend to expose that:

• Several people and several assistants are working the same backlog, and you need to know what is in progress and who has it.
• Some of the workers are not Claude chats at all: Claude Code in a repository, Cursor, or another assistant.
• You need someone outside the organisation, such as a client or a contractor, to see progress.

What those need is shared state that every participant reads and writes, with a name on each change. That is what a task board is for, and it sits alongside the project rather than replacing it: keep the briefing in the project, keep the work on the board.

A board that people and assistants share

fenbs is a small board built for that job. People are members of a board, each holding a role; roles are defined per company, and a role on one board can only narrow what the company role allows. An AI assistant connects over MCP as you, with scopes you tick at approval — read, write and comment — so it can never do more than you can, and revoking its access does not sign you out. Every change is recorded with who made it, and an assistant’s changes show as “Claude via” the person it acts for.

The part that answers the Tuesday problem above is AI context: short notes kept on the board, not inside any one assistant. Claude in a chat connected with the Claude connector, Claude Code in a terminal and any other connected assistant all call fenbs_get_context on arrival and read the same notes. Decisions go on their own page, with who decided and why, so the next assistant reads what was agreed instead of guessing.