hcom is a single-binary CLI that hooks coding agents together so they can message, observe and spawn each other across terminals. It is useful for multi-agent pipelines, but its relay trust model is all-or-nothing, which limits where it fits.

Can I use aannoo/hcom commercially?

Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is aannoo/hcom still maintained?

Yes. The repository last received commits 2 days ago.

What programming language is aannoo/hcom written in?

Mainly Rust, according to GitHub's language statistics.

hcom Review: Cross-Terminal Messaging for Coding Agents

At a glance

What is it?: hcom is a single-binary CLI that hooks coding agents together so they can message, observe and spawn each other across terminals. It is useful for multi-agent pipelines, but its relay trust model is all-or-nothing, which limits where it fits.
Who is it for?: Adopt hcom if you already run several coding CLIs in separate terminals and want them to hand work to each other without copy-paste, and if every device you would enroll is one you would give shell access to. Do not adopt it if you need scoped relay permissions, forward secrecy, or per-device authorization, because the documentation states the relay is one trust domain with an all-or-nothing join token that has no expiry and no revocation list.
Can I use it commercially?: Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository last received commits 2 days ago.
What is it written in?: Mainly Rust, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 10, 2026 · aannoo/hcom

The coordination gap between coding CLIs

Running Claude Code in one terminal and Codex in another gives you two capable agents that cannot see each other. The usual workaround is a human copying output from one window into the other, which breaks the moment a task needs several rounds. hcom targets that gap. It is a CLI that coding agents use to message, watch, and spawn each other across terminals, and the README states it integrates with Claude Code, Codex, OpenCode, Kilo Code, Pi, Oh My Pi, Antigravity, Cursor, Kimi, Gemini and Copilot in any combination without changing how you use them. The intended user is someone already running more than one of these tools. The README lists the use cases directly: coordinate pipelines, run different AI CLIs as each other's subagents, or replace copy-paste. A single agent user gets nothing from it.

Hooks, a SQLite database, and mid-turn injection

The README gives the data flow in one line: agent to hooks, hooks to db, hooks to other agent. Hooks record activity to a local SQLite database and deliver messages from it. There is no background service; the single Rust binary is the whole runtime. Delivery timing is the part worth noting. Messages arrive mid-turn, injected between tool calls, or they wake an idle agent immediately. That distinction matters because a message that only lands at the end of a turn is useless for steering work in progress. Each agent gets a queryable identity: name, status, inbox, live terminal screen, transcript in structured chunks, and an event log of every file edit and tool call. Agents can subscribe to events and react. Collision detection is on by default, and the README states that if two agents edit the same file within 30 seconds, both get notified. That is a fixed window, not a lock, so it warns rather than prevents. Hooks are written into config directories under ~/ or HCOM_DIR on first run, and the README notes that if you are not using hcom, the hooks do nothing.

Install and first two terminals

The primary install path is Homebrew: brew install aannoo/hcom/hcom. Alternatives include uv tool install hcom or pip install hcom, a shell installer for macOS, Linux, Android via Termux and WSL, and a PowerShell installer for native Windows. An existing install updates with hcom update. The quickstart is two terminals. In the first, run hcom claude, and the README lists codex, opencode, kilo, pi, omp, agy, cursor-agent, kimi, copilot and gemini as the other frontends. In the second, run hcom codex. From there you prompt normally, with examples like asking the other agent their favorite cake, or telling one to review what claude did and send it fixes. Running hcom with no argument opens the TUI dashboard. Two commands cover agents outside the hook system: any other AI tool without hooks can join by running hcom start, and any process can wake agents with hcom send. Terminal control is configurable; the README says to have an agent run hcom config terminal --info for a custom open and close setup, and that kitty, wezterm, tmux, zellij, waveterm, cmux and herdr also support closing panes from hcom kill.

The relay trust model is the real constraint

Cross-device work goes through an MQTT relay. You run hcom relay new to get a token, then hcom relay connect with that token on each device, with hcom relay status, hcom relay off and hcom relay on for control. The security section is unusually candid and is where the design limits show. The relay is one trust domain for one operator's devices, and membership is all-or-nothing: no scoped roles, no read-only peers, no per-device permissions. Payloads use a shared PSK with XChaCha20-Poly1305, bound to the relay, topic and timestamp, with a replay guard that drops duplicate envelopes inside a freshness window. Brokers and network observers cannot read or forge payloads without the PSK, but they can still see topic names, timing, message sizes and connection patterns. The join token contains the relay ID, broker URL and raw PSK. hcom does not ask a server to validate it, and it has no expiry, no scope and no revocation list. On a public broker, a leaked token lets an attacker decrypt captured traffic, publish authenticated relay traffic, send text to listening agents, launch agents on enrolled devices, kill running agents, and use remote relay RPCs. The README is explicit that if those agents can run tools, that amounts to shell access on every enrolled device. There is no forward secrecy, so a leaked PSK decrypts old captured traffic. Sender identity is routing metadata, not authorization. The PSK lives in ~/.hcom/config.toml, written with mode 0600 on Unix, kept out of environment variables, and remote config_get and config_set refuse relay_psk, relay_token, relay_id and the broker URL. Anyone who can read that file, including another user on the same OS account or a backup that did not preserve permissions, has the full PSK. Incident response is hcom relay off --all, which asks every reachable trusted peer to disable the relay. A private or self-hosted broker with --broker and --password adds broker access control, but the README states the token still leaks the PSK and captured traffic is still exposed. If you need per-device revocation, read-only peers, or forward secrecy, hcom is the wrong tool, and no configuration flag fixes that.

Where hcom sits against a workflow orchestrator

The nearest alternative is a workflow orchestrator such as a Python-based graph runner, where you define nodes and edges in code and the framework owns scheduling, retries and state. That model is deterministic and testable: the same graph produces the same execution order. hcom inverts it. The agents themselves decide when to message or spawn a peer, and the coordination emerges from prompts and subscriptions rather than a declared graph. That gives you flexibility for open-ended work like reviewing another agent's edits, and it gives you far less predictability. You cannot replay a run from a definition file. The other difference is surface area: an orchestrator runs in one process and one language, while hcom attaches hooks to the config directories of eleven different CLIs under your home directory. If your work is a fixed pipeline, the orchestrator is the better fit. If your work is a few agents in visible terminals reacting to each other, hcom's model matches the problem more closely.

Maintenance cost and what the MIT licence covers

hcom is a single Rust binary with no background services, which keeps the runtime footprint small, but the maintenance burden sits in the hooks. They are written into agent config directories under ~/ or HCOM_DIR on first run, so every agent CLI you install or upgrade is a potential source of drift between what hcom expects and what the tool now writes. The release cadence is frequent, with v0.7.25, v0.7.24 and v0.7.23 all published within roughly five weeks in mid-2026, and hcom update moves an install to the latest version. That pace suggests the hook layer is still moving. The project is MIT licensed, which permits commercial and private use and modification, and the repository ships a LICENSE file. That is a statement about the licence text, not legal advice; if you redistribute hcom or bundle it into a product, read the MIT terms and your own obligations rather than relying on this summary.

Editorial conclusion

Adopt hcom if you already run several coding CLIs in separate terminals and want them to hand work to each other without copy-paste, and if every device you would enroll is one you would give shell access to. Do not adopt it if you need scoped relay permissions, forward secrecy, or per-device authorization, because the documentation states the relay is one trust domain with an all-or-nothing join token that has no expiry and no revocation list. Before committing, verify the hook paths it writes under ~/ or HCOM_DIR on first run, and test hcom relay status on two devices to confirm the PSK fingerprint matches.

Official sources

Community notes