hcom's relay token has no expiry, no scope and no revocation, and it says so

A Rust binary published on the Python index

The repository's declared homepage is a page on the Python package index, which is the first odd thing you meet. The reason is in the build configuration: the project publishes a Python distribution whose build backend compiles the Rust crate and ships the resulting binary, with the binding type set to binary rather than to an extension module. That distribution declares no dependencies at all, which works because the database layer is compiled into the binary rather than linked against a system library. It is also marked as a beta release in its classifiers, while the Rust crate itself sits on a zero point seven line with three releases in the last two months, one of which arrived five days after the one before it and the previous one had waited nearly seven weeks. The packaging is deliberate and unusual, and the release rhythm behind it is not. The data path is local-first as well: agents do not reach each other over the network, they both talk to a database on your own machine, written by hooks that activate only when an agent is launched with this tool in front, so running your coding assistant the way you always have is unaffected. A tool with no hooks can still join, and any process can wake a listening agent.

Eleven agents, eleven aliases, and no table connecting them

The README names the agents it works with as a flat list of short command words, one for each coding CLI it can front. The build manifests name the same eleven tools by their full product names. Two of the short names are not obviously abbreviations of anything a reader would recognise, and nothing anywhere in the repository maps a short name to the product it launches. So the quickstart works because the word you type is the word the tool dispatches on, but the mapping from that word to a product is undocumented and lives somewhere in the source. The repository carries a second, private package manifest whose entire job is type-checking the plugin code it embeds against three separate third-party plugin interfaces, and two of its dependencies have names that differ from each other by a single character, which is the kind of pair that produces a very quiet mistake.

Two of the four install routes pipe a script into a shell

There are four ways in and two of them hand a downloaded file straight to a shell interpreter. The first is the Python tool installer, which works on all three desktop platforms and is what the documentation presents first. The second is a homebrew tap. The other two are a curl one-liner that pipes a release script into the Unix shell, and the PowerShell equivalent on Windows, plus a command to update an existing installation. Neither of the piped routes is accompanied by a checksum, a signature or a pinned version: they resolve to whatever the latest release asset happens to be at the moment you run them. That is a common pattern and not a reason to avoid the tool, but it sits oddly next to the relay section, which goes out of its way to explain cryptographic binding and replay windows for a feature most users will never enable.

The relay documents its limits before its features

The cross-device relay is a message broker link, and the security section for it is the most careful writing in the repository. The model is stated first and bluntly: one relay is one trust domain for one operator's devices, membership is all or nothing, and there are no scoped roles, no read-only peers and no per-device permissions. Payloads use a shared symmetric key with an authenticated cipher, and each payload is bound to the relay, the topic and a timestamp, with a replay guard that drops duplicate envelopes inside a freshness window. Then the part most projects would omit: brokers and network observers cannot read or forge payloads without the key, but they can still see metadata, specifically topic names, timing, message sizes and connection patterns. That is the honest floor of a shared-key design and it is stated without hedging. The client dependency list backs the claim rather than just making it: the broker library is pulled in with its default features switched off and only TLS enabled, so there is no plaintext or websocket path left enabled by omission.

The join token carries the raw key and has no expiry

The token you hand to each device is not an opaque invite, and the setup is two commands:

hcom relay new               # get token
hcom relay connect <token>   # on each device

The token contains the relay identifier, the broker address and the raw symmetric key, and the tool never asks a server to validate it. It has no expiry, no scope and no revocation list. The file then walks through what that means on a public broker, and the list is the section to read before enabling anything: 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 call remote relay functions. One sentence carries the whole risk, and it is worth quoting in spirit rather than literally: if those agents can run tools, treat a leaked token as shell access on every enrolled device. Adding a broker password narrows this to publishing, but the file is precise that it is broker access control rather than another encryption layer, and that captured traffic is exposed either way.

Four limits stated as design, not as oversights

A limits section lists what the relay will never do. There is no forward secrecy, so a leaked key decrypts traffic you already captured. There is no per-device attribution inside a relay: sender identity is routing metadata rather than authorisation, and every enrolled device speaks with full authority. There is prompt injection from an authenticated peer, because enrollment is total trust and a peer can launch, kill and drive agents rather than merely send text, which is why the file says to enrol only devices you would hand shell access to. One more property belongs in that list: every agent runs in a real terminal that can be seen, scrolled and interrupted, and seven named terminal emulators are called out as able to close a pane from the kill command, so the tool is built around the assumption that a human is watching. And there is no defence against local compromise, because the tool trusts the local user account and its own configuration file. The storage notes follow the same candour: the key lives in a configuration file written with owner-only permissions on Unix, is deliberately kept out of environment variables, and remote configuration calls refuse the four secret fields outright.

Incident response is best effort, and the key cannot be pulled back

The response section is the one to bookmark. Running the off switch for all devices asks every reachable trusted peer to disable the relay and then disables it locally, and the file says in as many words that this is best-effort damage control rather than containment, because the attacker's device ignores the request. Then the harder sentence: the key cannot be revoked. There is no server to notify and no denylist to update, so anyone holding the key can keep using the old relay until you stop using it yourself. The prescribed recovery is rotation, creating a new relay and moving every trusted device to the new token, with the honest footnote that rotation also changes the relay identifier, which orphans whatever state was retained on the old broker topics. A tool that says all of this before you need it is doing you a favour.

Four build systems, and an uninstall that stops mid-command

The root of the repository holds twenty-four entries for what is one Rust binary, and the manifests multiply accordingly: a cargo lock and manifest, a task runner file, a Python project file, a private node manifest with a lockfile and a TypeScript config, a node version file, a Rust toolchain file, an install script, two directories for embedded agent plugins, a skills directory, and manifest files for two different agent plugin marketplaces. The node manifest exists only to type-check the embedded plugins, and it pins a single node minor band and one exact version of a major compiler. At the other end, the uninstall section is the only part of the documentation that visibly breaks off: its third option is cut inside a shell substitution, so the manual removal path for anyone who did not install through a package manager is never actually printed.

Editorial conclusion

The relay documentation is the reason to trust the rest of it. A tool that tells you a leaked key means shell access on every machine you enrolled, that membership is all or nothing, that there is no forward secrecy, that peer identity is routing metadata rather than authorisation, and that revocation does not exist is a tool that has thought about its failure modes. Use hcom locally, where its local database and terminal visibility are the whole point and the trust boundary is one user account, and treat the cross-device relay as a different product with a different risk. Before enabling it, read the limits section rather than the feature list, and if you do enable it, self-host the broker, treat the join token as a credential with a permanent life, and decide in advance what you will do the day it leaks, because the documented answer is rotate to a new relay rather than revoke the old one.

Frequently asked questions

Official sources

1. aannoo/hcom on GitHub
2. License: MIT
3. Project website
4. README
5. Releases