Skip to main content
Add a teammate to your organization with a single command:
Capy prompts you for a role - Member, Project Admin, or Admin, narrowed to the roles your own role is allowed to grant - and then, for Member and Project Admin, asks which projects to grant. It prints a redeem code and offers to copy the whole capy redeem command to your clipboard. Every prompt has a flag, so you can run the same thing unattended: --role <member|project-admin|admin>, --project <id|name> (repeatable), --ttl <duration> or --expires <iso>, plus --json and --non-tty for agents and CI. Your teammate runs:
They authenticate, the service strips its outer wrap only if their account is an active member of the org, and their CLI strips the inner wrap locally with the token baked into the code. Capy saves the org key on their machine, so running capy from then on syncs the secrets for the projects you granted.

​
Why out-of-band delivery matters

The redeem code carries an invite token T alongside the service-wrapped copy of the master key. T is one of the two halves that decrypt that copy; the other half is the Capy service stripping its own wrap. Anyone who holds T and can also get the service to strip its wrap - which takes an authenticated, active member of the org - recovers the master key. The service only ever sees one half (its outer-wrapped blob). It never sees T. So T has to reach the invitee through a channel the service doesn’t touch:
  • Good: Signal, a password manager share, a QR code scanned in person, a phone call to dictate.
  • Bad: email, Slack DM that logs to your org admin, Git commit, a public chat log, screen share on Zoom with recording on.
There is no command to revoke an issued code, and a code stays usable until it expires - so control the window instead. Codes expire after 7 days by default; capy invite alice@example.com --ttl 30m shortens that, and --expires <iso> sets an absolute cut-off. If someone else has already redeemed a leaked code, run capy kick <email> on the account that used it, which deletes the membership so the service stops co-decrypting for them, then rotate the values they could read through your normal secret rotation process.

​
Adjusting access after they join

capy users opens the interactive members list, but it only manages people who are already in the org - there is no way to type a new email into it. Press r on a member row to change their org role, Enter to expand a member (and then a project) to edit their per-project role - project-admin, member, or none - and g on a protected-branch row to grant or revoke that branch. Adding someone new always starts with capy invite.

​
What gets exchanged

The invite flow double-wraps the master key:
  1. Your CLI wraps M with a key derived from T, the org ID, and the invitee’s email.
  2. The service adds an outer wrap over that result.
  3. The invitee authenticates, gets the service to strip the outer wrap, and strips the inner wrap locally using T + their authenticated email.
If the authenticated email doesn’t match the salt the inviter used, decryption fails cryptographically. See Cryptography → Inviting a new member for the full construction.

​
What’s next

Roles

Member, Project Admin, Admin, Owner.

Kicking users

Remove a teammate. O(1), no re-encryption.
Last modified on August 11, 2026