Operator Console

Inspect sessions, approvals, tenants, and persistent instances from the authenticated Node server.

The Node server includes a compact operator console at /admin. It uses the same authentication, tenant binding, and admin:read permission checks as the admin APIs. Its warm-paper surfaces, burnt-sienna emphasis, compact controls, and light/dark palette follow the same Fabric family contract as @fabricorg/ui. The console remains self-contained so loading @fabric-harness/node never introduces a React or browser-asset dependency.

FABRIC_HARNESS_API_TOKEN="$API_TOKEN" fh dev --port 4317

Open http://localhost:4317/admin, enter the API token, and connect. The token is kept in browser sessionStorage and sent as a bearer header; it is not written to the server-rendered page.

What operators see

The console combines tenant-scoped sessions, durable queue state, persistence health, and only the actions allowed for the authenticated principal. These screenshots are deterministic, sanitized UI states; no client data, workspace token, or environment identifier is embedded in the documentation.

Fabric Harness Operator Console listing three tenant-bound persistent agent sessions with replay, abort, and delete controls — Representative UIThe authenticated console keeps session identity, tenant scope, health, queue state, and permitted actions visible together.

Fabric Harness Operator Console showing one pending exact-input approval and one completed approval — Representative UIApproval state remains attached to the exact session and effect; controls appear only when the operator has permission.

The console provides paginated, searchable views for:

finite jobs and persistent agents;
sessions, runs, and active durable submissions;
built-in tools and pending or completed approvals;
persistence, queue, and worker health;
session cost metrics, policy decisions, and the audit trail.

Operators with approval:write can approve or reject a pending request. Operators with session:replay can fork a session from any durable entry, while session:abort and session:delete control abort and cascade deletion. Buttons are hidden when the authenticated principal lacks the corresponding permission; the server independently authorizes every action.

An application user does not need admin:read merely to handle approvals. Use the tenant-scoped GET /approvals endpoint or fh approvals --url <app-base-url> to discover visible requests, then fh approve or fh reject against the same remote URL. The /admin console remains reserved for operators who need broader run, health, audit, and replay access.

All collection endpoints use the same pagination shape:

{
  "items": [],
  "total": 0,
  "offset": 0,
  "limit": 50,
  "nextOffset": null
}

Use ?offset=0&limit=50&q=running. A tenant-bound principal only receives its own tenant. A principal allowed to operate several tenants can add ?tenant=acme; the server validates that selection against the principal before reading data.

Custom SSO deployments should use cookie authentication in authenticate, so the console can load without a separate bearer token. Assign operators admin:read, plus the action permissions they need. The APIs remain the source of truth; the console does not bypass RBAC or tenant isolation.

Operator Console

What operators see

On this page