Can You Share Claude Projects? Collaboration Explained
Can you share Claude Projects? Yes, but only on two plans. Claude’s Team and Enterprise plans let you share a Project with specific people or with your whole organization. You also control whether each person can view the Project or edit it. On the Free, Pro, and Max plans, there is no way to invite anyone into a Project. Those plans are built for one person working alone.
That one limitation surprises a lot of people. A Project feels like the obvious thing to hand a teammate. It holds your instructions, your files, and your chat history in one tidy workspace. But the invite button only exists on the two business plans. This guide explains how sharing actually works, what each permission level allows, and what your options are if you’re on a plan that can’t share. I’ll also cover the workarounds I’d try before paying for a Team plan.
Key Takeaways
- Project sharing is a Team and Enterprise feature. Free, Pro, and Max accounts cannot invite other people into a Project, according to the Anthropic Help Center.
- On a Team plan, a Project starts as either private (invite only) or public, meaning visible to everyone in your organization.
- There are two permission levels. “Can view” lets someone read the knowledge and chat inside the Project. “Can edit” lets them change instructions, files, and members.
- Your chats inside a shared Project stay private. Other members see the workspace, not your conversations, unless you share a chat yourself.
- Every plan, including Free, can share a single chat as a snapshot link. That is the closest thing to sharing a Project without a business plan.
- Team plan standard seats cost $20 per person per month billed annually, or $25 monthly, with a two-person minimum, per Claude’s pricing page.
Want more first-hand breakdowns like this one? Join the newsletter for a short weekly email, no fluff, just what’s working.
Can You Share Claude Projects on Every Plan?
No, and this is the first thing to get straight. Projects themselves exist on every plan. Even a Free account can create up to five of them, as covered in my breakdown of the Claude AI free tier. But creating a Project and sharing one are different features. Sharing lives only on the plans that come with an organization attached.
Here’s the full picture, plan by plan:
| Plan | Can create Projects? | Can share Projects? | Who you can share with |
|---|---|---|---|
| Free | Yes, up to 5 | No | Nobody |
| Pro | Yes | No | Nobody |
| Max | Yes | No | Nobody |
| Team | Yes | Yes | Members of your organization |
| Enterprise | Yes | Yes | Members of your organization |
Notice what’s missing from that table: sharing outside your organization. Even on Team and Enterprise, a Project cannot be handed to a random Claude user or opened up to the public internet. Sharing means sharing inside the walls of your workspace. If a client or contractor needs access, they need a seat in your organization first.
If you’re still fuzzy on what a Project actually contains, start with What Are Claude Projects? and come back. The short version: a Project bundles custom instructions, uploaded files, and related chats into one reusable workspace.
How Project Sharing Works on Team and Enterprise
On a Team or Enterprise plan, every new Project starts with a visibility choice. You pick one of two modes when you create it, and you can change it later.
Private means invite only. Nobody in your organization can see the Project exists unless you add them. You invite people by email address, one at a time or in bulk by pasting a list. This is the right default for client work, drafts, and anything with sensitive files in the knowledge base.
Public means visible to your whole organization. Everyone in the workspace can find the Project, open it, read its knowledge, and start their own chats inside it. Public here still means inside your company. It does not mean public to the internet. The Anthropic Help Center’s guide on project visibility spells out both modes.
The practical power move is the middle path: keep a Project private and invite exactly the people who need it. A three-person marketing Project doesn’t need the sales team browsing through it. And an organization-wide “company brain” Project, holding your brand voice and boilerplate, works best fully public so nobody has to ask for access.
One more detail worth knowing: the person who creates the Project isn’t the only one who can manage it. Anyone with edit access can add or remove members too. That’s flexible, but it also means edit access is a bigger deal than it sounds. More on that below.
Can View vs. Can Edit: The Two Permission Levels
When you share a Project, each member gets one of two roles. The gap between them is wide, so it’s worth choosing deliberately.
Can view is the read-and-use role. A viewer can open the Project, read the custom instructions, browse the knowledge files, and chat with Claude inside the Project. Claude will use the shared instructions and files in their chats, the same as it does for you. What viewers can’t do is change anything. Instructions, files, and the member list are all locked.
Can edit is the full-collaboration role. An editor can rewrite the custom instructions, upload or delete knowledge files, add and remove members, and change other members’ permissions. In other words, an editor can reshape the Project for everyone at once.
Here’s how the two roles compare at a glance:
| Ability | Can view | Can edit |
|---|---|---|
| Open the Project and chat inside it | Yes | Yes |
| Read instructions and knowledge files | Yes | Yes |
| Change custom instructions | No | Yes |
| Add or delete knowledge files | No | Yes |
| Add or remove members | No | Yes |
| Change other members’ permissions | No | Yes |
My working rule: default everyone to view, and grant edit to as few people as possible. A shared Project behaves like shared configuration. One well-meaning edit to the instructions changes the output for every member’s future chats, and nobody gets a notification that it happened. Small teams rarely need more than one or two editors per Project.
Your Chats Stay Private, Even in a Shared Project
This is the part of Project sharing people get wrong most often, in both directions. Sharing a Project does not share your conversations inside it.
When a teammate opens a shared Project, they see the workspace: the title, the instructions, the knowledge base. They do not see the chats you’ve had in there. Your conversations stay yours, even inside a fully public Project, unless you deliberately share a specific chat. Anthropic confirms this in the same visibility guide: chats within a shared project remain private to the person who had them.
This design cuts both ways. On the good side, you can think out loud inside a shared Project without an audience. Ask rough questions, draft bad first versions, and nobody sees the mess. On the awkward side, sharing a Project won’t automatically show your teammate that great chat where Claude nailed the analysis. The workspace travels; the conversations don’t. If the output of a chat matters to the team, you still have to share that chat on purpose.
So a shared Project is less like a shared Google Doc and more like a shared template. Everyone starts from the same instructions and the same files. What each person builds from there is their own until they choose to show it.
How to Share Your Work on Free, Pro, and Max
If you’re a solo user, the missing invite button isn’t the end of the story. You can’t share the Project container, but you can share almost everything that comes out of it. Here are the workarounds I’d reach for, in order.
Share a chat link. Every plan can turn a single conversation into a shareable snapshot link. Open the chat, hit Share, and send the link. The snapshot includes every message up to the moment you shared, along with any artifacts, while anything you write afterward stays private, according to Anthropic’s chat sharing guide. You can review and revoke your shared links under Settings, in the Privacy section. This is the fastest way to show a client or collaborator what a Project produced.
Publish an artifact. If the thing worth sharing is a document, a small app, or a diagram Claude built, publish it as an artifact and send that link instead. The viewer doesn’t need a Claude account at all. I covered when artifacts beat full workspaces in Claude Artifacts vs Projects.
Send the recipe, not the kitchen. A Project is really just three ingredients: instructions, files, and chats. The first two travel fine as plain text. Copy your custom instructions into a doc, zip up the knowledge files, and send both to your collaborator. They can rebuild the same Project in their own account in a few minutes. It’s manual, and the two copies will drift apart over time, but for a one-off handoff it works well.
Split the work by chat instead. Sometimes what feels like a Project-sharing problem is really a chat-organization problem. If a collaborator only needs one thread of the work, a shared chat link per thread may be all the collaboration you need. My comparison of Claude Projects vs chats digs into where that line sits.
One warning: don’t solve this by sharing a single Claude login between two people. It muddies your chat history, breaks each person’s usage limits, and runs against Anthropic’s usage policies. The workarounds above are slower but clean.
Is the Team Plan Worth It Just for Sharing?
At some point, the workarounds cost more time than the upgrade costs money. Claude’s Team plan runs $20 per person per month for a standard seat billed annually, or $25 billed monthly, and it now requires only two seats. Claude’s pricing page lists a premium seat tier as well, at $100 per person monthly billed annually, which mainly adds heavier usage and extra tools.
For a two-person setup, that’s roughly $40 to $50 a month to make sharing native. Here’s how I’d think about whether that’s worth it.
The Team plan earns its price when shared context is the actual product of your workflow. A solopreneur working with a virtual assistant is the cleanest example. Put the brand voice, the offer details, and the standard operating procedures into shared Projects. Give the assistant view access. Now every chat the assistant runs uses the same instructions and knowledge you use, without any copy-paste relay, and updates you make show up for them immediately. That last part is the real difference: a shared Project stays in sync, while an emailed copy of your instructions is stale the day after you send it.
The upgrade is harder to justify when sharing is occasional. If you hand off work once a month, chat links and exported files cover it. The same goes for sharing with people outside your business. A Team plan won’t help you share a Project with a client unless you’re willing to buy that client a seat in your organization, which is rarely the right move.
There’s also a middle case worth naming: two solo users who each keep their own Pro plan. Two Pro seats cost about the same as two annual Team seats. If you and a collaborator are both heavy solo users who only occasionally trade context, separate Pro accounts plus disciplined chat sharing may serve you better than a shared workspace. If you run a small business and you’re weighing the whole toolkit, not just sharing, my guide to Claude for small business walks through the plan decision from that wider angle.
Setting Up a Shared Project That Actually Works
Getting access right is half the job. The other half is setting up the Project so five people can use it without it decaying into a junk drawer. A few practices I’ve found make the difference between a shared Project the team actually uses and one that quietly dies.
Write instructions for the whole team, not for yourself. Solo Project instructions can be full of personal shorthand. Shared instructions need to work for the least-context member. Spell out the audience, the format, and the tone as if you were onboarding a new hire, because effectively you are. If you haven’t written Project instructions before, my step-by-step Projects guide covers the setup basics.
Name Projects for findability. In a public workspace, your Project titles become a directory your teammates browse. “Q3 client onboarding — SOPs + brand voice” beats “New project 7.” Assume the reader knows nothing.
Keep the knowledge base curated, not comprehensive. Every member’s chats draw on the same files. Ten tight, current documents beat forty stale ones, both for answer quality and for trust. When a price sheet or policy changes, updating that one file updates it for everyone, which is exactly the point of sharing. Make one editor the owner of that hygiene. For a closer look at how Claude actually uses those files, see How Do Claude Projects Work?
Decide what’s private before you upload, not after. Anything in a shared Project’s knowledge base is readable by every member with access. Financials, HR notes, and client secrets don’t belong in a Project shared with the whole organization. When in doubt, keep the Project private and invite narrowly.
Review membership occasionally. People change roles and leave. Because any editor can manage members, it’s easy to assume someone else is watching the list. Make it someone’s actual job, quarterly is plenty for a small team.
Common Project Sharing Mistakes
Assuming Pro includes sharing. It doesn’t, and this is the single most common surprise. Pro and Max are single-player plans. If a tutorial shows an invite flow you don’t have, you’re looking at a Team or Enterprise screenshot.
Making everything public to the organization. Public is convenient, but a workspace where every half-finished experiment is visible gets noisy fast. Reserve public status for Projects that are genuinely meant as shared resources.
Handing out edit access as a courtesy. It feels rude to give a colleague view-only access. Resist that feeling. Edit access is administrative power over the Project, not a politeness tier.
Expecting shared chats. Teammates will not see your conversations, and you will not see theirs. If your workflow depends on reviewing each other’s Claude output, build the habit of sharing chat links, because the Project alone won’t do it.
Uploading sensitive files before checking visibility. Check whether a Project is public or private before you drop files into it, not after. Flipping a Project from public to private later doesn’t un-see anything.
Frequently Asked Questions
Can you share Claude Projects on the Pro plan?
No. The Pro plan has no way to invite another person into a Project. Sharing Projects requires a Team or Enterprise plan, where sharing happens inside your organization. Pro users can share individual chats by snapshot link, or publish artifacts, and both of those links work for people outside Claude entirely.
Can you share a Claude Project with someone outside your organization?
No. Even on Team and Enterprise plans, Projects can only be shared with members of the same organization. There is no public link for a Project the way there is for a chat or an artifact. To collaborate with an outside client or contractor inside a Project, they would need a seat in your workspace.
If I share a Project, can other people read my chats?
No. Chats inside a shared Project remain private to the person who had them, even when the Project is public to the whole organization. Other members see the Project’s instructions and knowledge files, and they can run their own chats. Any conversation you want them to see, you have to share deliberately.
What’s the difference between a public and a private Project on a Team plan?
A private Project is visible only to the people you invite by email. A public Project is visible to everyone in your organization, and anyone in the workspace can open it and chat inside it. Public never means public to the internet. Both modes support the same two permission levels, view and edit.
How much does it cost to unlock Project sharing?
Project sharing arrives with the Team plan, which costs $20 per person per month for a standard seat billed annually, or $25 billed monthly, with a minimum of two seats. That works out to roughly $40 to $50 a month for the smallest possible team. Enterprise pricing is custom and adds admin and security features on top.
Is there any way to copy a Project to another account?
Not automatically, but a manual copy is easy. A Project is custom instructions plus knowledge files. Copy the instructions as text, send the files, and the other person can rebuild the Project in their own account in minutes. The copies won’t stay in sync, so treat this as a handoff, not ongoing collaboration.
Sources: Anthropic Help Center, “Manage project visibility and sharing,” 2026. Anthropic Help Center, “Sharing and unsharing chats,” 2026. Anthropic Help Center, “What are projects?”, 2026. Claude pricing page, claude.com, 2026.
