Shared projects: who gets what access
Shared projects are an opt-in beta in Shuriken 5.1. The trust model: what a member can reach, the controls you keep, and who to invite.
Contents
Sharing a coding agent session is safe only with someone you'd trust with your computer, because that's what you're sharing. In Shuriken's shared projects, an opt-in beta in 5.1, a member works in your project on your computer, with your files and your Claude. You keep a daily spend cap per member, a say over your project's hooks, and a Stop sharing button.
Why we wrote this down#
Shared projects let you invite people to a project by email, work in the same chats and the same queue, and see every message marked with who sent it. The first question anyone should ask about that is: what can they actually do on my machine?
It deserves an answer before anyone presses Share. So here's the trust model, in plain words. Shared projects are a beta, off by default, and both people have to turn on Shared projects (beta) in Settings › Projects. The details may still change during the beta. The principle won't.
A member gets nearly the access you have#
A shared project in Shuriken isn't a screen share. A member's app reaches your computer through Shuriken's relay, end to end encrypted, and their messages go to the same agents yours do. Those agents run on your machine, in your project, on your Claude.
Now think about what an agent can do. Claude Code, Codex and the rest read files, write files and run commands. That's the job. Anyone who can type a prompt into that agent can ask it to run a command. So anyone you invite can, in effect, run code on your computer.
We could wrap that in softer words. We'd rather not. The Share dialog says it in the box you tick before the invite goes out: "I trust their name fully. They can read and change everything in this project, run commands on this computer as you, and use your Claude."
What that means in practice:
| What | What a member can reach |
|---|---|
| Your computer | Their prompts run there, through your agents |
| Your files | What the project's agents can read and change |
| Your Claude | Their chats use your plan and count toward your limits |
| Your code | It runs on your machine. Members see it in their app as you do; our relay carries it end to end encrypted and can't read it |
One more thing about that Claude row. Providers' terms may not allow someone else to use your subscription, and it can put your account at risk, so check your plan's terms before you share.
There are guard rails around a member, too: they can't use the terminal, push, merge, open pull requests, or change the project's settings or sources, and they can't reach anything outside the shared project. A guard rail is a seatbelt, not a reason to invite someone you wouldn't otherwise. Plan for full access.
The controls you keep#
Trust doesn't mean no limits, and five come built in.
A daily spend cap per member. Every member gets a cap, in money, that you set; it starts at $10's worth. They see what they've spent today against it. When they reach it, their chats pause for the day. Their spend lands on your plan, so this is your brake.
Your hooks, your call. Projects often have git hooks, language servers and services that start by themselves. If a member changes files in your project, Shuriken holds those for you: your commits skip the project's git hooks, language servers don't start, and services marked to start on their own wait. Nothing they changed runs on its own until you look and choose to trust the project's files again.
Stop sharing, instantly. Stop sharing and they lose access at once. Their chats and messages stay in your project, and a member who leaves keeps nothing.
Everyone signs their work. Every message and every queued task shows its author's name and picture, and you see who's in the project right now. When something odd turns up in the history, you know who asked for it.
Members bring their own Shuriken account. No shared logins. You invite an email address; they sign in as themselves.
Who you should invite#
Good fits:
- Your co-founder or a close teammate on the same codebase, someone you'd already give SSH access to your dev machine.
- A pair-programming partner for one project, on a machine that holds only that project. A Shuriken server on a separate box or VM is a fine home for it.
Think twice, then don't:
- A client you met last week. You may trust their intentions; you're also trusting their laptop and their password hygiene.
- Someone from a community chat who offered to help.
- Anyone you wouldn't leave alone with your signed-in laptop for an afternoon.
If what someone really needs is your plan, not your computer, sharing a project is the wrong tool.
What we won't do#
We won't ship this with a cheerful "invite your team!" button and the warning in a help article. The trust step is in the Share dialog itself and on the live collaboration page. If that makes a few people decide not to share, good. Those are the people who shouldn't.
For what our cloud can and can't see in general, the security page has the full list. Sharing a project needs Pro on the owner's side; pricing has the plans. Shared projects, step by step shows how to turn the beta on, and you can try Shuriken to start.
Frequently asked questions
Can I limit what a member spends?
Yes. Each member gets a daily spend cap you set, $10's worth to start. When they reach it, their chats pause for the day.
