honeycomb
Get Honeycomb
honeycomb docs
GitHub Community latest

CLI reference

The `honeycomb` command-line tool is the single entry point for installing honeycomb, wiring it underneath your coding assistants, signing in, and running operational commands against your memory. It is a thin client of the local honeycomb daemon (default `127.0.0.1:3850`): every command that tou…

CLI reference

Derived from the honeycomb knowledge base, captured 2026-06. Commands and flags are transcribed from the engineering specifications, not from live --help output. Confirm exact spelling, flags, and behavior against your installed version with honeycomb --help and honeycomb <command> --help.

The honeycomb command-line tool is the single entry point for installing honeycomb, wiring it underneath your coding assistants, signing in, and running operational commands against your memory. It is a thin client of the local honeycomb daemon (default 127.0.0.1:3850): every command that touches memory, sessions, the codebase graph, or any other stored data sends a request to the daemon, which is the only process that talks to the storage backend. This keeps the CLI fast to start and keeps storage, encryption, and tenancy logic in one place.

This page documents the command surface as the knowledge base describes it. Where the knowledge base does not enumerate a specific flag, that is noted inline; confirm the detail against your installed version.

#Conventions

  • honeycomb is the global executable. Install it with the one-command installer (see Install).
  • Arguments in angle brackets (<value>) are required; arguments in square brackets ([value]) are optional.
  • Commands route through the daemon. If the daemon is not reachable, a command that needs it reports the failure on a single line and exits non-zero rather than printing a stack trace.
  • Two global flags are recognized by the dispatcher: --help / -h / help prints usage, and --version / -v / version prints the installed version.
honeycomb --help
honeycomb --version

#Command summary

Command Purpose
install Bootstrap entry: bring the daemon up, stamp the onboarding marker and referral code, open the dashboard
setup Detect installed assistants, wire their hooks, and bring the daemon up
connect <harness> Wire exactly one named assistant
uninstall [<harness>] Remove honeycomb's footprint from one assistant, or from every detected assistant
login Device-flow sign-in
status Report daemon connectivity, login state, and environment health
update Self-update the CLI, daemon, and assistant bundles
dashboard Open the local dashboard
remember Write a memory entry
recall Query memory (lexical plus semantic)
agent Manage agent_id scoping and per-agent settings
ontology Inspect and edit the memory ontology
secret Store, list, and use scoped secrets
skill Skillify scope, pull, unpull, and force operations
hook Inspect and re-wire lifecycle hooks
route Manage routing rules between agents and tables
sources Register and sync external source connectors
graph Build, query, and inspect the codebase graph
goal Manage org and session goals surfaced in agent context
org Organization administration (create, switch, list)
workspace Workspace administration within the active org
sessions prune Scoped cleanup of captured trace history
telemetry Inspect operator telemetry egress

The full top-level set above is what the knowledge base enumerates. Skillify operations that older Hivemind docs referenced as hivemind skillify ... are reached under honeycomb skill ... in this merged surface. The org and workspace verbs are the merged home of multi-tenant administration.

#Install

#honeycomb install

Bootstrap entry, the verb the one-command installer scripts hand off to once the global package is laid down. It composes existing daemon seams and is a thin daemon client.

Synopsis

honeycomb install [--ref <code>]

Description

install does three things, in order:

  1. Health-gate the daemon up (idempotent: an already-healthy daemon is a no-op, never a second bind of 127.0.0.1:3850). If the daemon never becomes reachable, the verb prints a "daemon didn't start" message plus a retry hint and exits non-zero.
  2. Persist the onboarding marker (phase: "installed" plus the effective referral code) into ~/.deeplake/onboarding.json. This write is fail-soft: a hiccup never fails the install.
  3. Open the dashboard, best-effort at honeycomb.local, always falling back to the http://127.0.0.1:3850/dashboard loopback. The opener refuses any non-local URL. A failed launch is non-fatal; the URL is printed for you to open by hand.

Re-running is safe.

Options

Flag Description
--ref <code> Override the referral code attributed at sign-up. The effective code resolves --ref first, then onboarding.ref, then the build-time default. An explicit blank value omits attribution.

The one-command installer that lays down the package before this verb runs is:

