Team-Claude View
What this is
Team-Claude View lets you bring your team's Claude Code activity into Carrier. Once you set up a workspace, you can browse the Claude Code session transcripts and the shared memory that your team produces while working in a repository — all from inside Carrier, without digging through everyone's local ~/.claude directories.
A workspace is tied to a single repository. There are two ways to get a repo's Claude Code data into Carrier, and you pick one when you create the workspace:
- Mode A — GitHub-linked. Carrier connects to a GitHub repository you own (or have access to) and pulls the shared data automatically on a schedule. This is the lowest-effort option once it's set up: nobody has to run anything by hand.
- Mode B — Manual upload. Each developer's machine packages up its local Claude Code cache and uploads it to Carrier using a small Python client. This works even when there is no GitHub repository involved, and it keeps the data flowing through your own machines rather than through GitHub.
Both modes end up in the same place: a workspace page in Carrier showing sessions and memory. The rest of this guide walks through each mode, compares them, and covers privacy and common questions.
Mode A — GitHub-linked
In GitHub-linked mode, Carrier holds a personal access token (PAT) for your repository and uses it to keep a private mirror of the shared Claude Code data up to date.
1. Create a fine-grained personal access token
Carrier needs read access to one repository's contents. Create a token at github.com/settings/personal-access-tokens/new and configure it like this:
- Resource owner / repository access — scope the token to the single repository you're linking. Don't grant access to all repositories.
- Repository permissions — set Contents: Read-only. That is the only permission Carrier requires.
- Expiration — a 90-day expiry is a good balance between safety and not having to rotate constantly. You can choose shorter; you'll just need to re-link more often (see Troubleshooting).
Copy the token when GitHub shows it — you won't be able to see it again afterward.
Classic vs fine-grained PATs. A classic PAT (with the
reposcope) also works, and Carrier will accept it. But because a classic token typically grants far broader access than Carrier needs, the workspace page shows an advisory banner recommending you switch to a fine-grained token. Fine-grained tokens let you limit access to exactly one repo with read-only contents, which is what we recommend.
2. Link the repo in Carrier
- From the Workspaces page, click Link a repo.
- Choose the GitHub tab.
- Fill in a name for the workspace, the repository URL (e.g.
https://github.com/your-org/your-repo), and paste the PAT you just created. - Click Create.
3. What the first sync does
When you create the workspace, Carrier immediately clones the repository and fetches its claude-team-share branch — the branch your team uses to publish shared Claude Code data. From that branch it reads the sessions/ and memory/ directories into a private server-side mirror.
If the claude-team-share branch doesn't exist yet, that's fine: the workspace is created and simply shows an empty state until the branch appears and the next sync picks it up. Nothing is broken — there's just nothing to show.
4. Staying up to date
Carrier polls the repository roughly every 30 seconds and re-syncs github-mode workspaces whose data has gone stale, so the page updates on its own as your team pushes new sessions and memory. If you want an immediate refresh, use the Re-sync now button on the workspace page.
Troubleshooting (Mode A)
- PAT expired or revoked. The next sync will fail authentication and the workspace shows an auth-error banner. Create a fresh token (step 1) and re-link the repo (or update the token on the existing workspace).
- Branch missing. If
claude-team-sharedoesn't exist on the remote yet, there's simply nothing to show. The workspace stays in its empty state until the branch is created and pushed. - Private repository. Make sure the PAT actually has access to that specific repo. With fine-grained tokens this means the repo is listed under the token's repository access; with a classic token it means the token's owner can read the repo. If Carrier can't read it, you'll see an auth/access error.
Mode B — Manual upload
In manual mode, there's no GitHub connection. Instead, each developer runs a small Python client that bundles their local Claude Code cache and uploads it to Carrier with an API key.
1. Save the API key (shown once)
When you create a manual-mode workspace, Carrier displays an API key exactly once, right after creation. Copy and save it now — it is never recoverable. If you lose it, you'll need to recreate the workspace to get a new one (see FAQ).
The creation screen also shows the exact upload URL and a ready-to-paste configure command for that workspace.
2. Configure each machine once
On every machine that should contribute data, run the configure command once. It saves the upload URL and API key locally so subsequent syncs don't need them:
python3 scripts/team-claude-client/carrier_configure.py --url <upload-url> --key <api-key>
Use the exact --url and --key values shown in the create modal.
3. Sync
After configuring, push the current machine's Claude Code data with:
python3 scripts/team-claude-client/carrier_sync.py
The client packages your local sessions/ and memory/ directories into a gzip tarball and uploads it. On success it prints how many sessions and memory entries were uploaded.
4. Automate with a SessionEnd hook (recommended)
Running the sync by hand is easy to forget. Claude Code supports hooks in .claude/settings.json, including a SessionEnd hook that fires when a session ends. Wire the sync script in so every finished session is uploaded automatically:
{
"hooks": {
"SessionEnd": [
{
"hooks": [
{
"type": "command",
"command": "python3 scripts/team-claude-client/carrier_sync.py"
}
]
}
]
}
}
Adjust the path to the script if your repo lays it out differently. With this in place, each developer's machine uploads its latest data the moment a Claude Code session ends.
Troubleshooting (Mode B)
401 Unauthorized— the API key is wrong or has been rotated. Re-runcarrier_configure.pywith the correct key for this workspace.413 Payload Too Large— the tarball exceeded the 50 MB upload cap. Trim down what's in your local cache (older sessions) before syncing again.400 Bad Request— the upload was rejected as malformed. This usually means the tarball was corrupt, or it contained paths outside the allowedsessions/andmemory/prefixes. The client only packages those directories, so a 400 typically points to a tampered or hand-built tarball.
Comparing the modes
| GitHub-linked (Mode A) | Manual upload (Mode B) | |
|---|---|---|
| Auth | Fine-grained PAT (Contents: Read), encrypted at rest | API key (shown once, bcrypt-hashed) |
| Cold-start | Create token, paste into the GitHub tab | Create workspace, save key, run carrier_configure.py per machine |
| Updates | Automatic — Carrier polls ~every 30s; Re-sync now for immediate | Run carrier_sync.py (or a SessionEnd hook) after each session |
| Works without GitHub | No — requires a GitHub repo and the claude-team-share branch |
Yes — no GitHub repo needed |
| Hosting | Data flows from GitHub to Carrier | Data flows directly from your machines to Carrier |
| Storage | Private server-side mirror of the claude-team-share branch |
Server-side mirror of the uploaded tarballs |
Privacy & security
- GitHub PATs are encrypted at rest using AES-256-GCM. Carrier stores the encrypted token, not the plaintext.
- Manual-mode API keys are bcrypt-hashed. They are shown once at creation and are never recoverable — Carrier cannot display or email them again.
- Marking a session private. The team-claude skill provides a
/privateslash command that marks a session as non-shareable, so it won't be included when your data is shared. - The scrubber is a convenience, not a guarantee. Before storing data, Carrier runs a scrubber that removes known credential patterns only. It is not a general PII or secrets detector and cannot catch everything. Do not rely on it to sanitize sensitive transcripts — if a session contains something you wouldn't want your team to see, don't share it.
- Removing a workspace deletes its data. When you remove a workspace, Carrier deletes its server-side mirror and, for github-mode workspaces, the encrypted token along with it.
FAQ
How do multiple machines work together? In manual mode, every machine that runs the client contributes its own cache to the same workspace. Carrier derives the workspace slug from the repo-root basename (the folder name of the repository root), so all checkouts of the same repository — regardless of where each developer cloned it — map to the same workspace. Each machine's contribution is additive.
Can I share privately, without GitHub? Yes — that's exactly what Manual mode is for. The data travels straight from your developers' machines to Carrier over the API, with no GitHub repository in the loop.
How do I rotate a GitHub PAT? Create a new fine-grained token (see Mode A, step 1) and either re-link the repo or update the token on the existing workspace. The old token can then be revoked on GitHub.
How do I regenerate a manual-mode API key? There is currently no in-place regenerate. The current path is to delete the workspace and recreate it, which issues a fresh key (shown once). Then reconfigure each machine with carrier_configure.py using the new key.
What gets deleted when I remove a workspace? Its server-side mirror of sessions and memory is deleted. For github-mode workspaces, the encrypted PAT is deleted as well. After removal there is nothing left server-side for that workspace.