Skip to main content
Remove a teammate with a single command:
Capy asks you to confirm first, and the prompt defaults to No. Once you confirm, the service removes their membership. The next time their CLI tries to co-decrypt anything, the service refuses (they’re no longer a member), and their local key.enc becomes cryptographically inert - its outer wrap needs the service to strip it, and the service won’t. No key rotation. No re-encrypting every secret. No propagating a new master key to every remaining member. A membership delete, and revocation is complete.

​
Removing access from the members table

capy users opens the interactive members table, but it has no org-level remove. Pressing r on a member’s row turns the Role cell into an in-place picker, and the choices are admin, project-admin, and member - capped by your own role:
Expand a member with Enter and press r on one of their project rows, and the choices are project-admin, member, and none. Picking none revokes their access to that one project; they stay in the org and keep their other projects. Taking someone out of the organization is capy kick only.

​
Why it’s safe to skip re-encryption

The kicked user’s key.enc is an outer-wrapped blob. To use it they need to present it to the service and have the service strip the outer wrap. The service checks membership on that call - if they’ve been kicked, the call returns 403. The bytes stay on disk until their CLI next talks to the service. When the service answers with an explicit revoked response - on their next capy or capy redeem - the CLI deletes the key material for that org: ~/.capy/orgs/{orgId}/users/{userId}/, the cached project keys under ~/.capy/orgs/{orgId}/projects/, and the keep.lock in the working directory. Either way the blob is unusable. See Cryptography → Revocation for the full construction.

​
What kicking does not do

  • It doesn’t recall plaintext values they already saw. If the kicked user read a value and stored it somewhere outside Capy (a text file, a screenshot, a chat log), that copy is outside Capy’s control. Rotate anything sensitive through your normal secret-rotation process.
  • It doesn’t invalidate deploy tokens. Any deploy tokens minted while they were a member still work. If you have reason to suspect they captured one, list the project’s tokens with capy deploy list and revoke it with capy deploy revoke <deployId>.
  • It doesn’t rotate the master key. Remaining members keep using the same M. That’s fine - the departed user can’t recover M without the service, and the service won’t help them.

​
When you do need to rotate

If you suspect the kicked user captured the seed phrase (not just their key.enc), rotate: new seed, new M, re-encrypt every secret, re-invite every remaining member. The seed phrase is the one artifact that bypasses the service’s co-decrypt gate. In practice this requires someone with access to the owner’s seed phrase. Kicking random members doesn’t trigger it.

​
What’s next

capy kick

Full command reference.

Revocation (cryptography)

The exact cryptographic enforcement.
Last modified on August 11, 2026