Session screen

What is one supervised agent session actually allowed to do right now? The capability document, the tool grants, the loaded release, the liveness contract, and every recent decision — for the one session selected in the rail. This is also the screen for session-scoped policy enabling and OMP adapter reload; reloading changes neither policy selection nor process identity (concepts/session-enable).

#Header and rail

Title Session; scope counts live sessions; freshness reads updated <time> from the selected record. Actions: Refresh sessions (secondary) and — only while the selected session does not already have every catalogued hook enabled — the primary Enable all hooks. The facet rail lists every live session as <agent> · <project directory> with its loaded-hook count and runtime tone; the rail footer names the control channel: Application Support/Tama/session-control. Records are polled once per second while an authorized operator is signed in; the button re-reads on demand.

For an OMP session, Reload adapter sends the same validated request as tama sessions reload --session ID. It reports success only after receiving that process's loaded adapter digest. An unsupported already-loaded entry refuses with instructions for its in-terminal reload command; the action never starts a replacement session.

When the selected session holds a capability, Withdraw access sends sessions/capability/revoke with the session and its harness, the operation tama sessions capability revoke --session ID --agent HARNESS runs: the grant is null at once and the build gate stops admitting it. The answer (revoked, none-held or no-override) or the product's refusal is shown as the mutation's outcome, and the session list is read again.

#Faults

Each alert is a distinct failure with its own verbatim title:

• Session control unavailable — discovery itself failed; the detail is the error sentence, including Tama found only legacy v1 session records. Reinstall the verified bundled runtime, then stop or resume the affected agent session to publish v2 state. (runbook).
• System policy error — the session record carries a policy error; actions are Approval settings and, when the record names a support URL, Platform support.
• Hook registry failed to load — the runtime's own registry load error, verbatim.
• The runtime is serving a stale registry — reloadRequired with no pending reload; the detail states both identities: This session loaded release <loaded> and the installed release is <installed>. Enabling every hook reloads the registry in place. — with an inline Enable all hooks action (runbook).
• The runtime holds overrides for hooks this build does not declare — the unknown hook ids, listed.

OMP sessions also show Loaded OMP adapter, or Loaded adapter identity unavailable when their entry does not publish a digest. Remote adapter reload unavailable identifies an older entry without this control operation. Last runtime or adapter reload failed displays the actual lastReloadError. A matching policy release alone is not evidence that the JavaScript adapter has been replaced. Agent Git editors not configured (danger) shows the adapter's gitEditors.error verbatim when tama hook pre-bash --git-environment failed for the session, whose ordinary tool calls are then refused; a failure published without a cause is named as a broken status contract. Agent Git editors not reported (warning) identifies an adapter that predates managed Git editors, so a Git command that opens an editor can wait for a keyboard; Reload adapter loads the installed one. A session whose gitEditors.configured is true shows neither. The same runtime.gitEditors object is in tama sessions --json.

With no live session and no error: No supervised session is running, with the exact expectation — Tama refuses to start an agent unless the platform has a ready kernel-enforcement backend. Open or resume a supported coding-agent session, and it appears here within a second.

#Hook state per session

One table across every live session before any is selected: SESSION, GLOBAL STATE, LOADED, and ALLOWLIST. The record's runtime status distinguishes enforcementMode (all or only) and its sorted machineEnabledHookIds from the session's additive enabledHookIds. Under emergency disable, the machine selection remains visible but is bypassed, so only the generation-bound session allowlist can run. These are the same facts tama sessions and tama_hook_runtime_status expose.

#Counters

Registered (hooks the runtime knows), Loaded (hooks the runtime can run; warns when it differs from registered), Overrides (allowlisted in this session during a global disable, suppressed otherwise; warns when nonzero), Decisions (semantic events recorded).

#Task scope

Below the session's last turn ending, the Task scope panel shows the work the session declared it serves — Working (the defect, the task, or both), Touches (the repositories its changes are held to), the operator's words, and whether it serves the instruction being served — or This session has declared no task scope. Its fields declare a defect, a task and repositories for the selected session, and Clear removes the declaration; both run the same declaration and refusals as tama task scope through tama request task-scope/…, and a refusal is shown in the command's own words. Another session that declared the same defect is shown as Also declared.

#Session capability

The signed authorisation the session holds for privileged tool use (concepts/capability): Lifetime, Expires at (Not bounded by time), Remaining uses (Not bounded by count, warning at one or fewer), Issued by, Schema version, Nonce, Release, Catalog checksum. Without one: No capability has been issued to this session. Every privileged tool call is decided by the standing policy alone. The grants table (TOOL / ACTIONS) states the empty cases exactly: No capability, so no grants. and The capability carries no tool grants; it authorises nothing by itself.

#Runtime and decisions

The Runtime box shows Loaded release, Installed release, Catalog checksum, and Liveness — heartbeat, <ttl>s TTL or process <pid>, the two modes the supervisor publishes. During a global disable it adds: Hooks are globally disabled on this machine. This session runs only the policies in its allowlist. Recent decisions is the register of what policy actually decided, newest first — WHEN, EVENT, HOOK, DECISION (blocking decisions get the danger chip; the trailing count is blocks) — with the most recent blocking reason printed verbatim below the table. The same reason headlines Posture.

#Mutations

Enable all hooks reports Enabling every registered hook in session <id>… then <n> hooks enabled in <agent> session <id>.; the single-hook enable lives on Hooks and reports <hook-id> is enabled in <agent> session <id>. Both travel as private request files the session's own supervisor validates and applies; rejection (The agent runtime rejected the session-control request: <reason>) and session exit (The agent session ended before the session-control request completed.) are reported failures, never assumed success. The session list is read again whenever the session-control directory changes or a listed agent process exits; a directory Tama cannot watch is reported as Tama could not watch the session-control directory <path>: <reason>.

#Inspector

Selected: Project, Control key (first 12 of 64), Updated at, Policy mode, Policy backend, Backend capabilities (None reported when empty); badges Kernel-gated / Backend not ready / Not configured plus the capability lifetime. The screen states its own boundary on the screen: it can Enable a hook in one live session and Enable every registered hook and reload that session; it never can Disable a hook for one session, Issue, extend or revoke a capability, or Read the agent's transcript or tool arguments. Unselected, it states the ownership rule: Session records are written by the supervised runtime into Application Support and removed when the process ends. Tama reads them; it never creates one.