How to Share a Claude Cowork Project With Others

You can share a Claude Cowork project with people in your organization where Claude’s project sharing is available and enabled. Give collaborators the appropriate project access, then separately check that they can reach the files and outputs needed for the work.

A project invitation does not turn a folder on your computer into a shared drive. fenbs can keep the shared decisions, tasks, and current next step alongside this workflow, so colleagues have a common work record even when their local files or AI apps differ.

What should you check before inviting someone?

1. Update Claude Desktop and confirm which organization and account you are using. Check whether your project is available in your Claude account or is still a local project.
2. Open the project’s sharing controls and review your organization’s available options. If sharing is disabled, ask the organization’s administrator about the intended access.
3. List the materials a collaborator needs: project instructions, source documents, generated files, and the latest reviewed outcome.
4. Separate project access from file access. Move or copy only the required deliverables into an approved shared location, with appropriate permissions.
5. Invite one colleague first and ask them to confirm what opens from their own account and computer.

Anthropic’s Cowork project guide↗ (opens in a new tab) confirms organization project sharing and explains differences between account projects and local material. Its current instructions also cover interface changes, so follow the controls available in your app rather than a screenshot from an older walkthrough.

If you are still deciding what belongs in this workspace, what Claude Cowork is provides the background. Here the task is narrower: make a specific piece of ongoing work usable by the next person without making assumptions about access.

How do you choose project access?

Where sharing is enabled, open the project’s Share menu, add the colleague, and choose the appropriate access. “Can view” lets them use the project without editing its shared setup; “Can edit” permits changes to that setup. Anthropic’s visibility and sharing guide↗ (opens in a new tab) explains these permissions and removal.

Base the choice on responsibility. A teammate drafting from approved instructions might only need to use the project. The person responsible for keeping those instructions accurate may need to edit them. Discuss who changes the project instructions before several people begin correcting them independently.

Read the audience label carefully. An organization-wide setting reaches a different audience from selected invitations. Keep a short record of who should have access and why, particularly when a client engagement ends or someone changes teams. That makes a later access review much easier.

Which files remain on your computer?

Anthropic distinguishes project information stored in your Claude account from folders and files that stay local. Moving a local project’s information into the account does not upload those folders or their contents; older local sessions also stay on that computer. Some organization setups still retain local-only projects, as the Cowork guide explains.

For example, a consultant might create a report using a folder of interview notes. The colleague reviewing the report may need the finished document and a few approved references, rather than every interview. Make that choice deliberately before sharing a folder containing more than the reviewer needs.

Our guide to projects in Cowork covers the project setup itself. For a handoff, the practical test is whether the reviewer can open the named deliverable without being on your computer or asking you to retrieve it.

Does the project expose your private conversations?

Sharing a project does not automatically share individual project chats. Treat any transcript you want someone to read as a separate sharing choice, and check its audience before sending. A reviewer can often do their job with a concise outcome and source links instead of a long record of experimentation.

Do not assume personal memory is the team’s official account of events. Write down the specific instruction or decision that colleagues must use. If you want more detail about how remembered context works, read the Claude project memory guide and check your account’s current controls.

For the broader menu of sharing choices, see how to share in Claude.

When a private conversation produces an approved change, put that reviewed decision in the shared work record. fenbs Decisions and rules let the next person find the agreement without needing access to the conversation that led to it.

What makes the handoff clear enough to use?

Send the project invitation with a short handoff message. Name the deliverable, explain the requested action, and identify anything the recipient must not treat as approved. “Please review the recommendations; the totals have not been checked” is much more useful than “Here is the project.”

• Output: the file or link the next person should open.
• State: what is finished, what was checked, and what remains uncertain.
• Decision: the current approval, who made it, and any limits on its scope.
• Next step: one concrete action and the person responsible for it.

Ask the recipient to explain their next step before you consider the handoff complete. If they need another file or interpret an unfinished check as completed, fix the message and the shared record. The team brain hub covers how to make this habit work across ongoing projects.

How to do this with fenbs

1. Create a free account and try the workflow personally; use a team kanban board for colleagues who need access.
2. Add the project and a task for the deliverable. Link to its approved shared location and name the review the recipient needs to perform.
3. Record the person’s decisions and the current task status. Keep untested work and unresolved approvals explicit.
4. Connect a supported assistant using Integrations, then ask it to read project context at the start and save progress at the end.

fenbs does not upload your local Cowork folders or make inaccessible files available to teammates. It is not the right fit if your only need is file synchronization; use your approved file service for that and keep the shared work record linked to it.

Finish by testing both sides of the handoff: the colleague can reach the deliverable, and they can identify the next action. A shared project becomes useful when those two checks succeed together.