---
id: platform/account-deletion
title: Delete your account
description: Preview what account deletion removes, resolve blocked workspaces, confirm with the exact phrase, and know what happens next.
keywords: [bex, account deletion, delete account, remove account, GDPR, offboarding]
last_updated: 2026-09-23
---

Deleting your account removes the account and tears down the workspaces only
you own. Read the preview first: it names every workspace and says whether it
will be deleted, left, or block the request.

:::danger No cancel
Once your deletion intent is recorded there is no cancel — no button, no API,
no grace reversal. Resolve every `blocked` row before you confirm.
:::

## What deletion removes

One request deletes your account only — never another user's account, and
never a workspace on its own. For each workspace you belong to, the preview
assigns one disposition:

| Disposition | Meaning |
| --- | --- |
| `delete` | You are the sole member: the workspace and everything in it — services, datastores, secrets, environment groups, registry credentials, sandboxes — is torn down |
| `leave` | Other admins remain: you are removed and the workspace keeps running for them |
| `blocked` | The request cannot proceed until you resolve this workspace (below) |

Beyond workspaces, deletion removes your API keys, SSH keys, notification
settings, and the OAuth and device grants authorizing your agents and
integrations; revokes your sign-in sessions; anonymizes your residual
references in activity, audit, and session records; and finally deletes the
identity itself. Details per surface are in [Effects](#effects).

## Preview deletion {#preview}

In the dashboard, open **Settings** and find the account-deletion card: it
shows the same three lists the API returns, and each blocked workspace links
to that workspace's settings so you can fix it. Or query directly:

```graphql
query {
  accountDeletionPreview {
    delete { id name action }
    leave { id name action }
    blocked { id name action }
  }
}
```

```json
{
  "delete": [{ "id": "wks_123", "name": "side-project", "action": "delete" }],
  "leave": [],
  "blocked": []
}
```

The REST equivalent is `GET /v1/users/deletion-preview`. API keys never
appear as members: the machine identities your keys minted are excluded from
the counts, so a workspace with only you plus your keys still reads `delete`.

## Resolve blocked workspaces {#blocked}

A workspace blocks deletion when you are its sole admin on a shared workspace,
or when it is the instance's pinned ops workspace. Any blocked row refuses
the whole request. A pinned ops workspace can never be deleted by this flow;
its row only clears once you are no longer its sole member. Otherwise resolve
each blocked row, then preview again:

- **Promote another admin** so your row becomes `leave` — see
  [Workspaces, members, & roles](./members.md).
- **Remove the other members** so you become the sole member and the row
  becomes `delete`.
- **Delete the workspace yourself** if nothing in it needs to survive; the
  disposition then disappears with the workspace.

If you own the workspace, leaving is not available to you at all —
ownership cannot be transferred yet — so a `leave` row for an owned
workspace cannot execute. Remove the other members first so the row becomes
`delete`, or delete the workspace directly.

The request re-checks dispositions when it runs, so a workspace that became
blocked after your preview still refuses rather than half-deleting.

## Confirm deletion {#confirm}

Deletion requires a direct signed-in browser session and the exact phrase.
Type it precisely — the comparison is exact, and anything else is a `400`
that names the phrase:

```graphql
mutation {
  deleteAccount(confirmation: "delete my account") {
    state
  }
}
```

```bash
curl --fail-with-body --silent --show-error \
  -H "Authorization: Bearer $BEX_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"confirmation":"delete my account"}' \
  -X DELETE "$BEX_API_URL/v1/users"
```

Machine API keys, OAuth client credentials, and delegated tokens are refused
with `403`: this verb never runs from automation, only from you in a browser
session. A recorded request answers `202` with the deletion `state`
(`pending` for a fresh intent).

## What happens next {#next}

Deletion runs asynchronously in the background: auth material goes first,
then each workspace is torn down or left per the recorded plan, then your
subject rows are removed or anonymized, and the sign-in identity is deleted
last. The `state` moves `pending` → `cleaning` → `identity` → `done`; a
failed step is recorded and retried rather than dropped. There is no cancel
once the intent is recorded.

## Effects on keys, sessions, and billing {#effects}

- **API keys** are deleted, including the machine identities they minted.
- **SSH keys** are deleted with the account.
- **Agents and integrations** lose access: OAuth and device grants are
  revoked, and CLI telemetry tied to you is removed.
- **Sessions** are revoked before the identity is deleted, so tokens minted
  afterwards fail closed.
- **Billing linkage** is removed with each deleted workspace: the workspace's
  subscription is cancelled where Stripe is enabled. This guide makes no
  promise about refunds, invoice history, or data exports — settle those
  before you confirm.

Source pin: Bex `6f2975248`.