Command overview
beacon endpoint discover lists supported agent harnesses detected on the local host.
Command syntax
--all to include every supported runtime target, including runtimes that are not detected on the host. OpenClaw Gateway is discovered through its managed plugin, and its separate gateway OTLP export is validated through the beacon endpoint integrations openclaw commands after Gateway diagnostics export is configured.
Gemini CLI discovery looks for the gemini executable and ~/.gemini/settings.json, then checks whether local OTLP telemetry is enabled for Beacon. VS Code discovery checks Copilot Chat OpenTelemetry configuration and reports Beacon-managed state when the OTLP endpoint points at Beacon’s local receiver. GitHub Copilot CLI discovery looks for the copilot executable or ~/.copilot/config.json, then validates that COPILOT_OTEL_ENABLED=true and the effective OTLP endpoint points at Beacon’s local HTTP receiver, usually http://127.0.0.1:4318. Claude Code discovery looks for the claude executable and Claude settings paths; optional Claude hook status is available through beacon endpoint hooks status --harness claude. Antigravity CLI discovery looks for the antigravity or antigravity-cli executable, ~/.gemini/config, or ./.agents, then checks whether Beacon endpoint hooks are installed in ~/.gemini/config/hooks.json or ./.agents/hooks.json. Grok Build discovery checks whether Beacon’s managed hook file is installed at ~/.grok/hooks/beacon-endpoint.json or ./.grok/hooks/beacon-endpoint.json. Hermes Agent discovery looks for the hermes executable or ~/.hermes, then checks ~/.hermes/config.yaml for Beacon-managed hooks, identified by the endpoint settings flags (--log, --config, --cli) or a legacy BEACON_ENDPOINT_MODE=1 prefix, together with --platform hermes. OpenCode discovery looks for the opencode executable or ~/.config/opencode, then checks whether Beacon’s managed plugin is installed at ~/.config/opencode/plugins/beacon.ts. Cline discovery looks for ~/.cline and treats a cline executable as an additional signal rather than the deciding one, because Cline’s VS Code and JetBrains hosts ship no executable; it then checks whether Beacon’s managed plugin is installed at ~/.cline/plugins/beacon.ts. Pi discovery looks for the pi executable and treats ~/.pi/agent as an additional signal, because an npm, pnpm, or bun install is often absent from the inherited PATH while its state directory is not; it then reports whether Beacon’s managed extension is installed at ~/.pi/agent/extensions/beacon.ts, and reports a beacon.ts without Beacon’s marker as disabled rather than enabled. Oh My Pi discovery looks for the omp executable and treats the resolved agent directory as an additional signal for the same reason as Pi; it then reports whether Beacon’s managed extension is installed at ~/.omp/agent/extensions/beacon.ts, and honors PI_CODING_AGENT_DIR and PI_CONFIG_DIR when resolving that path. OpenClaw Gateway discovery looks for the openclaw executable and treats the extensions directory as an additional signal, because a gateway is commonly run as a daemon under an account whose PATH this process did not inherit; it then reports whether Beacon’s managed plugin is installed at ~/.openclaw/extensions/beacon-endpoint/, honors OPENCLAW_STATE_DIR when resolving that path, and reports a plugin directory missing either manifest as disabled rather than enabled, because OpenClaw skips such a directory silently. fx discovery looks for the fx executable and treats ~/.fx as an additional signal; because fx has no file Beacon writes into, its telemetry status reports how much of the session store under ~/.fx/sessions has actually been collected rather than whether a marker is present, distinguishing “no sessions yet” from “sessions present and none collected” from “collected and current”. Qwen Code discovery looks for the qwen executable and treats ~/.qwen as an additional signal, because an npm or version-manager install is often absent from the inherited PATH while its config directory is not; it then checks ~/.qwen/settings.json for Beacon hook commands carrying --platform qwen, reporting hooks turned off by disableAllHooks as disabled and invalid settings JSON as misconfigured rather than missing. Devin CLI discovery looks for the devin executable, ~/.config/devin, or ./.devin, then checks whether Beacon endpoint hooks are installed in ~/.config/devin/config.json or ./.devin/hooks.v1.json; devin remains a legacy alias for devin-cli. Devin Desktop discovery checks Cascade/Windsurf hook files at ~/.codeium/windsurf/hooks.json or ./.windsurf/hooks.json. Factory Droid discovery looks for the droid executable and validates the effective OTEL_TELEMETRY_ENDPOINT launch environment without treating customer-managed shell export values as Beacon-owned configuration. Set MDM-managed launch environments to Beacon’s local OTLP HTTP receiver through MDM or another customer-owned launch policy.
Flags
Examples
Show detected runtimes:Show detected runtimes
Print discovery results as JSON
Show all supported runtime targets
Use system endpoint paths while discovering
Related
Agent harness integrations
Compare supported runtimes and telemetry modes.
Runtime hooks
Install and inspect hook-based endpoint telemetry.