# Disable a team or transfer ownership

Disabling a team permanently releases every team-managed member, and transferring ownership demotes the current owner to admin instead of removing them from the team.

The **Danger zone** tab on a team detail page includes two high-risk actions: **Disable team**, available to anyone with permission to change team status, and **Transfer owner**, visible only to the team's actual owner.

> [!CAUTION]
> The description next to the Disable team button reads, in Chinese,
> "禁用后应由后端限制团队空间的协作和资源变更能力" — "Disabling should have the
> backend restrict collaboration and resource changes in the team space" — which
> sounds like a temporary freeze. What actually happens: every "team-managed
> member" in the team is **immediately and irreversibly** converted to a
> standalone account, in the same request, and returned to their own personal
> space. Switching the team's status back to enabled does **not** restore those
> accounts to team-managed mode. Neither the button copy, the confirmation
> dialog, nor the notification email mentions this.

_Interface illustration: Danger zone tab on the team detail page: the intro warning at the top and the Disable team action row_

## Before you begin

- **Disabling or enabling a team requires the permission to change team status** (`team:update_status`). The team owner has it by default, but this permission can also be granted to other members through a custom role — it is not owner-exclusive.
- **Disabling a team requires a recent security check.** If you have not verified your identity with your password, a passkey, TOTP, or an email code within the last hour, selecting **Disable team** first redirects you to a verification page; the action continues automatically once you pass it. Inside that one-hour window, you go straight to the confirmation dialog described below.
- **Only team-managed members are affected by disabling a team.** A "standard member" — someone participating with their own standalone account — keeps their account mode and space unchanged.
- **The interface text for both actions on this tab is available only in Simplified Chinese.** The button labels, descriptions, confirmation dialogs, and success toasts are hardcoded strings that are not translated — they display in Simplified Chinese regardless of your dashboard's interface language. This page quotes them as they actually appear.
- **Transferring ownership requires the permission to transfer team ownership** (`team:transfer_owner`), and it can only ever be exercised by whoever is currently recorded as the team's actual owner. Unlike most team permissions, this one cannot be granted to another member through a custom role — a team admin who holds every other permission still cannot transfer ownership; only the owner can.
- **Transferring ownership requires the same recent security check as disabling a team** — the one-hour window described above applies here too.
- **The new owner must already be a member of the team**, and their account must be a standalone account, not a team-managed one. You cannot transfer ownership to someone outside the team or to a team-managed member.
- **Ownership cannot be transferred while the team is disabled.** Re-enable the team first.

## Disable a team

| What happens                                                                                                                                           | What does not happen                                                                                                                |
| ------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
| The team's status changes to **Disabled**                                                                                                              | The team record is not deleted, and no membership records are deleted                                                               |
| Every team-managed member in the team is immediately converted to a standalone account, and `current_space_type` switches back to their personal space | Standard members are not affected — their account mode and space stay exactly as they were                                          |
| The platform creates or confirms a personal billing account for each converted account                                                                 | Existing resources in the team, such as instances and storage, are not deleted — the release only changes the user's tenancy fields |
| A status-change entry is recorded in the audit log                                                                                                     | Any balance the team owed is not automatically carried over to these new personal accounts (see the open question below)            |
| When you disable the team yourself from the console, the platform also sends a notification email to the owner and admins                              | That email is **not** sent when a platform administrator force-disables the team from the admin backend                             |
| The status can be switched back to **Enabled** at any time                                                                                             | Re-enabling the team does **not** restore the released accounts to team-managed mode — there is no automatic recovery path          |

1. Open the team detail page and select the **Danger zone** tab.
2. Select **Disable team**.
3. If you have not completed a security check in the last hour, complete the verification page first.
4. Confirm the dialog. Its text is hardcoded in Simplified Chinese: "确认禁用团队「团队名」？" ("Disable team "team-name"?"). Select the confirm button to proceed.

_Interface illustration: Disable team confirmation dialog, with the confirmation text and the confirm button_

Submitting the dialog immediately shows a toast reading, in Simplified Chinese, "团队已禁用" ("Team disabled"), and every team-managed member is already a standalone account by that point.