# macOS or Linux
curl -fsSL https://get.theapiary.sh | sh

# Windows PowerShell
irm https://get.theapiary.sh/install.ps1 | iex

#Setup, connect, uninstall

#honeycomb setup

Detect every installed coding assistant and wire each one: patch its config, write the compiled hook handlers, link team skills, and register the MCP server where the assistant speaks MCP. The wiring is idempotent and foreign-safe, so re-running writes nothing where nothing changed and never touches a third party's hooks.

Synopsis

honeycomb setup

It is safe to run again at any time, for example after installing a new assistant.

#honeycomb connect <harness>

Wire exactly one named assistant rather than every detected one.

Synopsis

honeycomb connect <harness>

<harness> is one of the six supported assistants: claude, codex, cursor, hermes, pi, or claw (OpenClaw). Confirm the exact accepted identifiers against your installed version.

#honeycomb uninstall

Reverse only honeycomb's footprint: remove its config entries and its skill links, and leave foreign entries untouched.

Synopsis

honeycomb uninstall [<harness>]
honeycomb uninstall [--only <platforms>]

With no target, uninstall reverses every detected assistant. With a named harness (or an --only list), it reverses just those. An emptied config is cleanly unlinked rather than left as an empty object.

#Authentication

#honeycomb login

Sign in with the OAuth 2.0 Device Authorization Flow (RFC 8628), which works for headless installs, remote SSH, and local terminals. The CLI requests a device code, you approve in a browser, the CLI polls for a token, and the daemon mints a long-lived org-bound token. Credentials are written to the shared ~/.deeplake/credentials.json at file mode 0600.

Synopsis

honeycomb login

The same device flow can also be driven from the dashboard's "First time setup" button, which is the recommended path for new users (you read the code on the page instead of copying it out of a terminal). On session start the daemon also heals a drifted org token automatically: if the token's org_id claim disagrees with the active organization, it re-mints a corrected token.

#honeycomb status

Report daemon connectivity, login state, and environment health (daemon reachable, signed in, hooks wired).

Synopsis

honeycomb status

#Update

#honeycomb update

Self-update the CLI, the daemon, and the per-assistant bundles.

Synopsis

honeycomb update [--dry-run]

Options

Flag Description
--dry-run Report what would be updated without applying changes.

#Memory

#honeycomb remember

Write a memory entry to the memory table through the daemon.

Synopsis

honeycomb remember "<text>"

The knowledge base shows additional metadata (for example importance and tags) on the equivalent SDK call. Whether those are exposed as CLI flags is not enumerated in the knowledge base; confirm against honeycomb remember --help on your installed version.

Example

honeycomb remember "we deploy from the release branch, never from main"

#honeycomb recall

Query memory with hybrid lexical plus semantic recall through the daemon. When the semantic path is unavailable, recall transparently falls back to the lexical arms and still answers.

Synopsis

honeycomb recall "<query>"

Example

honeycomb recall "how do we deploy"

#Dashboard

#honeycomb dashboard

Open the local dashboard web page served by the daemon at the loopback address. The dashboard shows your memories, the state of each connected assistant, team skills, a map of your codebase, and overall health.

Synopsis

honeycomb dashboard

#Codebase graph

The graph verb builds and inspects a live graph of files, symbols, and edges extracted from your source with tree-sitter (no language server, no LLM). The build is owned by the daemon; the CLI triggers it. The local snapshot is the authoritative source for reads.

#honeycomb graph build

Walk the repository, extract every supported source file, aggregate one snapshot, and write it to disk. A successful build best-effort pushes the snapshot to the cloud when you are authenticated.

honeycomb graph build

#honeycomb graph init

Install a managed post-commit hook that asks the daemon to rebuild the graph after each commit.

honeycomb graph init

#honeycomb graph pull

Fetch a teammate's cloud snapshot for the current HEAD.

honeycomb graph pull

#honeycomb graph diff <sha1> <sha2>

Load two snapshots by commit and print added and removed node and edge counts with examples.

honeycomb graph diff <sha1> <sha2>

#honeycomb graph history

Tail the per-repository history.jsonl audit log, where each entry records its own commit, hash, counts, and trigger.

