1. Open your invite link.

   Your team admin sends a link that looks like repoops.ai/team/join/<token>. Open it in a browser within 14 days; after that the invite expires and your admin sends a new one.

2. Sign in.

   Sign in with Google, Apple, Microsoft, or an email link, whichever the sign-in page offers. If you don't already have a RepoOps account, signing in creates one. Your invite is accepted the moment you land back on that page: you'll see "You're in 🎉".

3. Install the free desktop app (if you haven't already).

   Grab the installer from the install doc. The desktop app is free for one developer, whether or not you're on a team.

4. Generate a connect code.

   Back in the browser, open repoops.ai/team/connect, choose the team if you belong to more than one (the page never creates a team for you), and click Generate connect code. You get a one-time code, valid for 15 minutes. It is shown once and is not in the page URL, so copy it before you navigate away; if you lose it, generate another. The code is yours: the machine you paste it into is recorded as your device.

5. Paste the code into the desktop app.

   In the desktop app: Settings → Connect to team. Paste the code. The app names the team the code binds to before you agree, without spending the code; if it is the wrong team, cancel and generate a code from the right one. Then accept the consent screen that explains what the team can and can't see.

6. Check capture and hosted delivery.

   Review publishing settings and capture health, then verify hosted delivery acknowledgments. A bound installation or accepted repository policy does not prove that evidence has arrived.

7. Optional: share lessons with your team.

   A separate toggle, Share lessons with your team, sends each new lesson's distilled form (its trigger, rule, and fix) to the team's shared brain. Off by default; turn it on if your team wants cross-repo lesson sharing.

A team owner or admin publishes a versioned investigation policy from the repository's hosted settings. In local Settings → Managed GitHub repositories, review the repository, owner access and new-transcript retention, then accept the exact version for your installation.

Repository-wide transcript uploads require current acceptance. A changed policy requires fresh acceptance; a revoked device, removed membership or unavailable GitHub installation cannot authorize managed uploads. Owners and admins inspect acceptance in the same repository settings. Personal per-session transcript grants remain a separate decision.

New managed transcripts record the accepted policy version and expire after the configured number of days from upload. Existing records keep their expiry. Acceptance remains awaiting evidence until delivery is verified; it is not a full-fidelity or GitHub merge-compliance receipt.

Open Runtime health from a local investigation page to inspect the latest transcript delivery attempt. Acknowledged records, oversized records still on disk and failed repository deliveries are separate counts. The uploader reads records incrementally and retries unacknowledged evidence; these counts do not establish complete session coverage.

Newly published policies use the captured-source contract. After accepting it, the local daemon sends repository-assigned Claude Code and Codex transcript snapshots in bounded chunks whenever hosted delivery is available, including when optional cloud streaming is off. Existing policy versions keep their original scope until the owner publishes a new version and the installation accepts it.

Use Request evidence beside a managed installation, or the request section inside Captured transcripts. Select the installation, exact session ID, supported source and Evidence family: the whole source, the transcript only (no tool records) or the tool records only. For one family, the installation still checks the whole source's repository scope, then sends only that family's records, byte for byte, plus the first record that carries the session's scope; the snapshot row names the family and how many byte ranges of the source it holds. Source receipts cannot be requested alone, because a receipt is the check RepoOps makes on captured bytes as they arrive; that option is disabled with the reason. Offline requests remain queued for up to 72 hours. Cancel a pending request in the same modal. Each request shows its state with a line saying what it means: Policy changed means a newer policy version needs acceptance before the installation answers, Requester no longer an owner or admin means the person who asked lost that role, and Scope unverified is explained below. States describe captured evidence only; refresh the snapshot list to read delivered bytes.

The installation keeps a record of who asked. In local Runtime health, Owner retrievals lists the last requests this machine received: the owner or admin by name and linked GitHub login, the session and source, when it was asked and what the installation reported.

The repository's managed installations card ends with Managed evidence audit: every policy publish and acceptance, snapshot upload and read, request, pickup, result and cancellation, case retrieval and check exception for this repository, newest first, 50 a page. The team Audit log keeps every other event.

Owners and admins open Captured transcripts in repository settings or from a selected Attribution session. Read preview is the default: a copy of the snapshot built on the server with credentials, tokens, keys and emails masked. Each snapshot row says how many spans the preview masked and how many bytes it withheld (one record over 1 MiB is withheld rather than masked), and the snapshot list carries the masking rule version and the byte ranges of the masked spans in the original. The preview is never the complete source. Search preview searches the preview only, so a masked value cannot be found by guessing it. Read original and Download original open the encrypted original exactly as captured; they are separate actions, and the audit trail records preview reads and original reads as different events. A verified snapshot means its byte count and ordered digest were checked; it does not establish full session, trace or provider coverage. Missing, receiving and expired evidence remain distinct. Encrypted provider fields remain encrypted.

Every case also opens with an Evidence coverage section. Open Coverage matrix to see seven evidence families for the case: runtime event payload, deployment, commit and PR links, session metadata, transcript, tool records, source receipts and diagnostics. Each reads captured, partial, unsupported, expired, restricted or not requested, with the stored bytes or chunk range and the last accepted hash where one exists. A case with no agent session still shows its runtime and GitHub evidence and says why there is no transcript.

Owners and admins of a managed repository press Retrieve missing evidence on the case. RepoOps checks stored snapshots first and says so when everything retrievable is already stored. Otherwise it queues a request for each linked session that has no verified snapshot, on the installation that reported that session, and lists the outstanding requests under the matrix. Pressing it again reuses a queued request. In the coverage matrix, the Transcript and Tool records rows each have Request only this family, which asks for that family alone and is disabled once the family is captured for every linked session; the Source receipts row's button is always disabled with the reason. For members, unmanaged repositories and paused policies the button is disabled and its tooltip says why. The local app shows the same matrix read-only; retrieval runs from the hosted case.

Before sending a snapshot, the installation checks repository and session metadata throughout its captured JSONL prefix. A context switch to another repository, conflicting session identity or unresolved metadata holds the whole snapshot locally and reports a partial request. Quoted paths in message text are not repository assignments. Source files are preserved.

Scope-unverified means the snapshot came from an older client that did not perform this check. Its metadata remains visible, but its bytes cannot be opened or used to complete a request. Update the local installation and request the evidence again. An integrity hash alone does not prove repository scope.

Runtime health also reports verified snapshots, acknowledged chunks, blocked repositories and source failures. Offline attempts resume without discarding source files. Requests to offline installations wait for reconnection and remain subject to their expiry.

Each pull request in a managed repository gets a RepoOps managed evidence check. A commit passes when its author is a team member with a linked GitHub identity and an installation that accepted the current policy, when every session the commit names in a Session-Id trailer has a verified snapshot, and, for a commit that names no session, when the author's installation reported in the last 24 hours that it is capturing and syncing this repository. The check summary names each commit that falls short and why. Press Re-run on GitHub once evidence has synced.

Bots and emergencies pass only through an exception an owner or admin adds in the repository's managed installations card: a bot login for up to 365 days, or one pull request for up to 7 days, each with a reason recorded in the team audit log. To block merges on the check, add it as a required status check in the repository's branch protection. It covers pull requests, not clones or offline edits.

To deny access itself, an owner or admin turns on Restrict repository access to enrolled developers under Repository access in the same card. It needs the GitHub App installation to hold Administration: Read and write on the repository; without it the option is disabled, names the missing permission and links the installation's GitHub settings, and the dashboard cannot enforce access, only report it. Preview changes (dry run) lists who would lose which direct access; nothing changes until you tick the confirmation and apply that exact list. RepoOps changes only the direct grants of outside collaborators, or of any collaborator on a personal repository. It never touches organization membership, teams, an organization member's direct grant, repository admins, a bot with a bot exception or a person with an emergency access exception, and people who reach the repository through a team are listed as not enforceable. Each change is audited and has Restore previous access. The managed installations guide has the details.

Owners and admins see every managed repository they manage at the top of Connections. Each repository shows its exact policy version, state, retention and contract, then the GitHub collaborators the policy covers beside the team member each one is linked to and how many installations currently accept the policy. The collaborator list comes from the hourly repository access sweep; until it has run for a repository, the view says not reported rather than guessing from the team roster. Bot accounts are counted apart, because a bot needs an exception, not an installation.

Each enrolled installation then shows its adapter coverage (captured and uncaptured tools), the last upload and last verified receipt, its unsent records and bytes with the oldest item's age, how long it has been silent, the verified cloud evidence it has retained with the last accepted hash, and the owner requests still queued or collecting. Every value names its source and the time that source last reported. A value no source reported reads not reported, never zero. Unsent counts are this repository's transcript files with bytes RepoOps has not verified, their size and the age of the oldest unsent content. Until the installation's capture scan has finished one full pass of the repository's sources the cell reads At least, and an installation on an older RepoOps version shows its whole-device queue with a note saying so. Uncaptured tools are coding tools with no capture adapter whose history or configuration file is in the repository (Aider, Cursor, GitHub Copilot, Windsurf, Cline, Continue, Gemini CLI). When a current installation cannot support an investigation, by the same rule the merge check applies, its row says why, and Today lists it under Collection health for owners and admins. Today also lists each required GitHub collaborator with no current installation, and each one not linked to a team member. A device whose data disk is under the free-space floor reads disk pressure: capture at risk, because new captures may not fit.

The health report an installation sends to the team names only the repositories it accepted a managed policy for, or every tracked repository if you turned cloud sync on yourself. Any other repository on the machine counts toward repos capturing on the device and its name stays on the machine.

A transcript that ends inside an unfinished record, after a crash or while a session is still writing it, uploads its complete records up to the cut. The unfinished tail is never sent. Until that record is finished and the whole file uploads, the installation's coverage stays in backlog, and once the backlog is a day old the merge check says a transcript ends inside an unfinished record.

• Your work counts. Telemetry, spend, and activity roll up into your team's shared view at repoops.ai/team.
• The brain's text stays on your machine unless you say otherwise. A bound desktop sends the hourly brain pulse (aggregate counts, rule fingerprints, short titles), and redacted activity once streaming is on. Full brain files leave only if you turn on the brain publisher, which is off by default; distilled lessons leave only under "Share lessons".
• Server-owned policy applies. The capture-mode floor, the sensitive-path watchlist, and any per-action approval floor your team set take effect on your bound desktop once you're connected. Budget alerts go to the team's owners and admins, not to your desktop.