**Re-enabling the team**: the status label reads "停用" ("Disabled"), and the action changes to **Enable team**. Selecting it and confirming the dialog — its text, also hardcoded in Simplified Chinese, reads "确认启用团队「团队名」？" ("Enable team "team-name"?") — shows a "团队已启用" ("Team enabled") toast, but this only flips the `status` field back. Accounts that were already released remain standalone; they are not automatically reclaimed as team-managed. The only way to bring those members back into team-managed mode is to send them a new team-managed invitation.

> [!NOTE]
> Two points here have no clear answer in the code and need confirmation from
> product or engineering: whether a released account's outstanding balance to
> the team carries over to the new personal account it receives, and whether
> re-inviting a released account as a team-managed member actually succeeds —
> the invitation-acceptance logic rejects team-managed invitations sent to an
> email that already has an account, and a released account almost certainly
> falls into that category.

## Transfer team ownership

The team's actual owner can hand the team over to another member using **Transfer owner**. This does not remove the current owner from the team.

> [!CAUTION]
> The natural reading of "transfer ownership" is "I give this team away and I'm
> no longer part of it." That is not what happens. The current owner's team role
> is switched from **Owner** to **Admin** in the same request — they stay in the
> team, keep team-governance access such as managing members, invitations, audit
> logs, groups, and image sharing, and keep managing instances in the team's
> space. What they lose is the owner role itself and every permission on the
> team's billing account (invoices, payment methods, and other financial
> actions), which is reassigned to the new owner. Neither the button, its
> description, nor the confirmation dialog mentions that the outgoing owner
> remains a team member.

| What happens                                                                                                                 | What does not happen                                                                                                                                                          |
| ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| The target member's team role changes to **Owner**                                                                           | The target member is not automatically added to the team — they must already be a member; the member picker excludes the current owner from the list                          |
| The current owner's team role changes to **Admin**, and they remain a team member                                            | The current owner is not removed from the team, and does not lose access to team-governance features covered by the default admin role                                        |
| The team's billing account owner field is updated to the new owner, and their billing permissions are synced to the full set | The outgoing owner's permissions on the team's billing account are not preserved — they are cleared, along with the ability to change team status (unless separately granted) |
| A `team:transfer_owner` entry is recorded in the audit log                                                                   | Projects, instances, and other resources owned by the team are not affected — they remain the team's                                                                          |
| The platform sends a notification email to both the outgoing and the new owner                                               | —                                                                                                                                                                             |

1. Open the team detail page and select the **Danger zone** tab.
2. Select **Transfer owner**. Only the actual owner sees this action.
3. If you have not completed a security check in the last hour, complete the verification page first.
4. In the dialog, pick the new owner from the member dropdown (owners are excluded from the list). If the team has no other members, the dialog falls back to a plain user-ID field instead — but the entered user must still already be a team member, or the transfer is rejected.
5. Confirm the dialog. Its text is hardcoded in Simplified Chinese, reading "确认转移「团队名」的团队所有权？" ("Confirm transferring team ownership of "team-name"?"). Select the confirm button to proceed.

_Interface illustration: Transfer owner confirmation dialog: the member picker, the selected-member notice, and the confirm button_

Submitting the dialog immediately shows a toast reading, in Simplified Chinese, "团队所有权已转移" ("Team ownership transferred"). The new owner's role becomes Owner and the previous owner's role becomes Admin in the same request; both receive the notification email.

**Is this reversible?** Yes, but there is no dedicated undo — because the permission to transfer ownership belongs only to whoever currently holds the owner role, the demoted former owner cannot reclaim it unilaterally. The new owner has to run **Transfer owner** again and pick the former owner as the target, the same way any other transfer works.

**What the previous owner can still do afterward**: as an admin, they keep team-governance permissions — managing members and invitations, viewing the audit log, managing roles and groups, sharing images, and managing, deleting, and configuring billing for instances in the team's space. What they no longer have is anything owner-exclusive (starting another transfer, and by default, changing the team's enabled status) and any permission on the team's billing account itself — the new owner has to grant those separately if intended.

## Related documentation

- [Invite and manage team members](/spaces/teams/members/)
- [Team roles and groups](/spaces/teams/roles-groups/)
- [Team billing and budgets](/spaces/teams/billing/)
- [Team lifecycle and audit](/spaces/teams/audit-lifecycle/)