For teams
Your CLAUDE.md only knows what you worked out
The expensive part of a codebase is not in the code. It is the migration that has to run serially, the endpoint that lies about its status code, the reason you stopped retrying on 429 — things a colleague learned once, at cost, and that everyone else rediscovers. DeerDawn puts that in every teammate’s next session.
$10 per person, per month. Works with Claude Code, Cursor, ChatGPT and Codex.
What changes with a second person
Not more features. Three properties a solo brief never needs, because there the author and the reader are the same person.
Every fact carries a name
A decision with no author cannot be trusted, chased, or retired. Your brief says who worked it out and when, so a claim you doubt is a person you can ask rather than folklore you have to re-derive.
You get told what happened while you were gone
A solo brief is a diary — skipping a day costs nothing, because nothing happened. A team brief opens with what your colleagues recorded since your last session, which is why teams keep the habit that individuals drop.
Disagreements surface instead of overwriting
When two people record opposite conclusions about the same thing, both stay and the brief says so. Picking a winner automatically would throw away the only fact nobody else has: that the team is not agreed.
Your agent knows who else is in the file
Before an edit, the agent can say a colleague has recently written in the same area — by name. It is a warning that arrives in time to prevent a collision rather than explain one afterwards.
One commit, not one install each
Install friction does not add across a team, it multiplies — and a team of five where two never connect gets a half-empty brief that reads as a broken product. So the setup is a file you commit once. Everyone who clones the repo has the connector; each person signs in as themselves the first time their agent uses it.
The committed file names the server and nothing else. It carries no key, which is the point rather than a limitation: a credential in a committed file outlives every rotation.
Shared does not mean visible
Putting your team’s knowledge somewhere only works if you can keep things out of it. Sharing is one setting per project, and nothing moves between states on its own.
| State | Who can read it | What it is for |
|---|---|---|
| Personal | You alone | Nobody else in the workspace can open it — including an owner. For work that happens to live here but is not the company’s. |
| Private to the org | You and workspace owners | Not shared with the team, but the company’s work. An owner can read it, so nothing walks out of the door when somebody leaves. They can read it; they cannot silently rewrite it. |
| Shared | The whole workspace | In everyone’s brief, with control over which sections travel. |
The questions people actually ask
Can my manager read my side project?
No. Personal is the one setting a workspace owner cannot override, and it exists precisely so the answer to this question is a flat no rather than a policy.
What happens when someone leaves?
Their keys are revoked immediately and their access ends. What they contributed stays, still credited to them by name — a team that lost half its context whenever an engineer left would be the opposite of the product.
Does inviting someone expose what I already had?
No. Everything that predates the team stays personal until you move it yourself, and that holds against anyone added later too, not only against the person you are inviting today.
Who has seen a given project?
The audit log records the person, the tool and the time for every read, write and export, plus invitations, role changes and removals.
The full technical detail is on the security page.
Start with the project you argue about most
The one with the deploy nobody else can do, or the service with the rule you keep having to re-explain. Move that one in first — it is where a shared brief pays for itself fastest, and where you will know within a week whether this works for you.