opschain admin users disable

Included from Basic tier

Disables a user: new logins are refused and every live credential the user holds — v1 tokens, sessions and api keys — is revoked immediately — this is the "cut access now" verb, not a soft flag. The account and its history remain; enable reverses it. The verb rides the v2 UserService.DisableUser RPC and is valid for ANY identity — local, directory (ldap), federated (oidc/github) and service-account rows alike (superseded the earlier local-only lifecycle rule for disable/enable): the marker is OpsChain-local shadow state, so this never writes to the provider — still block the leaver in the provider as well.

The verb is on the step-up floor — single and --bulk alike: a session without a live elevation is refused with the typed STEP_UP_REQUIRED error, surfaced verbatim with a hint naming the CLI elevation flow (opschain elevate with a TOTP or recovery code; a session signed in through an idp-mode provider re-authenticates at the IdP instead). Break-glass accounts and sessionless credentials (native api keys, the static admin token) pass — the floor binds interactive sessions.

A same-named pair (e.g. a local break-glass account shadowed by a directory row) is ambiguous: --provider selects the row by its auth_provider value, and without it the refusal names the matches.

opschain admin users disable emergency.admin
Disabled emergency.admin (provider local, break-glass)

After a successful disable the verb warns about the user's standing automations — the triggers and scheduled activities their identity executes: rows naming them run_as, plus rows they created with no explicit run_as (a row someone else runs as survives their disable) — because those firings now refuse identity resolution until reassigned:

opschain admin users disable carol
Disabled carol (provider ldap:corp)
Warning: carol's standing automations will refuse firing until reassigned ...:
  triggers (2): bot-run, nightly-deploy
  scheduled activities (1): deploy (/projects/demo)

The warning never blocks the disable. opschain admin users reassign-automations moves everything onto a service account in one verb ; the run-as flag of opschain triggers update repoints a single trigger. The GUI's disable dialog (Administration → Users) shows the same offboarding summary — triggers, scheduled activities and the agents the user owns (agent_count, agent_names) — and the disabled row's Reassign automations… is the repair verb.

--bulk disables many users in one call: pass user ids or usernames as arguments, or pipe them whitespace-separated on stdin. Each member succeeds or is refused independently (never all-or-nothing); an already-disabled member reports unchanged. The verb exits non-zero when any member was refused, after reporting every row:

opschain admin users disable --bulk carol 019a1111-aaaa-7bbb-8ccc-ddddeeee0001 nobody
disabled  carol
disabled  admin
refused   nobody: not found
2 of 3 disabled, 1 refused

-o json|yaml prints the updated user document (single form) or the per-member result rows (--bulk), owned_automations included.

Flags

Flag	Meaning
--provider <auth_provider>	Select the identity provider's row (local, ldap:<key>, oidc:<key>, …) when the username exists under more than one.
--bulk	Write many users in one call: ids/usernames from the arguments, or whitespace-separated on stdin when no arguments are given.
--server <url>	Server base URL (default: the active context / OPSCHAIN_SERVER).
--auth-token <token>	Admin bearer token override (default: your opschain login session, then $OPSCHAIN_ADMIN_TOKEN, then the token stored by opschain admin login).

Exit codes: 0 on success, 1 when the user does not exist, any bulk member is refused, or the token is rejected, 2 for the connection usage errors on opschain docs cli/admin-users.

See also

• opschain docs cli/admin-users-enable — the inverse.
• opschain docs cli/admin-users-reset-password — revoking refresh tokens while keeping the account usable.
• opschain docs cli/triggers-update — reassigning a stranded trigger's run_as identity.