How to Check What Claude Code Still Knows After a Teammate Leaves
Put a shared Claude Code setup in front of a team and be able to show what the agent still knows when someone leaves. Two questions and two markers do it, and on my own run the fix I was sure of failed because the answer was still in git history, which sits on the same list as open sessions and saved approvals.
>This covers the test for when someone leaves. Claude Code Multiplayer goes further: bringing the next person on, deciding who owns which paths, and the rollout pack a new teammate can start from without you.

Claude Code Multiplayer
Build One Shared Workspace for Your Team and Agents in 30 Days
Hello builders,
We can put a shared Claude Code setup in front of a whole team, let people come and go, and show with one command what the agent still knows about the work of someone who has left. I thought deleting the notes a departed teammate left behind would settle it, and a fresh session answered the question anyway by reading the decision out of git history. When we remove a teammate from Claude Code, the seat and the repository access go first, and what we test afterwards is a pair of questions with a marker in each.
The tools built for sharing sessions say themselves that this is unsolved. claude-together, a 17-star open-source project for exactly that, lists among its limitations a paragraph that begins “A room key is permanent and unrevocable”, and the rest of it reads like a warning label.
leave_roomonly deletes your own copy; it can’t evict anyone else. You cannot kick a member. The only way to exclude someone is for everyone else to start a fresh room.
I admire a project that prints that on its own front page. A repository with Claude Code in it has the same problem, and I have not found anything that ships a way to take back what an agent picked up from one person.
Two questions, two markers

The banner across the picture reads SAM IS REMOVED FROM THE WORKSPACE, and Sam is my stand-in for whoever is leaving your team. Under MUST BE FORGOTTEN sits a question only Sam’s work could answer, with the marker 900, the token lifetime in seconds that Sam settled on. Under MUST SURVIVE sits a question about work everybody shared, with the marker 002-auth-migration. Before the removal both markers are present, and afterwards marker ‘900’ is gone while the other is still present. Why a marker, when we could compare the two answers? Two runs of the same question come back worded differently every time, so a comparison never comes out equal and tells us nothing.
Each question goes in its own small file, three lines long. I call them q-sam.md for the answer that has to go and q-shared.md for the one that has to stay. These are my examples, so write your own questions, and pick a marker that can’t turn up by accident, because the script looks for it as a whole word.
QUESTION: What was decided about the auth token TTL, why, and what was rejected?
MARKER: 900
EXPECT: gone
QUESTION: What is the current ACTIVE plan and who opened it?
MARKER: 002-auth-migration
EXPECT: kept
The script asks a fresh session the question and looks for the marker in what comes back. Save it as workspace/bin/revoke-test.sh and make it executable.
#!/usr/bin/env bash
# revoke-test.sh <question-file.md> baseline|after
# Asks a fresh session one question and checks the answer for a marker.
# Exit 0 = OK or PASS, 1 = INVALID or FAIL, 2 = the test itself could not run.
set -uo pipefail
usage() { echo "usage: revoke-test.sh <question-file.md> baseline|after" >&2; exit 2; }
[ $# -eq 2 ] || usage
Q="$1"; PHASE="$2"
case "$PHASE" in baseline|after) ;; *) usage ;; esac
question=$(sed -n 's/^QUESTION: //p' "$Q")
marker=$(sed -n 's/^MARKER: //p' "$Q")
expect=$(sed -n 's/^EXPECT: //p' "$Q") # gone | kept
[ -n "$question" ] && [ -n "$marker" ] && [ -n "$expect" ] \
|| { echo "revoke-test: $Q needs QUESTION, MARKER and EXPECT" >&2; exit 2; }
out="${Q%.md}.$PHASE.txt"
claude -p "$question" > "$out" && [ -s "$out" ] \
|| { echo "revoke-test: claude gave no answer, so there is no verdict" >&2; exit 2; }
grep -qwF -- "$marker" "$out" && found=present || found=gone
if [ "$PHASE" = baseline ]; then
[ "$found" = present ] && echo "baseline OK: marker '$marker' present." \
|| { echo "baseline INVALID: the agent never knew it. Pick a better question."; exit 1; }
else
[ "$expect" = kept ] && want=present || want=gone
[ "$found" = "$want" ] && echo "PASS: marker '$marker' is $found." \
|| { echo "FAIL: marker '$marker' is $found, expected $want."; exit 1; }
fi
We run it from the repository root, with the two question files kept in a folder outside the repository.
# while Sam is still on the project
./workspace/bin/revoke-test.sh ~/revoke/q-sam.md baseline
./workspace/bin/revoke-test.sh ~/revoke/q-shared.md baseline
# after Sam is removed
./workspace/bin/revoke-test.sh ~/revoke/q-sam.md after
./workspace/bin/revoke-test.sh ~/revoke/q-shared.md after
What my own run got wrong
I ran all of this on Claude Code v2.1.292, and both baselines came back baseline OK. Then I took Sam out of the file that says who may write what, which is roughly where a normal offboarding stops, and the after-phase printed FAIL: marker '900' is present, expected gone. The note where Sam wrote that decision down was still a file in the repository and the agent had simply read it, so whether that record outlives the person is a choice we should make on purpose.
So I deleted the record, committed and ran it again, and got the same FAIL. The answer began “Found it in the git history.” The fresh session had gone through the log when the working tree did not answer the question. It finally passed in a fresh repository: I copied only the files we had decided to keep into a new folder, ran git init, committed and ran the after-phase there, which printed PASS: marker '900' is gone. and PASS: marker '002-auth-migration' is present. That’s the same last resort claude-together documents for itself.
The folder outside the repository is there because of one more failure. My first version saved each answer inside the repository, next to its question, and with a saved answer sitting there the after-phase read it and failed.
The line under the picture explains the second question: “If both markers vanish you have not revoked anything. You have broken the agent.” When the test fails, these are the places to check, cheapest first.
- any session still open, which holds their work in a context we can’t reach: stop it and start a new one
.claude/settings.local.json, where a “Yes, and don’t ask again” they clicked weeks ago is still granting things: read the whole file and delete their rules- agent-team mailboxes and task lists under
~/.claude/teams/and~/.claude/tasks/, which live on their laptop and left with it - files in the repository, and then its git history, which only a fresh repository drops
Write the two questions for one real teammate this weekend. Run the baseline first, while they’re still on the project, because that’s the half with a deadline.
Now go build something this weekend!
John Cook