Administrator guide
The panel dashboard is the admin surface of the enterprise panel. Everything you change here
is signed, versioned and picked up by daemons on their next fetch — sessions never need a
restart of the panel. All admin actions are role-gated (admin) and audited with their
actor.
Sign in with your organization email and password. On a fresh deployment the first admin
account is bootstrapped with PANEL_ADMIN_PASSWORD — see
Deploying the panel.
The dashboard has seven tabs: Catalog, Prompts, Connectors, Users, Teams & roles, Keys and Audit.
Catalog — MCPs and capability packs
Section titled “Catalog — MCPs and capability packs”Authorize or revoke the MCP servers agents may use. Each entry has an id, a display name,
an upstream endpoint, a scope (global or team), an optional team, and the upstream
secret. The secret stays in the panel: sessions reach the server through the local broker
on loopback, and the credential is injected there — the agent never sees it. Entries with
an empty secret get no Authorization header injected upstream.
Revoking an MCP removes it from the signed catalog; sessions lose it on their next fetch. Every authorize/revoke bumps the catalog version and is audited.
The same tab lists capability packs with their kind and default state, and lets you enable or disable each pack’s default per scope. Chronos ships three governed packs:
- Kairos — the method-skill pack (governed engineering workflows).
- Tempo — the output optimizer (runs at the adapter).
- Pulse — the reuse-first guardrail (runs at context).
Toggling a pack is a cascade change: it bumps the packs version and is audited.
Prompts — governed context
Section titled “Prompts — governed context”Company prompts, standards, skills and conventions: governed markdown applied to every
session of the company (global scope) or of a team. Each entry has a stable id, a name, a
kind (prompt, standard, skill or convention), a scope, and a markdown body (up to
48 KiB) edited with a live preview.
At session start the daemon downloads the signed context bundle, verifies the signature,
resolves the cascade and materializes the result into the agent’s managed context —
highest precedence, non-overridable, never committed to any repo. Each adapter injects it
natively (for example Claude Code via --append-system-prompt).
Saving or deleting an entry bumps the context version, so the next session created picks it up. The audit records the change with metadata only — the markdown body never appears in the audit trail.
Connectors — issue trackers
Section titled “Connectors — issue trackers”Connect a Jira or Linear connector once, organization-wide or per team. Each connector has
an id, a name, an endpoint (for example https://<yourOrg>.atlassian.net or
https://api.linear.app/graphql) and a write-only credential — the secret stays in the
panel and is never shown again.
Workspaces then bind a board or team in their committed .chronos/settings.toml
([integrations.jira] or [integrations.linear]) by the connector id.
Users — accounts and one-time passwords
Section titled “Users — accounts and one-time passwords”The panel is the organization’s identity source. This tab also holds the organization name
(rename is public at GET /v1/org and used by the sign-in pages).
Create a user with an email identity, a display name, teams, a role and optionally a
password. Creating a user without a password generates a one-time password shown exactly
once — hand it to the user through a safe channel. The user signs in with it and rotates
it themselves (POST /v1/me/password). Passwords are scrypt-hashed with Node built-ins;
hashes never leave the store.
From the same tab you can disable a user (blocks both panel sign-in and app login) or reset their credential (issues a new one-time password). User creation, status changes and resets are admin-only and audited.
Device approval
Section titled “Device approval”Developers connect the app with chronos login, a device-grant flow: the CLI shows a short
code and opens the panel’s /activate page. Approving a device requires signing in first —
the approved subject is the verified identity, never a free-text claim. The user enters
their email, password and the code (XXXX-XXXX) and approves the machine; the CLI then
receives its bearer, and the panel’s public signing keys are pinned on the device at login.
Disabling the user account revokes this path too.
Teams & roles
Section titled “Teams & roles”Manage each member’s team membership and role: developer, reviewer, maintainer or
admin. The role the panel returns drives what the local actor may do — for example, only
roles with pr.merge can merge. Changing a role in the panel changes the daemon’s actor
capabilities on its next fetch.
The signing keys behind the trust model. The active key signs new bundles; previous keys are retained in the trusted-key set so live sessions keep verifying after a rotation. Rotate from this tab when your key-management policy requires it; private keys never leave the server.
The panel-side audit tail: who authorized which MCP, which credentials were minted and by whom, cascade and role changes, and which sessions loaded which catalog version. It complements the daemon’s local session audit — see Audit & traceability.
Admin API
Section titled “Admin API”Everything in the dashboard maps to role-gated, audited routes under /v1/admin/:
| Route | Purpose |
|---|---|
GET /v1/admin/state | full admin view of the org state |
POST /v1/admin/mcp · DELETE /v1/admin/mcp/<id> | authorize / revoke an MCP |
POST /v1/admin/pack | toggle a pack’s default per scope |
POST /v1/admin/context · GET /v1/admin/context/<id> · DELETE /v1/admin/context/<id> | governed context CRUD |
POST /v1/admin/user · POST /v1/admin/user/status · POST /v1/admin/user/reset | create / disable / reset users |
POST /v1/admin/member | team membership and role |
POST /v1/admin/org | organization name |
POST /v1/admin/keys/rotate | rotate the signing key |