Sharing AI coding context with your team without leaking secrets

Your assistant knows your project well by now. It has a CLAUDE.md that explains the build, a notes file with last month's decisions, and a few saved sessions from hard debugging days. Then a teammate joins the work, opens a fresh session, and gets suggestions you ruled out weeks ago.

The obvious fix is to share your context. The obvious risk is sharing too much: an API key pasted into a transcript, a customer email in a debugging log, a local path that reveals more than it should.

This article shows you what context is worth sharing, how to separate it from what should stay personal, a review pass to run before anyone else sees it, and how to choose who gets access.

What your teammate actually needs

A teammate does not need your whole history. They need enough to make the same good choices you would. In practice that is four things:

• Project instructions. How to build, test and run the project, the conventions you follow, the commands that are safe. This usually lives in CLAUDE.md (read by Claude Code) and AGENTS.md (read by many other coding agents).
• Decisions and their reasons. "We use cursor pagination because offset pagination broke on large exports." Short, dated, one per entry.
• Known traps. The flaky test, the environment variable that must be set, the migration that must run before the deploy.
• A few sessions worth reading. The investigation that found a root cause, the design discussion with rejected options. See which AI coding sessions are worth keeping for how to pick them.

Everything else, such as raw chat logs, scratch notes and half-finished ideas, adds noise. It also raises the chance that something private slips through.

Split shared context from personal context

The cleanest way to share safely is to decide up front which files are team files and which are yours. Put team files in the project. Keep personal files outside it.

A layout that follows this split:

billing-service/
├── CLAUDE.md                 # team instructions for Claude Code
├── AGENTS.md                 # team instructions for other agents
├── .env.example              # variable names only, no values
├── .gitignore
├── src/
└── .prjcontext/
    ├── instructions/
    │   └── testing.md        # longer team instructions
    ├── memory/
    │   ├── decisions.md
    │   └── known-traps.md
    └── sessions/
        └── 2026-09-12-slow-orders-after-deploy.md

Your personal preferences, such as "explain things briefly" or "I use fish, not bash", belong in your global assistant settings in your home folder, not in the project. That keeps team files focused and avoids pushing your habits onto others.

If you need a shared starting point for instructions, the guide to writing CLAUDE.md and AGENTS.md walks through what to include.

Run a review pass before you share

Before a teammate can see your context, read it once as if you were a stranger. This takes a few minutes and catches most problems.

1. Search for obvious secrets

Run a quick search over the context folders and instruction files:

grep -rniE 'api[_-]?key|secret|token|password|passwd|bearer|BEGIN [A-Z ]*PRIVATE KEY' \
  CLAUDE.md AGENTS.md .prjcontext/

This will find false positives, such as the word "token" in a sentence about tokenisers. That is fine. You are looking for anything that looks like a real value.

2. Read every saved session

Transcripts are the riskiest part. They contain command output, file contents and anything you pasted. Look for:

• keys, tokens, passwords or connection strings in command output
• customer names, emails or other personal data from logs
• internal hostnames, IP addresses or account IDs
• your local paths and usernames

If a session contains any of these, cut the passage or keep only your summary.

3. Check what would actually be shared

Do not rely on memory for what is in the folder. List it. With git, git status and git diff --staged show what a commit would contain. Whatever tool you use, look at the real list of files before it leaves your machine.

4. If you find a real secret, rotate it

Deleting a key from a file does not un-leak it if it was ever committed, pushed or pasted into a chat. Revoke it and issue a new one. The article on keeping secrets out of your AI context covers the full routine.

Choose the right level of access

Not everyone needs the same access. Think in two levels:

• Read access for people who need to understand the project: a reviewer, a contractor looking at one issue, a teammate on another team. They can view and clone, but not change the shared context.
• Write access for people who work on the project day to day. They add decisions, update instructions and save sessions.

Two more rules help:

• Start narrow. Give read access first and upgrade when needed. It is easier than taking access away later.
• Remove access when the work ends. When someone leaves the project, remove them the same day. If they had access to anything sensitive, rotate those credentials too.

Publishing context openly is a different decision. Public project memory and sessions can be a great teaching resource, but only after a careful review, because everyone can read every version.

Write shared context for someone who was not there

Context that makes sense to you can be useless to a teammate. A few habits make it readable:

• Write the reason, not just the rule. "Do not use the ORM for reports" is a rule. "Do not use the ORM for reports: it loads whole rows and the export timed out at scale" helps someone decide when the rule applies.
• Date your decisions. A reader needs to know if a note is from last week or last year.
• Mark what is superseded. Do not silently delete old decisions. Add "Replaced on 2026-09-20 by..." so the history stays clear.
• Keep instructions short. Assistants and people both skim. Put details in separate files and link them.

A small before and after for a memory entry:

<!-- Before -->
- dont use offset pagination

<!-- After -->
### 2026-08-30 Cursor pagination for list endpoints
Offset pagination skipped rows when orders were inserted during
large exports. Cursor pagination on (created_at, id) fixed it.
Applies to every list endpoint that can return more than one page.
Discussion: sessions/2026-08-30-cursor-pagination-design.md

Keep shared context healthy over time

Sharing is not a one-time event. As the project changes, the context drifts.

• Update instructions in the same change as the code. If a pull request changes the test command, it should change CLAUDE.md and AGENTS.md too.
• Review new sessions like code. When a teammate adds a session, skim it for secrets and relevance before you rely on it.
• Prune. Delete sessions about code that no longer exists. Move lasting conclusions into project memory.

When a new person joins, this shared context becomes their starting point. The guide on onboarding a new contributor with project context shows how to turn it into a first afternoon plan.

How PrjLab handles this

We built PrjLab to share a project together with its context, with review built into the flow. The prj CLI captures CLAUDE.md, AGENTS.md and everything in .prjcontext/instructions/, .prjcontext/memory/ and .prjcontext/sessions/. It skips obvious secrets such as .env files, key files and credential folders, plus anything in .gitignore or .prjignore. That filter is a safety net, not a complete secret scanner, so you run prj status and review the list before prj push. Global assistant folders and machine credentials are never scanned, which keeps your personal settings personal. Repositories are private by default; you share by handle as a reader (view and clone) or writer (also push), and removing someone takes effect immediately. If you make a repository public, anyone can read and clone it, including its memory and sessions, so review those first.

Frequently asked questions

Should I share my personal assistant settings with the team? No. Keep personal preferences in your global settings and put only team rules in the project's CLAUDE.md or AGENTS.md.

Is it safe to share raw AI transcripts? Only after you have read them. Transcripts often contain command output, pasted values and personal data, so trim or summarise them first.

What if I shared a secret by mistake? Revoke and rotate it right away. Removing it from the file is not enough if anyone could have copied it.

Can I give someone access to read the context but not change it? Yes. In PrjLab, invite them as a reader: they can view and clone, but only writers can push.

Want to share your next project with its context? Follow the getting-started guide.