honeycomb graph history

The knowledge base also describes query endpoints (find, impact, neighborhood, tour, and others) that agents read through the codebase-graph browse surface rather than as distinct CLI verbs. See the knowledge graph spec and the recall and retrieval spec.

#Sessions

#honeycomb sessions prune

Scoped cleanup of your captured trace history. The command groups your session events by path, lets you filter, and asks the daemon to delete the matching rows from the sessions table and the corresponding summaries from the memory table, so traces and summaries never drift out of sync.

Synopsis

honeycomb sessions prune [--before <date>] [--session-id <id>]

Options

Flag Description
--before <date> Prune sessions whose first event is before the given date.
--session-id <id> Prune a single session by id.

These two filters are the ones the knowledge base names. Confirm the exact date format and any additional filters against your installed version.

#Goals

#honeycomb goal

Manage org and session goals that are surfaced in agent context. Goals are backed by the structured goals table and also appear as markdown files in the memory browse surface, so the same objective can be managed either with the CLI or by editing files. honeycomb goal list reads only the structured table.

honeycomb goal list

The full subcommand set (add, close, transition between opened, in_progress, and closed) is implied by the goal lifecycle but not exhaustively enumerated in the knowledge base. Confirm against honeycomb goal --help.

#Secrets

#honeycomb secret

Store and use scoped secrets that an agent can cause to be used without ever reading. Secrets are encrypted at rest on the daemon host (not in the storage backend) and are never returned to a caller. The API exposes names but never values, and there is deliberately no "read a secret value" path.

honeycomb secret list

The store, list, delete, and exec operations are the ones the knowledge base names (mirroring the /api/secrets/* routes). Confirm the exact CLI subcommand names and arguments against honeycomb secret --help.

#Skills

#honeycomb skill

Manage team skills mined from your sessions: set sharing scope, pull team skills onto disk, unpull them, and force operations. Skills auto-pull on session start, so a teammate's freshly mined skill becomes visible within seconds; the explicit verbs are for manual control.

honeycomb skill scope team --users alice,bob
honeycomb skill pull --force

The --users and --force flags shown above are the ones the knowledge base names. Confirm the complete subcommand and flag set against honeycomb skill --help.

#Other commands

The knowledge base names these additional top-level verbs without enumerating every subcommand and flag. They are listed here for completeness; confirm their surface against your installed version.

Command Purpose
honeycomb agent Manage agent_id scoping and per-agent settings.
honeycomb ontology Inspect and edit the knowledge-graph ontology (entities, aspects, claims).
honeycomb hook Inspect and re-wire lifecycle hooks for each assistant.
honeycomb route Manage routing rules between agents and tables.
honeycomb sources Register and sync external source connectors.
honeycomb org Organization administration: create, switch, list.
honeycomb workspace Workspace administration within the active organization.
honeycomb telemetry --show Render, in plaintext, exactly what operator telemetry has been and would be sent.

#Environment variables

These environment variables change CLI and daemon behavior. They are read by the daemon and the hooks rather than passed as flags.

Variable Effect
HONEYCOMB_PORT, HONEYCOMB_HOST, HONEYCOMB_BIND Override the daemon's port, host, and bind address (a team deployment widens the bind beyond localhost).
HONEYCOMB_ORG_ID Override the organization selected at login.
HONEYCOMB_CAPTURE=false Read-only mode: capture hooks run but write no trace data; recall and search still work.
HONEYCOMB_EMBEDDINGS Opt out of semantic recall. Unset, true, or 1 keeps embeddings on; false or 0 turns them off and recall uses the lexical fallback.
HONEYCOMB_TELEMETRY=0, DO_NOT_TRACK=1 Silence all operator telemetry.
HONEYCOMB_AUTOPULL_DISABLED=1 Disable the session-start auto-pull of team skills.
HONEYCOMB_ASSET_AUTOPULL_DISABLED=1 Disable the session-start auto-pull of portable assets.
HONEYCOMB_GRAPH_PUSH=0 Skip pushing codebase-graph snapshots to the cloud.

The pipeline stage toggles (the HONEYCOMB_PIPELINE_* family) are documented in the capture and memory spec.