Skip to main content
Manage server settings, users, security policy, SSO, audit data, and the submission review queue. All 24 workflows support --output table|json. JSON mode never prompts or emits progress banners. Destructive JSON commands require --force or --yes. Core administration requires the admin role. Review commands are also available to global reviewers and authorized teamspace owners or reviewers. Some role changes require super_admin.

Commands

Settings

settings returns the direct settings array. Sensitive values are redacted by the server. set returns the server setting object and never echoes the supplied value in human output. A positional setting value may be retained by shell history. Prefer deployment secret files for sensitive settings that support external management.

Users and roles

List users:
Create a user and let the server generate a password:
Supported roles are super_admin, admin, reviewer, and user. Create with a chosen password only when shell-history exposure is acceptable:
Reset interactively in human mode:
Generate a password without prompting:
JSON reset requires --generate. Created and generated passwords are returned once. Treat the entire result as a secret and do not paste it into logs, issues, or chat. Change a role:
Delete a user:
Human deletion prompts unless --force or --yes is present. JSON deletion requires confirmation through one of those flags.

Diagnostics and policy

diagnostics returns the direct health object. Trace privacy responses return trace_privacy. Cache clear returns the number of cleared entries.

SAML

Show redacted configuration:
Create or replace configuration:
Every update requires the IdP entity ID, SSO URL, and X.509 certificate. Optional flags include --idp-slo-url, --sp-entity-id, --jit|--no-jit, and --active|--inactive. Certificate and private-key material is never returned by configuration reads. Delete configuration:
JSON deletion requires --force or --yes.

SCIM tokens

List results contain metadata and token prefixes only. Creation returns the plaintext bearer token once. Treat that result as a secret. Revocation requires a complete UUID and prompts in human mode unless forced.

Security events

Severity accepts info, warning, or critical. Limit accepts 1 through 1,000 and offset accepts zero or greater. JSON returns the server envelope with events and total.

Audit log

Query events:
Available filters are action, actor, resource type, sensitivity, outcome, source, start date, and end date. Source accepts server or cli. Limit accepts 1 through 500. Print CSV to stdout:
Write CSV atomically:
Print JSON:
Write JSON atomically:
Existing files prompt in human mode. JSON mode fails with a conflict unless --force or --yes is provided. Audit exports can contain sensitive administrative data.

Review queue

Reviews are revision-based and use the observal review command group. Content is visible only to participants and authorized reviewers.
Review data can include submitted configuration. Handle it as potentially sensitive. Credentials are redacted in snapshots. Submit a verdict and publish. Approval never publishes by itself unless the effective policy sets automatic publishing:
Review policy sets required approvals (0 to 5 per type), self-approval, and automatic publishing. A teamspace may set one policy for team-visible items and another for its public namespace; neither can be looser than the organization policy for public items. Zero approvals with automatic publishing is the “auto approve” setting.
Use observal review --help for threads, comments, reviewer requests, dismissal, and watch/mute.

Automated checks (experimental)

Experimental and off by default. A super admin or admin turns it on under Settings, Experimental (experimental.review_checks). While off, the checks tab, queue labels, settings and endpoints below are hidden, and automated checks neither run nor block publishing; the built-in secret, schema and skill folder checks still apply. Each revision runs built-in checks (secret scan, required fields, skill folder validity) plus configurable automated checks on the worker, within about 15 seconds of submission: Checks that contact external hosts, other than the Git source check, are off by default. Every check is advisory by default; an admin or team owner can mark one as blocking. A blocking check that is queued, running, failed or errored holds publication, including automatic publication. A check that could not run reports skipped or error, never pass. Settings are scoped. Admins edit the organization settings (used for public items) with the gear button on the review queue, or PUT /api/v1/admin/review-checks. Team owners and admins edit their teamspace’s settings (used for team-visible items) on the teamspace Settings tab, or PUT /api/v1/teams/{id}/review-checks. Changes apply to new revisions; POST /api/v1/reviews/{number}/checks/rerun re-queues an open review under the current settings. These checks are static and network lookups: they do not prove a component is safe or that it works.

Exit codes