The client · open source

A daemon keeps the record.A page shows its work.

hx is the open-source client that keeps the second codebase: a small daemon that watches the session folders agent tools already write, and mirrors every session to the store its organization runs. HX Client is the daemon's local interface, where every folder, destination, and byte it sends is visible and reversible on the device it runs on.

Every screen, annotated →github.com/hx-framework/hx

HX Client overview screen: folders watched, sessions on disk, destinations, and the list of connected HX Fortresses — The overview: what's picked up, where every session is stored, and who can see it — with a banner the moment a folder's routing needs a human decision.

What runs where

A daemon, an interface,
a destination

The client is deliberately small. It adds no step to anyone's day: agent tools keep writing their sessions exactly as they do today, and hx takes custody from there.

hx — the daemon

One small binary. It watches the folders where agent tools already keep their sessions — Claude Code, Codex, whichever comes next — and mirrors each session to its destination. Nothing changes in the editor, the agent, or the workflow.

HX Client — the interface

The daemon's own page, served from the device at a local address. It shows every watched folder, every destination, every byte queued or sent — and every control to pause, scope, or reverse the flow.

HX Fortress — the destination

Session storage a company runs on its own servers. A personal space holds the sessions that belong to no company, readable by its author alone. The client verifies both continuously, byte for byte — and the fortress has its own console, and its own page.

Diligence

What a security review finds

Agentic sessions are sensitive by nature: they quote the codebase, the plans, and the people. The client is built with that in mind, and built to be examined — by the engineer who runs it, and by the security teams whose job is to ask.

1Privacy & control. Syncing pauses with one control — for fifteen minutes, until tomorrow, or until the author resumes it. Any folder can be excluded, including folders that don't exist yet, and exclusion outranks every other setting. Personal sessions can stay on the machine entirely. Every switch sits on the device, and every switch is reversible.

2Data governance. Every folder maps to exactly one destination, and the interface shows the whole reason: repository → project → company → fortress. Company sessions rest on servers the company runs. A repository no project has claimed is treated as personal and raised as a banner, so an administrator can attach it — routing is always a visible state.

3Security. The interface is served from the device, and the page itself sends nothing anywhere. Devices sign in explicitly and disconnect in one action. Storage is verified continuously: upload offsets are checked against what the fortress actually holds, and a periodic test write is read back to prove the store works, so integrity is checked continuously instead of assumed.

4Data protection & PII. Transcripts are scanned before anything leaves the machine. Personally identifying details are scrubbed from sessions before they are sent, and sessions that look like they contain secrets or credentials are held back entirely, flagged for the author's review. The inspector shows the exact text queued to leave — before it leaves.

5Retention & jurisdiction. Deletion is a control on screen: synced personal sessions can be deleted from the interface, and company fortresses follow each company's retention policy. A self-hosted fortress keeps session content inside the organization's own infrastructure and jurisdiction — data residency follows from the architecture.

The organizational side of the same questions — lawful basis, works councils, retention policy — is covered by the policy kit and its GDPR annex.

Before it sends

What leaves the machine

The first question every engineer asks has a literal answer: a preview of the transcript text queued for upload, session by session, before it goes.

The What Leaves This Machine inspector: a list of queued sessions on the left, the exact transcript text to be uploaded on the right — The inspector, opened from Privacy Controls or straight from the overview's session count.

The line under every preview states the contract: the transcript shown is exactly what uploads — nothing else is read or sent. Where content is withheld, the record keeps the conversation's shape, using the same redaction markers PSF defines for the portable record.

Trust, implemented

The four safeguards, drawn per folder

Trust names four conditions before a session reaches anyone but its author. The interface draws them — for every folder, as the reason it syncs where it does.

An expanded folder row showing the routing chain from git repository to project to company to fortress, and the named teammates who can see the sessions — A folder row, opened. The chain is the routing; the people row is the audience.

The chain is the first three conditions in order: a work repository, attached to a project, in a company, backed by that company's fortress. The people row is the fourth — a named team, the author's own opt-in, and the two teammates who haven't opted in and therefore see nothing.

The safeguards, in full →See the other screens

Open source · MIT

Yours to run, read, and audit

The client is one binary, MIT-licensed, stewarded by let.ai research the way the framework itself is. Every claim on this page is checkable in the source — and everything the interface shows is also a command, reading the same local state.

hx uiopens the interface — the same facts as the commands, drawn friendlier
hx statusaccount, daemon, connection quality, sync progress
hx doctor syncanything blocked, since when, and the fix — with --json for automation
hx logsthe daemon's own words, tailed live

Read the source →The interface, screen by screen

A daemon, an interface,a destination