Synopsis
Description
Removes <email> from the current organization. The service deletes their membership, and their local key.enc becomes cryptographically inert - the service will refuse to strip the outer wrap for a non-member.
Capy takes the organization from keep.lock when you run the command inside a project. Outside a project it uses your only organization, or prompts you to pick one if you belong to several.
<email> has to match a member of that organization; the match is case-insensitive. Capy prints a confirmation prompt before removing anyone, and the prompt defaults to No.
capy kick is O(1). No key rotation, no re-encryption of secrets for remaining members.
capy kick is disabled in local-only mode, which has no organization, team, or server.
What kicking does
- Revokes the ex-member’s ability to decrypt any secret in the org.
- Takes effect on their next CLI call. Already-running processes they have in memory continue working until they terminate.
- Wipes their local key material for that org the next time they run
capy or capy redeem. Those two commands recognize the service’s revocation response and delete ~/.capy/orgs/{orgId}/users/{userId}/, the cached project keys for the org, and keep.lock in the working directory.
- Leaves the master key unchanged for remaining members.
What kicking does not do
- It doesn’t recall plaintext copies the user already read and stored elsewhere.
- It doesn’t invalidate deploy tokens they may have minted. Revoke those separately with
capy deploy revoke <deployId>.
- It doesn’t rotate the master key. Follow your incident-response procedure to determine whether rotation or recovery is needed.
Example
Answer no and nothing changes:
If the address doesn’t match a member of the org, Capy exits 1 without touching anything:
See also
Last modified on August 11, 2026