HOTL Host Capability Matrix

July 6, 2026 ยท View on GitHub

Generated from runtime/capabilities/catalog.json (schema v1); claims verified 2026-07-05. Do not edit this table by hand.

This matrix separates three different claims:

  • Provider maturity describes what the provider documents.
  • Local detection is reported by scripts/hotl-capabilities.sh probe and can remain unknown even when a host is installed.
  • HOTL support describes whether HOTL has a conformant implementation, only a candidate native integration, or a fallback.

The Phase 1 catalog is descriptive. It does not select an execution driver or change permissions.

HostCapabilityCategoryProvider maturityHOTL supportMinimum versionObservabilityAvailability conditionsSecurity boundaryFallbackVerifiedSources
claude-codeAgent viewautomationresearch previewcandidate2.1.139partialAgent view available in the active Claude Code distributionBackground sessions continue without a terminal and may use isolated worktrees; agent-view row state is scheduling telemetry, not HOTL completion evidence.hotl-fallback:workflow-execution2026-07-05source 1
claude-codeWorktree-isolated sessionsisolationstablecandidatenot specifiedpartialGit repositoryFilesystem and command permissions continue to apply inside the isolated checkout.hotl-fallback:worktree-isolation2026-06-29source 1
claude-codeLifecycle hookslifecyclestablecandidatenot specifiedfullHooks not disabled by user or managed settingsHooks execute with the trust level of the local Claude Code process and must be reviewed as code.hotl-fallback:durable-state2026-06-29source 1
claude-codePlugin background monitorslifecyclestablecandidate2.1.105fullInteractive CLI with Monitor tool availability
Plugin enabled
Monitors run unsandboxed at hook trust level and require careful command review.hotl-fallback:durable-state2026-06-29source 1
claude-codeAgent teamsorchestrationexperimentalcandidate2.1.32partialExperimental agent teams enabled
Task can be partitioned without conflicting shared-file edits
Each teammate is an independent Claude Code session with team coordination tools.hotl-fallback:workflow-execution2026-06-29source 1
claude-codeBackground subagentsorchestrationstablecandidate2.1.198partialClaude Code session with Agent tool availability
Background tasks not disabled by configuration
Subagents run in the background by default but their completion notification is not verification or HOTL completion evidence.hotl-fallback:workflow-execution2026-07-05source 1 source 2
claude-codeDynamic workflowsorchestrationresearch previewcandidate2.1.154partialPaid plan or supported API/provider
Dynamic workflows enabled where required
Spawned agents inherit the workflow tool allowlist and use accept-edits behavior for file changes.hotl-fallback:workflow-execution2026-06-29source 1
claude-codeGoal and loop continuationorchestrationstablecandidate2.1.139partialClaude Code distribution exposing /goal and /loop
Hooks and managed policy permit the selected continuation path
Goal and loop commands continue host turns but do not replace HOTL iteration bounds, gates, ownership, or receipts.hotl-fallback:workflow-execution2026-07-05source 1
claude-codeSubagentsorchestrationstablecandidatenot specifiedpartialClaude Code session with the Agent tool availableSubagent tools, model, permissions, and MCP access are scoped by the agent definition and parent session.hotl-fallback:workflow-execution2026-06-29source 1
claude-codeAuto permission modesecurityresearch previewcandidate2.1.83partialEligible plan and supported model/provider
Workspace admin enablement when required
A classifier reviews actions after hard permission rules; auto mode is not a substitute for sensitive-operation review.hotl-fallback:human-gates2026-06-29source 1
codexAutomationsautomationstablecandidatenot specifiedpartialCodex app
Automation availability for the active account and workspace
Automation runs use the configured project permissions and workspace policy.hotl-fallback:workflow-execution2026-06-29source 1
codexRemote connectionsautomationstablecandidatenot specifiedpartialCodex Remote available for the active account
Authenticated paired host and supported mobile or desktop client
Remote control uses the connected host's project, credentials, permissions, and approval boundary; remote UI status is not a HOTL receipt.hotl-fallback:workflow-execution2026-07-05source 1 source 2
codexBrowser Developer modebrowserstablecandidatenot specifiedfullCodex app Browser or Chrome integration
Full CDP access enabled and allowed by workspace policy
Full CDP inspection requires explicit approval and can be disabled by managed policy.hotl-fallback:typed-verification2026-06-29source 1
codexManaged worktreesisolationstablecandidatenot specifiedpartialGit repository
Codex app or supported local surface
Filesystem access remains bounded by the active Codex permissions.hotl-fallback:worktree-isolation2026-06-29source 1
codexLifecycle hookslifecyclestablecandidatenot specifiedfullHooks feature enabled
Non-managed hook definition reviewed and trusted
Non-managed command hooks require hash-based user trust before execution.hotl-fallback:durable-state2026-06-29source 1
codexLocal, worktree, and remote thread handofflifecyclestablecandidateCodex app 26.616partialMatching project available on the destination host
Connected and trusted local or remote host
Handoff moves host execution context but does not transfer HOTL controller ownership until the new controller explicitly claims or takes over the run.hotl-fallback:durable-state2026-07-05source 1 source 2
codexMemoriesmemorystablecandidatenot specifiedpartialMemories available for the active account
Memory use or generation enabled
Memory use follows account, workspace, and per-thread controls.none2026-06-29source 1
codexGoal modeorchestrationstablecandidatenot specifiedpartialCodex app, CLI, or IDE extension
Goal mode available on the active surface
Goal mode can continue for hours or days but remains inside the active Codex sandbox and approval policy; it is not HOTL completion evidence.hotl-fallback:workflow-execution2026-07-05source 1
codexSubagentsorchestrationstablecandidatenot specifiedpartialEnabled by default in current Codex releases
Spawned only after an explicit user request
Subagents inherit parent sandbox and live approval overrides.hotl-fallback:workflow-execution2026-06-29source 1
codexNative code reviewreviewstablecandidatenot specifiedpartialGit repository with a reviewable diff, commit, or base branchReview is read-oriented unless the user separately authorizes fixes.hotl-fallback:reporting2026-06-29source 1
hotl-fallbackHOTL worktree isolationisolationstableconformant2.18.0fullGit repository with at least one commitProtected branches, dirty worktrees, and branch collisions stop according to HOTL preflight rules.none2026-06-29source 1
hotl-fallbackHOTL workflow executionorchestrationstableconformant2.18.0fullHOTL runtime or inline executor availableUses the active host's shell sandbox and approval boundary while HOTL enforces controller ownership, workflow order, retry limits, aggregate budgets, gates, and effect evidence.none2026-07-05source 1
hotl-fallbackDurable run statepersistencestableconformant2.18.0fulljq installedSerialized, revisioned state remains local under the execution root and is gitignored by default; explicit leased controller ownership prevents concurrent mutation and age alone never permits takeover.none2026-07-05source 1
hotl-fallbackDurable execution reportingreviewstableconformant2.18.0fulljq installed for state-managed reportingReports default to concise successful output and captured failure evidence; missing reports are reconstructed from authoritative state and completion remains false until disposition is recorded.none2026-07-05source 1
hotl-fallbackRisk-sensitive human gatessecuritystableconformant2.18.0fullInteractive controller available for human gatesHigh-risk human gates cannot be auto-approved.none2026-06-29source 1
hotl-fallbackTyped verificationverificationstableconformant2.18.0fullHOTL runtime available
Required verifier capability available or human fallback accepted
Verification commands run inside the active host shell boundary.none2026-06-29source 1

HOTL support states

  • candidate: provider capability identified for a future native adapter; no HOTL conformance claim yet.
  • experimental: a HOTL integration exists but is opt-in and not yet conformant.
  • conformant: deterministic HOTL contract scenarios pass for the implementation.
  • fallback_only: HOTL deliberately uses a generic fallback rather than a native integration.
  • unsupported: HOTL has no safe native or fallback path for the capability.
  • deprecated: the integration remains visible only for migration.

Interpretation rules

  • An installed executable does not prove plan entitlement, rollout availability, administrator enablement, or usable permissions.
  • Preview and experimental capabilities remain opt-in even when locally detected.
  • unknown is an evidence-preserving result, not an error and not a synonym for unavailable.
  • Host security controls remain authoritative when they are stricter than HOTL policy.
  • Relevant catalog rows must be refreshed from official sources when a driver or support claim changes.