# HarnessLink > HarnessLink is the controller for AI coding agents such as Claude Code, Codex, omp and pi: one gateway for every model call, shared memory they all search, and sync and restore of your setup across machines. Every public page of harnesslink.sh that llms.txt lists, as Markdown. https://harnesslink.sh/llms.txt is the index. --- Source: https://harnesslink.sh/ # The controller for your coding agents. HarnessLink links omp, Claude Code, Codex, pi, Antigravity, Cursor, and others: one gateway for every model call, one memory they all search, and your setup on any machine. `curl -fsSL https://harnesslink.sh/install.sh | bash` macOS and Linux. Needs curl and bash. Architecture in depth ## Bring your harness. Plug it into HarnessLink. Every capability is an independent tier. As you connect your coding agents, HarnessLink routes their models, shares their memory, and lets them collaborate. Tier 01 Plug in your harness ### Bring any harness you code in. Zero patching. Works through each harness’s standard hooks, MCP servers and model settings. omp, Claude Code, Codex, Antigravity, Cursor, pi, or others - connect in seconds without altering your logins or shell config. Plug-and-play roster: omp Claude Code Codex Antigravity Cursor pi others Run on your machine: `$ hnl install` **7 ready** Detected harnesses **0 required** Binary patches **Untouched** Shell config Tier 02 Unified model gateway ### One local endpoint for every model call. Route all model requests through HarnessLink’s local proxy. Cache prompt prefixes with 99.95% hit rate, enforce budget limits, and switch providers without touching harness code. Run on your machine: `$ hnl gateway status` **99.95% hit** Context cache **127.0.0.1:4000** Local proxy **Hard-capped** Spend limits Tier 03 Continuous shared memory ### What one harness learns, the others know. Every finished turn is automatically banked as Markdown and indexed with SQLite full-text search on your local disk. Any harness recalls past decisions, code patterns and project history in 2 tool calls. Run on your machine: `$ hnl memory search "auth refactor"` **Markdown + FTS5** Storage format **2 tool calls** Recall time **Zero (local first)** Cloud dependency Tier 04 Cross-harness delegation ### Harnesses hand off work to each other. Pass tasks between harnesses seamlessly. Have omp orchestrate architectural refactoring while delegating sub-searches to Antigravity or Codex, tracking full turn runs and artifacts on a single board. Run on your machine: `$ hnl run "verify test suite"` **Subagent swimlanes** Agent handoffs **69k tokens, not 4.3M** Session resume **Unified telemetry** Runs board STAGE TELEMETRY • TIER 01 ACTIVE 60 FPS Harness Bus Topology Bus state Active • 7 nodes bridged Protocol Stdio MCP • Non-invasive hooks Binary patching 0 bytes modified ## Measured on our own machines - **99.95%**of model context served from cache - **2 tool calls** to recall any project’s memory - **69k, not 4.3M** tokens to resume a 17 MB session ## Install once. Keep everything after that Free for one person. Teams add shared policies, run traces and audit; see [pricing](https://harnesslink.sh/pricing). `curl -fsSL https://harnesslink.sh/install.sh | bash` [Sign in](https://harnesslink.sh/login) [Read the docs](https://harnesslink.sh/docs) [Supported harnesses](https://harnesslink.sh/harnesses) --- Source: https://harnesslink.sh/pricing # Plans and pricing HarnessLink is the controller for your coding agents - it routes their model calls, gives them shared memory, banks what they do, and syncs and restores your setup. You code in omp, Claude Code, Codex, pi, and others. Every plan includes the whole controller - gateway, memory tools, context hooks, autobank, sync and restore - and the HarnessLink dashboard; plans differ in how much the cloud keeps and how many AI asks you get. Prices are in GBP and exclude VAT where applicable; paid plans are charged by card at checkout and cancellable from the billing portal. ### Free £0 for ever Everything you need to start syncing your harnesses' memory, sessions and setup across machines. [Get started](https://harnesslink.sh/login) - 25,000 history rows - 250 MiB session storage - 16 MiB memory - 2 devices - 30-day retention - Keyword search (no AI asks) ### Pro Popular £10/ month More headroom and semantic search for individuals who rely on HarnessLink daily. [Get started](https://harnesslink.sh/login) - 500,000 history rows - 10 GiB session storage - 256 MiB memory - 10 devices - Unlimited retention - 200 AI asks / month - Semantic search ### Team £22/ user / month Shared organisation, generous storage, and collaborative sync for growing teams. [Get started](https://harnesslink.sh/login) - 2,000,000 history rows - 50 GiB session storage - 1 GiB memory - One team · 50 devices - Unlimited retention - 1,000 AI asks / month (pooled) - Semantic search - Shared organisation - Team invites and seats ### Enterprise Contact us No limits, a self-hosting option, and a dedicated support arrangement. [Get in touch](https://harnesslink.sh/contact) - Unlimited history rows - Unlimited session storage - Unlimited memory - Multiple teams · configurable device limits per team - Unlimited retention - Unlimited AI asks - Semantic search - Shared organisation - Per-team and per-user policies - Self-hosting ## Frequently asked questions ### How do I change my plan? Pick the plan in the dashboard and pay by card at checkout; the tier applies as soon as the payment confirms. Changing card details, switching tier or cancelling later all happen in the same billing portal, reachable from [your plan page](https://harnesslink.sh/plans). ### What counts towards my storage quota? History rows are the prompts captured from your harnesses. Session storage covers their JSONL transcripts. Memory storage is the semantic memory plane. Devices are machines linked to your account. ### Is there a free trial on paid plans? The free plan is the trial: it does not expire, and it carries the whole product minus the headroom. Move up when you hit a limit, and cancel from the billing portal whenever you like. Already have an account? [View your current plan](https://harnesslink.sh/plans) in the dashboard · [Templates](https://harnesslink.sh/templates) · [Integrations](https://harnesslink.sh/integrations) · [Docs](https://harnesslink.sh/docs) --- Source: https://harnesslink.sh/docs # Installing HarnessLink HarnessLink is the controller for your coding agents - it routes their model calls, gives them shared memory, banks what they do, and syncs and restores your setup. You code in omp, Claude Code, Codex, pi, and others. This page takes a fresh machine through to a working setup. ## Find the page for your task | Task | Where | | --- | --- | | Install (macOS / Linux) | [Install section below](https://harnesslink.sh/docs#install) | | Install (Windows) | [Windows section below](https://harnesslink.sh/docs#windows) | | Connect to the cloud (first-time login) | [Connect the cloud below](https://harnesslink.sh/docs#connect-the-cloud) | | What HarnessLink syncs | [What syncs below](https://harnesslink.sh/docs#what-syncs) | | Set up one harness (Claude Code, Codex, omp, pi, Antigravity, Cursor) | [Harness pages](https://harnesslink.sh/harnesses) | | Every command | [Commands below](https://harnesslink.sh/docs#commands) | | Invite team members | [Team page](https://harnesslink.sh/team) (sign-in required) | | Share an artefact with your team | [Agents page](https://harnesslink.sh/agents) (sign-in required) | | Pull shared artefacts from your org | [Agents page](https://harnesslink.sh/agents) (sign-in required) | | Policies and scoped instructions | [Policies page](https://harnesslink.sh/policies) (sign-in required) | | Digest emails | [Settings page](https://harnesslink.sh/settings) (sign-in required) | | Plans and AI asks | [Plans and pricing](https://harnesslink.sh/pricing) | | Self-hosting | [Contact us](https://harnesslink.sh/contact) | | Templates and skills | [Templates](https://harnesslink.sh/templates) | | MCP server integrations | [Integrations](https://harnesslink.sh/integrations) | ## What you need | Requirement | Why | Auto-installed? | | --- | --- | --- | | **macOS, Linux or Windows** | Windows uses [install.ps1](https://harnesslink.sh/docs#windows) | - | | **Bun ≥ 1.3.14** | HarnessLink runs on Bun, not Node | yes (bun.sh) | | A harness to code in | omp, Claude Code, Codex or pi - HarnessLink wires itself into each one it finds | omp yes (unless you skip it); others with `--with` | ### Your harnesses keep their own logins HarnessLink needs no model credential of its own: model calls are made by your harness, through the local gateway, with the harness's own sign-in. ## Install ``` curl -fsSL https://harnesslink.sh/install.sh | bash ``` No GitHub account or token is needed: the installer fetches the source tarball from this site. It installs **omp** (upstream oh-my-pi, a harness you code in) alongside **hnl** (the controller) unless told not to, and is **re-runnable** - every step checks before acting, so running it again updates rather than reinstalls. ### Options ``` bash install.sh --help --dir Where to put the source checkout (default: ~/.superpi-src) --no-omp Skip installing omp (upstream oh-my-pi) --with= Also install the listed harnesses after omp (comma-separated) Valid ids: omp claude-code codex gemini pi dsh Example: --with=claude-code,codex --cloud Run HarnessLink setup even with --yes (needs a terminal to sign in) --yes Assume yes for anything that modifies the system --help This text ``` Pass options through the one-liner with `bash -s --`: `curl -fsSL https://harnesslink.sh/install.sh | bash -s -- --with=claude-code,codex`. ## Windows Open PowerShell and run: ``` irm https://harnesslink.sh/install.ps1 | iex ``` The installer downloads the source tarball from this site and extracts it with the `tar.exe` that ships with Windows 10+ - no git or GitHub involved. **Bun is installed automatically** via `bun.sh/install.ps1` if it is not already present. **Parameters.** `irm … | iex` cannot pass parameters; download the script and run it as a file instead: ``` irm https://harnesslink.sh/install.ps1 -OutFile install.ps1 powershell -NoProfile -ExecutionPolicy Bypass -File .\install.ps1 -Yes ``` `-DryRun` prints what it would do and changes nothing. `-NoOmp` skips omp. `-Yes` skips the onboarding and prints `hnl cloud setup` for you to run later. There is no `--with` or `--cloud` equivalent on Windows. | Requirement | Why | Auto-installed? | | --- | --- | --- | | **Windows 10+** | tar.exe and PowerShell 5.1 built in | - | | **Bun ≥ 1.3.14** | HarnessLink runs on Bun, not Node | yes (bun.sh/install.ps1) | ### Troubleshooting: Windows **Blocked by execution policy** Bypass for the current shell only (no system-wide change): ``` Set-ExecutionPolicy -Scope Process Bypass irm https://harnesslink.sh/install.ps1 | iex ``` **`hnl.cmd` not recognised after install** Bun's bin directory is not on `PATH`. For the current session: ``` $env:PATH = "$env:USERPROFILE\.bun\bin;$env:PATH" ``` Add it permanently in **System Settings → Environment Variables**. ## Verify ``` hnl --version hnl --smoke-test ``` The installer runs both. A version number alone does not prove a working install; the smoke test loads every command module and exercises the gateway and the MCP relay end to end. After that, plain `hnl` shows the home screen: whether the HarnessLink service is running, whether you are signed in and syncing, and what each harness is wired to. ## Connect the cloud: guided setup On an interactive terminal the installer opens HarnessLink setup straight away: one plan screen, sign in once in your browser, and everything else turns on by itself - cloud sync, the HarnessLink service and every harness on the machine. Nothing syncs until you sign in. Run it again any time with `hnl cloud setup`; plain `hnl` runs it for you if setup has never finished. These are the steps the dashboard's [Setup page](https://harnesslink.sh/setup) ticks off live from your real sync state. 1. ### 1. Install and sign in The installer puts HarnessLink and omp on the machine, then opens hnl cloud setup. Sign in once and it turns on cloud sync, the HarnessLink service and, for each harness it finds, gateway routing, transcript sync, autobank, context hooks and memory tools. ``` curl -fsSL https://harnesslink.sh/install.sh | bash ``` 2. ### 2. Cloud sync on Signing in turns sync on. Plain hnl shows sync health on its home screen; this shows what has uploaded and what is waiting. ``` hnl cloud status ``` 3. ### 3. First sync completed Prompt something in any connected harness (omp, Claude Code, Codex, pi, Antigravity). It shows here after the next sync; this command syncs now. ``` hnl cloud sync ``` 4. ### 4. Profile pushed The HarnessLink service uploads this machine's profile by itself and again whenever it changes: HarnessLink's config and MCP server names, plus each harness's agents, commands, rules and skills. Never secret values. Push to refresh it now. ``` hnl cloud push-profile ``` 5. ### 5. Code intelligence wired Optional Install gortex to unlock semantic code search across your repositories. ``` curl -fsSL https://get.gortex.dev | sh ``` 6. ### 6. HarnessLink skills folder in the profile Optional Skills and agents in HarnessLink's own folder (~/.superpi/agent: installed by hnl add, or left by the old built-in agent) travel inside the profile, so a new machine can restore them. Ticks once a profile carries at least one. The dry run lists every file the profile would carry. ``` hnl cloud push-profile --dry-run ``` 7. ### 7. Memories in the cloud Optional Setup turns this on: each harness's own memory files and its memory bank upload by themselves, and older MemPalace and ~/.hermes memories are imported once. Run the import again any time. ``` hnl cloud import-memories --apply ``` 8. ### 8. Adopt on another machine Optional On a fresh machine, restore this device's config, skills, tools and harness files. config.yml is backed up before it is replaced, harness files are only created (never overwritten), and MCP servers arrive disabled until you approve them. ``` hnl cloud restore --device --apply --install-tools ``` ## What setup connects A **harness** is the program that runs a model with tools - omp, Claude Code, Codex, pi. You code in it; HarnessLink is not one. For each harness it finds, setup turns on the features that harness supports. Every feature is a command of its own, so you can redo or undo it later. Each harness has [its own page](https://harnesslink.sh/harnesses) with what it gets and the commands for it. | Feature | What it does | Harnesses | Command | | --- | --- | --- | --- | | **Gateway routing** | Model calls go through a local gateway on `127.0.0.1:4747`: cached on exact repeats, usage recorded. Your harness keeps its own login. | Claude Code, Codex, omp, pi | `hnl gateway connect [id]` | | **Transcript sync** | Session transcripts, prompt history and the harness's own memory files (`CLAUDE.md`, `AGENTS.md`, `memories/` …) upload to your account. | Claude Code, Codex, omp, pi, Antigravity, Cursor (`~/.cursor/sessions` and `~/.cursorrules` only) | `hnl cloud harnesses enable ` | | **Autobank** | Every finished turn becomes a Markdown memory bank entry, starting with the last 30 days; todo and plan snapshots too. Runs in the HarnessLink service. | omp, pi, Claude Code, Codex, Antigravity (one entry per conversation). Not Cursor. | `hnl cloud autobank enable ` | | **Context hooks** | A project brief at session start and matching memories on each prompt, read from local files. | Claude Code, Codex, omp | `hnl harness context [id]` | | **Memory tools (MCP)** | The model can search, read and record HarnessLink memory itself. | omp, Claude Code, Codex | `hnl mcp register --harness= --yes` | All of this runs in the **HarnessLink service**, a background process that setup installs as a LaunchAgent (macOS), a `systemd --user` unit (Linux) or a logon task (Windows). It hosts the gateway, the MCP hub (one per machine: each MCP server you configure in HarnessLink starts once and is shared by up to 64 sessions), a watchdog that caps the service's child processes and memory, and cloud sync. Check it with `hnl gateway status`, or just run `hnl`. When the service is down, harnesses routed through the gateway get "connection refused". Policies you set on the dashboard are enforced before a tool runs in Claude Code, Codex and omp: tool and command rules, with their folder and model conditions. "Ask first" rules ask in Claude Code and omp and block in Codex, and standing instructions are added at the start of each session in all three. pi, Cursor and Antigravity are not enforced yet. Changes reach your machines within about a minute. ## What HarnessLink syncs Sync is on whenever you are signed in. It has six categories, all on by default. Turn one off with `hnl cloud sync --disable ` and back on with `--enable`; `hnl cloud status` shows each one. - **Prompt history** (`history`) - the prompts you type in every harness with capture on (Claude Code, Codex, omp, pi, Antigravity), each tagged with its harness. Not responses. - **Session transcripts** (`sessions`) - full transcripts from every harness with capture on, except Antigravity. - **Memories** (`memories`) - HarnessLink's memory tree under `~/.superpi/agent/memories` (bank entries from every harness with autobank on, `MAIN.md`, daily summaries, `state/` snapshots) and each captured harness's own memory files. - **Old agent usage** (`usage`) - tokens and cost recorded by HarnessLink's old built-in agent. Nothing new is recorded; existing records still upload. - **Gateway usage** (`gatewayUsage`) - tokens and cost of every model call through the gateway. - **Device profile** (`profile`) - this machine's HarnessLink config and MCP server entries (secret values reduced to their names), plus the setup of each installed harness: Claude Code, Codex, omp and pi agents, commands, rules, prompts, skills and `CLAUDE.md` / `AGENTS.md` (Markdown only; their config files by key name only). Everything is redacted on your machine before upload. On a new machine, `hnl cloud restore --apply` writes the profile back; every restored MCP server stays disabled until you approve it. Data from HarnessLink's old built-in agent (its history, sessions and memories) is still read for restore, resume and upload. Nothing new of that kind is produced. Data is partitioned per organisation and user - other members can never read your history or memory. See [Plans and pricing](https://harnesslink.sh/pricing) for storage limits per tier. Organisations on the Team or Enterprise plan can also share selected artefacts with the whole org via the [Agents page](https://harnesslink.sh/agents). ## Commands Every command takes `--help`. The commands below are the whole of `hnl`; coding happens in your harness. | Command | What it does | | --- | --- | | `hnl` | No arguments. Runs setup when this machine is not signed in. After that, a home screen: service state and version, sign-in, sync health, autobank per harness, what each harness is wired to (gateway, transcripts, autobank, context, memory tools) and the one next action. Without a terminal it prints the same as plain text. | | `hnl cleanup` | Remove the git worktrees the old built-in agent left in ~/.superpi/wt. Shows the size and asks first; worktrees with uncommitted changes are listed and never deleted without saying so. | | `hnl cloud ` | Sign-in, sync and memory: setup, status, sync, recall, brief, push-profile, restore, pull-sessions, pull-memories, pull-history and more (hnl cloud --help lists all). | | `hnl completions` | Print a shell completion script (bash, zsh or fish). | | `hnl config` | Shortcut for cloud status: review authentication, sync health, active profile, and connected harnesses. | | `hnl context-hook` | The entry point harness hooks call: a project brief at session start and matching memories per prompt. You do not run it by hand. | | `hnl daemon` | Run or manage the HarnessLink service (gateway, MCP hub, watchdog, cloud sync, harness capture). | | `hnl gateway` | The local model gateway: status, connect and disconnect harnesses, and the background service. | | `hnl harness` | List, install and wire harnesses: capture, memory tools, context hooks. | | `hnl install` | Shortcut for harness install: guided setup to install and configure coding harnesses (omp, Claude Code, Codex, pi). | | `hnl kb (alias hnl knowledge)` | The Cloudflare knowledge base: ingest, search, status. | | `hnl mcp` | Connect a harness to the HarnessLink MCP hub, print its client config, or register it in harness configs. | | `hnl registry (alias hnl add)` | Install a registry item. Skills go into each harness's own skills folder (Claude Code, Codex, omp, pi, Antigravity, Cursor) for every harness on this machine; agents and extensions are omp only. hnl add --list shows what is installed; hnl remove removes only what HarnessLink installed. | | `hnl resume` | Pick a session from any harness on this machine and resume it natively, or seed a fresh one from memory. | | `hnl sessions` | List or search sessions from every harness on this machine (read-only). | | `hnl setup` | Shortcut for cloud setup: interactive terminal wizard to authenticate and connect your machine. | | `hnl status` | Shortcut for gateway status: inspect the local model gateway, port bindings, and background daemon status. | | `hnl telegram link\|status\|unlink` | Link a Telegram chat to your cloud account, so you can ask about your memory and sessions from it. | | `hnl update` | Update HarnessLink and each installed harness through its own updater. | | Root flag | What it does | | --- | --- | | `hnl --help` | List the commands. | | `hnl --version` | Print the HarnessLink version. | | `hnl --smoke-test` | Load every command module and exercise the gateway and the MCP relay end to end. | | `hnl --profile ` | Run against a named profile instead of the default. | ### Removed commands These belonged to HarnessLink's old built-in agent. Each now prints one line - use omp (or your harness) for that - and exits with status 2. So does any other first argument that starts with `-`, such as `-p` or `--model`. `launch`, `acp`, `auth-broker`, `auth-gateway`, `agents`, `bench`, `browser-relay`, `cleanse`, `commit`, `compress`, `dry-balance`, `eval`, `factory`, `gallery`, `gc`, `grep`, `grievances`, `integrate`, `join`, `marketplace`, `models`, `plugin`, `provider`, `q`, `read`, `say`, `search`, `share`, `shell`, `ssh`, `stats`, `ste`, `tiny-models`, `token`, `ttsr`, `usage`, `worktree`, `wt`. ## Updating ``` hnl update ``` Opens a picker over every harness on the machine - omp first, hnl itself, then Claude Code, Codex and others that are installed - and runs each one's own updater. hnl updates itself by re-running the installer from this site. Without a terminal (scripts, CI) it updates hnl directly. If an older HarnessLink ran its built-in agent on this machine, its git worktrees may still sit in `~/.superpi/wt`. `hnl cleanup` removes them with your consent - the update and the home screen offer it too. ## Uninstalling Undo the wiring first: deleting `hnl` while harnesses still point at its gateway leaves them failing with "connection refused". ``` hnl gateway disconnect # put back each harness's own provider settings hnl harness context --remove # remove HarnessLink's context hooks hnl gateway service uninstall # stop and remove the background service ``` Remove HarnessLink's MCP entry from each harness: `claude mcp remove --scope user hnl`; the `[mcp_servers.hnl]` block in `~/.codex/config.toml`; `mcpServers.hnl` in `~/.omp/agent/mcp.json` and `~/.cursor/mcp.json`. Then delete HarnessLink: ``` rm -f ~/.bun/bin/hnl ~/.bun/bin/superpi ~/.bun/bin/harnesslink rm -rf ~/.superpi-src rm -rf ~/.superpi # ⚠ also deletes local history, memory and sessions ``` omp, pi, Claude Code, Codex and other harnesses stay installed - they are separate programs. `~/.bun/bin/pi` is the pi harness, not part of HarnessLink. ## Troubleshooting **`hnl: command not found`** `~/.bun/bin` is not on your `PATH`. Add it and open a new shell: ``` export PATH="$HOME/.bun/bin:$PATH" ``` **A harness fails with "connection refused"** It is routed through the gateway and the HarnessLink service is not running. Check, then restart it: ``` hnl gateway status hnl gateway service restart ``` **hnl shows you signed out, or another machine's setup** Check which config directory is in use. `HARNESSLINK_CONFIG_DIR` (or legacy `SUPERPI_CONFIG_DIR`) accepts either a relative name (resolved under `$HOME`) or an absolute path (used as the full config root). Setting it to a relative name such as `cfg` resolves to `$HOME/cfg`; setting it to an absolute path such as `HARNESSLINK_CONFIG_DIR=/tmp/cfg` uses `/tmp/cfg` directly. To switch profiles, use an absolute path or set `HOME`. ``` echo "${HARNESSLINK_CONFIG_DIR:-$SUPERPI_CONFIG_DIR}" # empty means the default ~/.superpi ``` ## Guides Everything above in depth, and the rest of HarnessLink, one guide per subject: - [Using HarnessLink](https://harnesslink.sh/docs/usage): Using HarnessLink day to day: Ask, history, policies, shared memory, resuming sessions across harnesses, profile sync, templates, delegation, runs and cost. - [Installing HarnessLink](https://harnesslink.sh/docs/install): The full HarnessLink install guide: requirements, Windows, install options, verifying, the first-run onboarding, updating, troubleshooting and uninstalling. - [Memory Banking](https://harnesslink.sh/docs/memory-banking): How HarnessLink turns each finished turn in omp, Claude Code, Codex, pi and Antigravity into a Markdown memory entry, when banking runs, and what reads it. - [What HarnessLink captures from each harness](https://harnesslink.sh/docs/multi-harness): What HarnessLink captures from omp, Claude Code, Codex, pi, Antigravity and Cursor after setup, and how it stays a controller rather than a harness. --- Source: https://harnesslink.sh/harnesses # Harnesses HarnessLink works with A harness is the coding agent you work in: it runs a model with tools. HarnessLink is not one. It reads the files each harness already writes and, when you run setup, adds its own entries to that harness's config: gateway, context hooks, MCP server. What that gives you depends on the harness. ## One memory for every harness Every harness HarnessLink banks writes to the same memory: omp, Claude Code, Codex and pi bank each finished turn, Antigravity one entry per conversation. Claude Code, Codex and omp read it back: a brief of the project when a session starts, related entries on each prompt, and the MCP memory tools when the model wants more. Cursor gets the memory tools too, registered by hand. So a decision made in Claude Code can come up in Codex, and when you are signed in, `memory_search` adds what your other machines banked. ## What each harness gets | Feature | [Claude Code](https://harnesslink.sh/harnesses/claude-code) | [Codex](https://harnesslink.sh/harnesses/codex) | [omp](https://harnesslink.sh/harnesses/omp) | [pi](https://harnesslink.sh/harnesses/pi) | [Antigravity](https://harnesslink.sh/harnesses/antigravity) | [Cursor](https://harnesslink.sh/harnesses/cursor) | | --- | --- | --- | --- | --- | --- | --- | | Prompt history | Yes | Yes | Yes | Yes | Yes | No | | Session transcripts | Yes | Yes | Yes | Yes | Yes | Partly | | Memory bank (autobank) | Yes | Yes | Yes | Yes | Partly | No | | Gateway routing | Yes | Yes | Yes | Yes | No | No | | Context hooks | Yes | Yes | Yes | No | No | No | | Memory tools (MCP) | Yes | Yes | Yes | No | No | Partly | | Org policy rules | Yes | Partly | Yes | No | No | No | | Skills from templates | Yes | Yes | Yes | Yes | Yes | Yes | | Resume in another harness | Yes | Yes | Yes | Yes | No | No | ### [Claude Code](https://harnesslink.sh/harnesses/claude-code) Claude Code gets everything HarnessLink does: its transcripts and prompts are captured, every finished turn becomes a memory entry, a project brief and related memories arrive through Claude Code's own hooks, and the model can search the same memory your other harnesses write. ### [Codex](https://harnesslink.sh/harnesses/codex) Codex gets the full set: its transcripts and prompt history are captured, every finished turn is banked, context hooks bring a project brief and related memories into each session, and the MCP memory tools search what Claude Code, omp and pi banked too. ### [omp](https://harnesslink.sh/harnesses/omp) omp is the harness the installer adds by default. HarnessLink captures its prompts, transcripts, todos and plans, banks every finished turn, brings memory into each session through a managed omp extension and gives the model the MCP memory tools. ### [pi](https://harnesslink.sh/harnesses/pi) HarnessLink captures pi's prompts and transcripts, banks every finished turn into the memory your other harnesses search, and routes pi's Anthropic and OpenAI Codex calls through the local gateway. pi has no hooks HarnessLink can use, so memory does not flow back into a pi session. ### [Antigravity](https://harnesslink.sh/harnesses/antigravity) HarnessLink reads what the Antigravity CLI (`agy`) writes: your prompts, each conversation's transcript and its summary, banked as one memory entry per conversation. Antigravity's model traffic goes straight to Google and it has no hooks or MCP preset, so HarnessLink does not route or add to its sessions. ### [Cursor](https://harnesslink.sh/harnesses/cursor) Cursor support is partial. You can register HarnessLink's MCP server in Cursor by hand, so its model can search and read the memory your other harnesses bank, and HarnessLink syncs `~/.cursor/sessions/*.jsonl` and `~/.cursorrules`. Cursor's chats live in an editor database HarnessLink does not read, so they are not captured or banked. ## Guides - [Using HarnessLink](https://harnesslink.sh/docs/usage): Using HarnessLink day to day: Ask, history, policies, shared memory, resuming sessions across harnesses, profile sync, templates, delegation, runs and cost. - [Installing HarnessLink](https://harnesslink.sh/docs/install): The full HarnessLink install guide: requirements, Windows, install options, verifying, the first-run onboarding, updating, troubleshooting and uninstalling. - [Memory Banking](https://harnesslink.sh/docs/memory-banking): How HarnessLink turns each finished turn in omp, Claude Code, Codex, pi and Antigravity into a Markdown memory entry, when banking runs, and what reads it. - [What HarnessLink captures from each harness](https://harnesslink.sh/docs/multi-harness): What HarnessLink captures from omp, Claude Code, Codex, pi, Antigravity and Cursor after setup, and how it stays a controller rather than a harness. ## Read next - [Claude Code](https://harnesslink.sh/harnesses/claude-code): Hooks, MCP memory tools, gateway and autobank - [Codex](https://harnesslink.sh/harnesses/codex): Hooks, MCP memory tools, gateway and autobank - [omp](https://harnesslink.sh/harnesses/omp): Context extension, MCP memory tools, gateway and autobank - [pi](https://harnesslink.sh/harnesses/pi): Transcripts, autobank and gateway - [Antigravity](https://harnesslink.sh/harnesses/antigravity): Transcripts and one memory entry per conversation - [Cursor](https://harnesslink.sh/harnesses/cursor): MCP memory tools, by hand; chats not captured [Install guide](https://harnesslink.sh/docs) · [Pricing](https://harnesslink.sh/pricing) · [Integrations](https://harnesslink.sh/integrations) --- Source: https://harnesslink.sh/templates # Templates and skills Ready-made templates, skills and extensions. hnl add installs skills into each harness's own skills folder (Claude Code, Codex, omp, pi, Antigravity, Cursor) for every harness on this machine; agents and extensions are omp only. Or paste the one-prompt block into any harness session that has web access. ## Templates ### code-reviewer template 2 files Code reviewer agent persona with severity-tagged checklist passes for correctness, security, tests, and naming. `hnl add code-reviewer` ### team-onboarding template 2 files Team onboarding template: HarnessLink install check, cloud sign-in, shared org skills and agents, and restoring a teammate's setup. `hnl add team-onboarding` ### weekly-digest template 1 file Weekly digest template explaining how to enable the dashboard digest and what each section contains. `hnl add weekly-digest` ## Skills ### code-review-checklist skill 1 file Severity-tagged code review passes covering correctness, security, tests, and naming conventions. `hnl add code-review-checklist` ### conventional-commits skill 1 file Commit message discipline playbook enforcing Conventional Commits format with scope and body guidance. `hnl add conventional-commits` ### incident-notes skill 1 file Structured incident and postmortem capture procedure with timeline, impact, and action items. `hnl add incident-notes` ### intent-discovery skill 1 file AI-native SDLC step 1: interview the originator until understanding is complete, then capture a human-readable, machine-actionable intent/-.intent.md. `hnl add intent-discovery` ### maintenance-intent skill 1 file AI-native SDLC maintenance loop: turn an alert, log excerpt, ticket or channel message into a diagnosed intent/-.intent.md — before a human reaches the keyboard. `hnl add maintenance-intent` ### plan-from-spec skill 1 file AI-native SDLC step 3: turn an approved spec into a standalone plan/.plan.md — files to change, ordered work, risks, and proof — implementable without the earlier artifacts. `hnl add plan-from-spec` ### spec-from-intent skill 1 file AI-native SDLC step 2: turn a committed intent.md into a requirements and design spec/.spec.md, honouring org instructions and style guides. `hnl add spec-from-intent` ### superpi skill 1 file Cross-harness playbook for HarnessLink (the `superpi` CLI), the controller beside your coding agent: cloud recall and brief, session search and resume, and on-demand sync. `hnl add superpi` ## Extensions ### context-compress extension omp 1 file Deterministically compresses large tool outputs before they enter context, with a retrieve_output tool to recover originals — headroom-style, reversible, local-first. `hnl add context-compress` [Docs](https://harnesslink.sh/docs) · [Integrations](https://harnesslink.sh/integrations) · [Pricing](https://harnesslink.sh/pricing) --- Source: https://harnesslink.sh/integrations # Integrations HarnessLink is the controller for your coding agents - it routes their model calls, gives them shared memory, banks what they do, and syncs and restores your setup. You code in omp, Claude Code, Codex, pi, and others. These are community MCP servers it can serve to every harness. Add a snippet to `~/.superpi/agent/mcp.json` and the HarnessLink MCP hub serves it to every harness that runs `hnl mcp`; your harnesses get the tools on their next session. There is no server-side OAuth through harnesslink.sh; each server talks directly to the third-party API with your own credentials. ### GitHub Read and write issues, pull requests, commits, file contents, and code search across repositories you have access to. Add to `~/.superpi/agent/mcp.json` mcp.json ``` { "mcpServers": { "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"], "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "" } } } } ``` ### Linear Query and create issues, projects, and cycles in your Linear workspace from inside any harness. Add to `~/.superpi/agent/mcp.json` mcp.json ``` { "mcpServers": { "linear": { "command": "npx", "args": ["-y", "mcp-linear"], "env": { "LINEAR_API_KEY": "" } } } } ``` ### Sentry Surface error events, stack traces, and issue details from your Sentry organisation without leaving the terminal. Add to `~/.superpi/agent/mcp.json` mcp.json ``` { "mcpServers": { "sentry": { "command": "npx", "args": ["-y", "mcp-sentry"], "env": { "SENTRY_AUTH_TOKEN": "", "SENTRY_ORG": "" } } } } ``` ### Notion Read and write pages, databases, and blocks in your Notion workspace with a connected integration token. Add to `~/.superpi/agent/mcp.json` mcp.json ``` { "mcpServers": { "notion": { "command": "npx", "args": ["-y", "@notionhq/notion-mcp-server"], "env": { "NOTION_API_KEY": "" } } } } ``` ### Stripe Look up customers, charges, subscriptions, and refunds in your Stripe account for quick debugging or reporting. Add to `~/.superpi/agent/mcp.json` mcp.json ``` { "mcpServers": { "stripe": { "command": "npx", "args": ["-y", "stripe-mcp-server"], "env": { "STRIPE_SECRET_KEY": "" } } } } ``` ### PostgreSQL Query any PostgreSQL database - describe schemas, run read-only SQL, and inspect data without leaving your harness. Add to `~/.superpi/agent/mcp.json` mcp.json ``` { "mcpServers": { "postgres": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres"], "env": { "DATABASE_URL": "postgresql://user:password@host:5432/dbname" } } } } ``` ### Playwright Drive a real Chromium browser - navigate pages, fill forms, take screenshots, and extract content from the live web. Add to `~/.superpi/agent/mcp.json` mcp.json ``` { "mcpServers": { "playwright": { "command": "npx", "args": ["-y", "@playwright/mcp"] } } } ``` ### Context7 Pull in up-to-date library documentation and code examples at query time so your agent's answers are never stale. Add to `~/.superpi/agent/mcp.json` mcp.json ``` { "mcpServers": { "context7": { "command": "npx", "args": ["-y", "@upstash/context7-mcp"] } } } ``` ### Slack Search messages, list channels, and post to Slack workspaces where you have a bot token installed. Add to `~/.superpi/agent/mcp.json` mcp.json ``` { "mcpServers": { "slack": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-slack"], "env": { "SLACK_BOT_TOKEN": "", "SLACK_TEAM_ID": "" } } } } ``` ### Cloudflare Manage Workers, KV, R2, D1, and other Cloudflare resources directly from your harness via the API. Add to `~/.superpi/agent/mcp.json` mcp.json ``` { "mcpServers": { "cloudflare": { "command": "npx", "args": ["-y", "@cloudflare/mcp-server-cloudflare"], "env": { "CLOUDFLARE_API_TOKEN": "", "CLOUDFLARE_ACCOUNT_ID": "" } } } } ``` ## How MCP servers work with HarnessLink **Where the config lives.** Put servers in `~/.superpi/agent/mcp.json`. The HarnessLink MCP hub starts each one once per machine and serves it to every harness that runs `hnl mcp` - setup registers that in each harness. Or add a server to one harness's own MCP config instead, if only that harness should have it. **Merging snippets.** If `mcp.json` already exists, copy the inner server object from the snippet into your existing `mcpServers` block - do not replace the whole file. **Environment variables.** Values like `` are placeholders. Replace them with real credentials - do not commit secrets to version control. Use your shell profile or a secrets manager to inject them via the `env` block. **Community packages.** All servers listed here are community projects - verify the current package name and version before use, and review each server's own documentation for the latest configuration options. [Docs](https://harnesslink.sh/docs) · [Templates](https://harnesslink.sh/templates) · [Pricing](https://harnesslink.sh/pricing) --- Source: https://harnesslink.sh/releases # Release notes What shipped in each HarnessLink release, from the project's changelog. Run hnl update to get the latest. Update HarnessLink and every installed harness to its current release: hnl update New machine? Install with: curl -fsSL https://harnesslink.sh/install.sh | bash ## Version 17.5.80 Oct 10, 2026 1 change ### Changed - Keep-warm stops refreshing a conversation once its latest response calls `yield`, which is how an omp subagent ends. Of the subagents that ended since 1 October, most never resumed, so refreshing them would have cost about $122 to protect about $61; a subagent that does resume is warmed again from its next turn. ## Version 17.5.79 Oct 10, 2026 2 changes · [17.5.79 on its own page](https://harnesslink.sh/releases/17.5.79) ### Added - Keep-warm for Anthropic prompt caches, on by default. When a conversation goes quiet (a subagent running a long build or test, or you stepping away), the gateway refreshes its 5-minute cache 4 minutes 45 seconds after the last request by sending the same request again and closing it as soon as Anthropic reports usage, so you pay one cache read (0.05x to 0.1x the input price) instead of writing the whole conversation again at 1.25x when work resumes. It keeps going for up to `gateway.cache.keepWarmMinutes` idle minutes (35 by default; `0` turns it off), only for conversations with at least 20,000 cached tokens, and stops for a conversation after any miss or provider error. A harness that warms its own cache (omp's main session does) resets the timer, so nothing is warmed twice. The requests it repeats are held in memory only (at most 64 MB), never on disk or in logs; `x-superpi-cache: off` on a request opts that conversation out. On the founder's own traffic since 1 October, re-caching after 5 to 60 minute pauses was $576 of $1,458 cache-write spend, almost all in omp subagents, which omp never warms; replaying that traffic, keep-warm would have saved about $327 for $71 of refreshes. The Usage page's Cache writes card shows refreshes sent, their cost, and what they saved. ### Fixed - The gateway answered a harness's cache-refresh request from its own response cache. omp repeats a request about 4.5 minutes later to keep Anthropic's prompt cache alive; the gateway replied with its stored copy, so the request never reached Anthropic, the provider's cache expired, the next turn wrote the whole conversation again, and the replay was even counted as gateway savings. Since 1 October this happened to 502 of omp's 1,421 refreshes. The gateway now answers an Anthropic request from its cache only when the stored response is under a minute old; later repeats go to Anthropic. OpenAI and ChatGPT requests are unchanged. ## Version 17.5.78 Oct 10, 2026 1 change ### Fixed - Token counts of a billion or more read as billions on the dashboard (`18.2B`), not `18244.0M`. ## Version 17.5.77 Oct 10, 2026 6 changes · [17.5.77 on its own page](https://harnesslink.sh/releases/17.5.77) ### Added - Usage page: a Cache writes card. It shows what prompt-cache writes cost and their share of your spend, how many were written for 5 minutes or for 1 hour, and how much of a conversation was written to the cache again after it had already been cached, grouped by the break before it: under 5 minutes (the cache was invalidated or missed), 5 to 60 minutes (the 5-minute cache ran out; a 1-hour cache would have kept it) and over an hour. It also estimates whether a 1-hour cache would have saved money on your own traffic: what it would have saved on those rewrites against what 1-hour writes (2x the input price instead of 1.25x) would have cost. The figures start once the gateway on your machine is updated (`hnl update`); older gateways keep syncing as before. - Usage page: Gateway savings shows the gateway's cache assist: how many requests HarnessLink added prompt caching to, and what their cache reads saved. - Setting `gateway.cache.anthropicTtl` (`5m` by default, or `1h`) sets how long the caching the gateway adds lasts. It applies only to requests that arrive without any caching of their own; caching that omp, Claude Code or another harness sets itself is never changed. ### Changed - The gateway's prompt-cache assist (for requests that arrive with no caching of their own) now uses Anthropic's automatic caching, which moves forward with the conversation, plus one cache point on the system prompt, or on the tool list when there is no system prompt, so a new conversation with the same tools still starts from cache. Before, it marked the system prompt and the last message, which could miss the cache once a long agent turn added more than 20 blocks. - Cost figures price 1-hour prompt-cache writes at Anthropic's 1-hour rate (2x the input price) instead of the 5-minute rate (1.25x): the gateway reads the 5-minute / 1-hour split Anthropic reports, the price list carries a 1-hour rate, and the Usage page, Overview, usage limits and the cache-write advisory all use it. Before, 1-hour writes showed about 37% too cheap. ### Fixed - A synced table that gained columns in a new release kept uploading only its old columns on existing machines, because the change-capture triggers were never rebuilt. They are rebuilt when the synced columns change. ## Version 17.5.76 Oct 10, 2026 The changelog lists no changes for this release. ## Version 17.5.75 Oct 10, 2026 13 changes · [17.5.75 on its own page](https://harnesslink.sh/releases/17.5.75) ### Added - Owner console: an Analytics tab (`/owner/analytics`) with daily, weekly and monthly active users, sign-ups, an activation funnel (signed up, linked a device, uploaded something, came back on a later day), weekly retention cohorts, API traffic and errors by route and client (CLI, MCP server, dashboard), dashboard feature use, public site traffic and funnel (page views, install command copies, sign-in and checkout starts, button clicks, links out, countries, cookie choices) and Web Vitals by page, over 7, 30 or 90 days. Charts have a table view for screen readers. - First-party usage measurement on the public site and the dashboard, stored in HarnessLink's own Cloudflare account (Workers Analytics Engine, kept 3 months); no new analytics company is involved. Events carry the page's route pattern (`/history/s/:sessionId`), never its address, ids, search text or anything you type; the server adds only country, phone or computer, and the plan for signed-in users, and never stores IP addresses. Nothing is sent when your browser has Global Privacy Control on. Signed-in users also get one "active day" record per day they use HarnessLink, deleted with the account. - A page for each harness HarnessLink works with, at [https://harnesslink.sh/harnesses](https://harnesslink.sh/harnesses): Claude Code, Codex, omp, pi, Antigravity and Cursor. Each says what HarnessLink captures there, the commands that set it up, how memory reaches that harness's model (context hooks or MCP memory tools) and what does not work yet; the index compares all six. - Release notes at [https://harnesslink.sh/releases](https://harnesslink.sh/releases) come straight from this changelog: every release from 17.5.31 on, each with its own link, a page of its own for releases with longer notes, and an Atom feed at [https://harnesslink.sh/releases.atom](https://harnesslink.sh/releases.atom). - Shared links to any public page show a preview card with that page's own title and summary. - Build checks for the website: every public page is checked for its title, description, canonical address, one main heading, structured data, working links, image text, preview card and sitemap entry; bundle sizes are held to budgets; and CI runs Lighthouse (mobile) on the main pages and fails below 95 for performance, accessibility and best practices, or 100 for SEO. ### Changed - Public pages load faster. They no longer download the dashboard's code and styles, and every public page except the home page brings its own code in a separate file, fetched alongside the shared code: the JavaScript the home page loads drops from 208 KB to 99 KiB compressed (docs 109 KiB), and its CSS by 48%. The home page picture comes in a size that fits the screen, and the video further down loads only when you scroll to it. Measured on a mid-range phone profile, the home page went from 86 to 98 in Lighthouse and its main picture shows about 1.4 seconds sooner. - The MCP server identifies itself to the cloud, so the owner console counts its calls separately from the CLI's. - Google Analytics never loads when your browser sends Global Privacy Control, and the cookie banner does not ask in that case. ### Fixed - Public pages no longer log a 401 error in the browser console when you are signed out. - Fonts no longer break the site's Content Security Policy, and guide pages no longer shift when the web font arrives. - Text in the home page's tier tabs now has enough contrast, and the pricing page's headings are in order. - The guide on what HarnessLink captures from each harness said Antigravity had no transcript files; it is synced since 17.5.70. The usage guide said `hnl resume` offers Cursor sessions, which it does not, and showed MCP entries without their `--harness` flag. ## Version 17.5.74 Oct 10, 2026 1 change · [17.5.74 on its own page](https://harnesslink.sh/releases/17.5.74) ### Added - Search engines and AI assistants can now read the whole public site without running JavaScript. Every public page (home, pricing, docs, templates, integrations, release notes, contact, legal) arrives as finished HTML with its own title, description, canonical address and sharing preview, plus structured data that says what HarnessLink is (also "Harness Link" and `hnl`), with the Free, Pro and Team prices taken from the same plan table the app uses. The product guides (using, installing, memory banking, what is captured from each harness) are now public at [https://harnesslink.sh/docs/usage](https://harnesslink.sh/docs/usage) and alongside, and the docs page links them. For AI tools there is [https://harnesslink.sh/llms.txt](https://harnesslink.sh/llms.txt) (a summary with links), [https://harnesslink.sh/llms-full.txt](https://harnesslink.sh/llms-full.txt) (the whole site as Markdown) and a Markdown copy of each page (for example [https://harnesslink.sh/pricing.md](https://harnesslink.sh/pricing.md)). `robots.txt` now welcomes the major search and AI crawlers by name while keeping the dashboard out, `sitemap.xml` covers every public page with its last-updated date, and [https://harnesslink.sh/.well-known/security.txt](https://harnesslink.sh/.well-known/security.txt) says how to report a security problem. Addresses that don't exist now get a real "not found" answer instead of an empty page, and pages no longer flash light before turning dark for visitors who chose the dark theme. ## Version 17.5.73 Oct 10, 2026 The changelog lists no changes for this release. ## Version 17.5.72 Oct 10, 2026 The changelog lists no changes for this release. ## Version 17.5.71 Oct 10, 2026 2 changes · [17.5.71 on its own page](https://harnesslink.sh/releases/17.5.71) ### Fixed - A session over 8 MB uploaded only its first 8 MB, so on the dashboard a long session stopped hours or days before its newest steps. It now uploads its opening (up to 64 KB: the session header and first prompt) and as many of its newest steps as fit, with one line between them saying how many steps were left out. This applies to every harness. The dashboard shows that line as one note, for example "3,188 steps were not uploaded (session over 8 MB).", in the raw log and at the top of the turn that follows; a turn whose prompt was left out says so instead of showing an empty prompt. If the newest step is over the limit on its own, its longest texts are shortened so it still uploads. - New Antigravity work uploaded only on the 5-minute rescan, because the real-time watcher did not watch Antigravity's transcripts. It now watches `~/.gemini/antigravity-cli/brain/`, so a conversation uploads moments after it changes, like the other harnesses. Only a conversation's `transcript_full.jsonl` counts; the artifacts and other files in `brain/` never start an upload. ## Version 17.5.70 Oct 10, 2026 1 change · [17.5.70 on its own page](https://harnesslink.sh/releases/17.5.70) ### Fixed - An Antigravity session on the dashboard showed only your prompts, because its conversations were never uploaded. With Antigravity's transcripts synced, each conversation now uploads (sub-agent conversations stay out; as for every harness, one over 8 MB keeps its first 8 MB) and reads as turns: your words without Antigravity's metadata, its thinking, each tool call with its output, errors, where Antigravity compacted, and the answer. `hnl resume` no longer offers Antigravity or Cursor sessions, which none of its harnesses can resume (choosing omp copied the foreign transcript into omp's sessions). ## Version 17.5.69 Oct 10, 2026 The changelog lists no changes for this release. ## Version 17.5.68 Oct 10, 2026 1 change · [17.5.68 on its own page](https://harnesslink.sh/releases/17.5.68) ### Added - A session now reads as turns instead of one long log: each of your prompts with, in order, the model's thinking (folded), its notes, each tool call with its result, the decisions it stated and the final answer. Step through turns with Previous / Next or the turn numbers around the current one, show one turn or all of them, and jump straight to the answer; the raw event log is one click away. From History, "Inspect in window" opens the same view over your search results. Prompts that are not in the synced transcript appear in time order and say so, and "View response" from a search result opens that prompt's own turn. ## Version 17.5.67 Oct 10, 2026 The changelog lists no changes for this release. ## Version 17.5.66 Oct 10, 2026 The changelog lists no changes for this release. ## Version 17.5.65 Oct 10, 2026 1 change ### Added - Site analytics on the public pages only (never the dashboard): Cloudflare Web Analytics, which sets no cookies, and Google Analytics 4, which loads only after you choose Accept in the cookie banner, with advertising features off and page addresses sent without their query string. "Cookie settings" at the bottom of every public page changes your choice; Reject deletes the Google Analytics cookies. ## Version 17.5.64 Oct 10, 2026 5 changes · [17.5.64 on its own page](https://harnesslink.sh/releases/17.5.64) ### Added - The public site is ready for search engines: `robots.txt` (dashboard pages kept out), `sitemap.xml`, and its own title and search description on every public page. A link to a page that doesn't exist shows a 404 page with links home, to the docs and to pricing, instead of the sign-in page, and the 404 is kept out of search results. - A one-time notice on the public site says HarnessLink only sets the cookies needed to sign you in, and no advertising or tracking cookies. - The terms gain subscription billing and a refund policy (cancel any time, access until the end of the paid period, UK statutory rights unaffected); the privacy notice gains your UK GDPR rights, the processors HarnessLink uses, and how to ask for a Data Processing Agreement. ### Changed - The landing page's moving video stays on its first frame when your system asks for reduced motion. ### Removed - The dashboard's credit balance and top-up buttons (added in 17.5.62): no top-up could be bought and nothing spent credits. They come back when credits pay for something. ## Version 17.5.63 Oct 10, 2026 6 changes · [17.5.63 on its own page](https://harnesslink.sh/releases/17.5.63) ### Added - Session handoff instead of compaction. Every harness session keeps a task checkpoint (`state/--.md`: goal, next step, latest tool calls, decisions, files edited, todos, status `open`/`done`/`picked_up`), updated by the autobank as the transcript grows. Past `context.handoffAt` (default: half the context window or 100k tokens, whichever is smaller; a token count, `"40%"` or `off`), measured from the transcript's real usage, Claude Code's new `Stop` hook asks the model to save a handoff with `memory_bank` and send you to `/clear`, and omp tells you to start `/new`. A `PreCompact` hook (Claude Code, Codex, omp) saves the handoff as a bank entry tagged `handoff` and skips an automatic compaction while the context is under 90% of the window; `/compact` and near-limit compactions go ahead. The next session (startup, `/clear`, after a compaction) gets the newest open handoff first in its brief, then marks it picked up. The service adds the new hooks to existing installs. - `hnl tasks` breaks a long or rambling request into separate requirements, grouped into five phases (investigate, implement, verify, check automatically, validate in use), and saves the plan so a new session can pick it up. - The command is `hnl`. Help, hints and errors say `hnl` whichever installed name you ran (`superpi`, `harnesslink` and `hlk` still work), and shell completions register `hnl`. Harness configs, hooks and the background service keep running `superpi`, which every install has. - The SessionStart brief carries the work-state snapshot of this session, else the most recently modified open one (it used to take the alphabetically last file), and is now up to 9,500 characters for Claude Code and omp and 7,000 for Codex (was 4,000). ### Fixed - `hnl daemon status`, `stop` and the new `restart` act on the supervised service (launchd, systemd, logon task); `status` used to say "stopped" while it ran, and shows the running build. `hnl update` restarts a service still running an older build, even when the CLI itself was already current. ### Removed - The gateway's context monitor (added in 17.5.62): it put its advice in response headers that no harness reads, and guessed token counts from text length. Session handoff (above) uses the real token counts and acts through each harness's own hooks. ## Version 17.5.62 Oct 9, 2026 3 changes · [17.5.62 on its own page](https://harnesslink.sh/releases/17.5.62) ### Added - Context monitor in local gateway (`gateway/context-monitor.ts`): evaluates prompt tokens against model context windows and emits `x-superpi-recommend-clear` and utilization headers when reaching the 10% context ceiling, preventing expensive LLM context compaction while preserving prefix cache hits. - Instruction Decomposition Engine and `hnl tasks` command (`tasks/decomposer.ts`, `commands/tasks.ts`): tears apart complex or gabbled prompts into atomic requirements organized across 5 disciplined execution phases (Investigation, Implementation, Verification, Auto-Verification, Validation & Use). - Zero-loss session clear recovery: `assembleBrief` automatically injects active work-state snapshots (`state/--.md`) on `SessionStart`, restoring plans and progress immediately following a `/clear` reset. ## Version 17.5.61 Oct 8, 2026 2 changes ### Fixed - Eliminated word duplication across the landing page: removed the duplicate "Sign in" button under the hero install command (retaining it in the header nav and closing section); replaced duplicate 7-harness chip roster in the Tiered Feature telemetry HUD with distinct bus topology metrics. - Resolved image text clustering: redesigned LinkField SVG badges with clean single-line labels, proportional sizing, high contrast, and dedicated indicator lights, ensuring crisp readability across all viewport widths. ## Version 17.5.60 Oct 8, 2026 1 change ### Fixed - Fixed website landing page layout alignment and edge feathering: the hero copy now aligns precisely with the top navigation brand container in a dedicated two-column desktop grid, eliminating the suspended offset and preventing text from overlapping the hardware illustration; the Tiered Feature moving video and hero SVG render now feature seamless radial feathering that dissolves into the background surface with zero borders or rectangular frames. ## Version 17.5.59 Oct 8, 2026 3 changes · [17.5.59 on its own page](https://harnesslink.sh/releases/17.5.59) ### Added - Added an interactive 4-tier architectural deep dive on the landing page demonstrating plugging in real coding agent harnesses (omp, Claude Code, Codex, Antigravity, Cursor, pi, others) with sticky background motion video stage, live telemetry HUD, and reduced-motion compliance. ### Changed - The landing page hero is fully responsive across all screen sizes (from 360px phones up to 4K ultrawide monitors) with a two-column desktop layout that prevents cropping or hiding on screen expansion. The hero features a realistic 3D physical computing miniature hardware model connecting real AI coding agent harnesses (omp, Claude Code, Codex, Antigravity, Cursor, pi, and others) to the central HarnessLink controller, with accessible HUD badges, live conduit pulses, and Atlassian Design System dark surface blending. - The landing page lede and brand positioning explicitly include the full roster of real AI coding harnesses (omp, Claude Code, Codex, pi, Antigravity, Cursor, and others). ## Version 17.5.58 Oct 8, 2026 1 change ### Changed - The landing page is short: a full-width banner shows your harnesses joined to one shared memory, with light moving gently along the links (still if your system asks for reduced motion), then four lines on what HarnessLink does, three measured figures and the install command. It no longer carries illustrations, dashboard screenshots or terminal transcripts. ## Version 17.5.57 Oct 8, 2026 1 change · [17.5.57 on its own page](https://harnesslink.sh/releases/17.5.57) ### Added - `superpi add qmd` sets up [qmd](https://github.com/tobi/qmd), a local search engine (keywords, vectors and reranking, all on your machine), over your HarnessLink memories. It installs qmd if needed, indexes your memories, adds qmd's MCP server to omp, Cursor, Codex and Claude Code, and, after you confirm, downloads its models (about 2.3 GB). The service keeps the index current as new memories arrive. `superpi add --list` shows its state, and `superpi remove qmd` takes out only what HarnessLink added; your own `qmd` entries and collections are never touched. ## Version 17.5.56 Oct 8, 2026 1 change ### Added - superpi.sh, superpi.app and their `www.` and `api.` hosts now send browsers to the same page on [https://harnesslink.sh](https://harnesslink.sh) (sign in there once more; GitHub works for everyone). Installer and update downloads follow the redirect, and every API call is still answered on the old hosts, so installed CLIs keep working without an update. ## Version 17.5.55 Oct 8, 2026 5 changes · [17.5.55 on its own page](https://harnesslink.sh/releases/17.5.55) ### Added - Install and `superpi update` also link `harnesslink` and `hlk` to the same launcher as `superpi` (Windows: `harnesslink.cmd`, `hlk.cmd`); an `hlk` that belongs to another program is never replaced. Every `SUPERPI_*` environment variable can also be set as `HARNESSLINK_*`, which wins. Cloud calls send `User-Agent: harnesslink/`. ### Changed - The CLI says HarnessLink: every message, help text, setup screen and MCP tool description, with links to [https://harnesslink.sh](https://harnesslink.sh) and the design system's blue as its accent. The command is still `superpi` and data stays in `~/.superpi`. - The cloud API base moves to [https://api.harnesslink.sh](https://api.harnesslink.sh). A `cloud.token` pinned to api.superpi.sh, api.superpi.app, superpi.sh or superpi.app is rewritten in place (atomically, still 0600) the first time the CLI or the service reads it; self-hosted bases are untouched. The installers and `superpi update` download from [https://harnesslink.sh](https://harnesslink.sh) by default; superpi.sh keeps working. - Hooks, the omp extension, the MCP hub, `mcp register` status and the service supervisor recognise both the `superpi` and the future `harnesslink` names and still write `superpi`. Installing the service removes a `harnesslink`-named unit, so two services never compete for the gateway port. ### Fixed - `superpi telegram` ignored the cloud URL override and the retired-domain rewrite; it now uses the same API base as every other cloud call. ## Version 17.5.54 Oct 8, 2026 2 changes · [17.5.54 on its own page](https://harnesslink.sh/releases/17.5.54) ### Added - SuperPi is now **HarnessLink**, at [https://harnesslink.sh](https://harnesslink.sh). The website, dashboard and owner console carry the new name, mark and wordmark, favicon, touch icon and share card, and the landing page gains illustrated feature sections. Sign-in (GitHub and Google), device approval links from `superpi cloud login` and Stripe returns use harnesslink.sh, and product email comes from HarnessLink , where replies now reach a person. superpi.sh, superpi.app and their api. hosts keep answering every API call, so installed CLIs keep working unchanged. Dashboard preferences (theme, install target, side-nav width) reset once because they're stored under new names. The command is still `superpi`. - Owner console: a Legacy hosts card shows which devices still call api.superpi.sh, api.superpi.app, superpi.sh or superpi.app, as a share of active devices over 7, 14 or 30 days. ## Version 17.5.53 Oct 7, 2026 2 changes · [17.5.53 on its own page](https://harnesslink.sh/releases/17.5.53) ### Added - `superpi run --harness ""` and the `delegate` / `delegate_status` MCP tools hand a task to another harness. It runs headless with that harness's default permissions and never a bypass flag, at most 2 delegations deep, 3 at a time per machine, with a 15-minute default timeout that kills the whole process tree. The child joins the caller's run on the Runs page, and its turn is banked as one `delegated` memory entry that the returned `transcript_ref` reads back through `memory_get`. - A local memory index (`~/.superpi/agent/memory-index.db`, SQLite full-text search, kept current by the service) answers `memory_search`, `memory_get`, `context_brief` recall and the context hooks offline in milliseconds. `memory_search` adds other machines' results from the cloud when it answers within 1.5 s, and otherwise says in one line that cloud results were unavailable. Signed out, it returns this machine's memories instead of an error. ## Version 17.5.52 Oct 7, 2026 1 change · [17.5.52 on its own page](https://harnesslink.sh/releases/17.5.52) ### Changed - Cost estimates now come from one public price list shared by the gateway and the dashboard (LiteLLM's model price data, refreshed hourly by SuperPi Cloud). The SuperPi service fetches the current list from the cloud every six hours and the gateway prices each response with it, falling back to the list bundled with SuperPi when offline, so USD usage limits add up the same on your machine and in the cloud. Models are matched however a harness names them (`claude-opus-4-6[1m]`, `anthropic/claude-opus-4.6`, dated snapshots, `gemini-3.8-flash-high`). Gemini models reached through Gemini CLI or Antigravity are now priced at Google's list price instead of $0, and Claude Fable 5.1 cache reads at $0.25 per million instead of $1. The Overview, Usage page and cost-review email show the date of the prices ("List prices as of …"). ## Version 17.5.51 Oct 7, 2026 1 change ### Fixed - A policy cache written by SuperPi 17.5.49 or earlier never picked up newer fields while your organisation's policy stayed unchanged, so refusals said "your organization's" instead of its name and `superpi` showed "fetched at an unknown time". The cache is now fetched in full once and records which version wrote it. SuperPi Cloud also answers "not modified" to the weak ETag form Cloudflare hands out. ## Version 17.5.50 Oct 7, 2026 2 changes · [17.5.50 on its own page](https://harnesslink.sh/releases/17.5.50) ### Added - Org model rules and usage limits. On the dashboard's Policies page, admins can allow or deny models by pattern (`claude-opus-*`, `anthropic/*`), optionally for one harness; once any allow applies, every other model is refused. They can also cap spend (USD, SuperPi's estimate from list prices) or tokens per UTC day or month, per machine or per person across machines. The SuperPi gateway enforces both before a model call leaves the machine, for Claude Code, Codex, and the Anthropic and OpenAI Codex providers in omp and pi once connected. A refused call names the rule or limit, the organisation and the Policies page; a limit refusal adds the usage and when it resets. A response that starts under a limit finishes; the next call is refused. `superpi` and `superpi cloud status` show the model rules and each limit's current usage. ### Changed - The download the installer fetches is about 0.8 MB (was 1.7 MB) and installs no third-party packages: the unused model-discovery code and the libraries it needed are no longer shipped. ## Version 17.5.49 Oct 7, 2026 1 change · [17.5.49 on its own page](https://harnesslink.sh/releases/17.5.49) ### Changed - The website, dashboard and owner console follow the current Atlassian Design System, in light and dark: its colours, type sizes, 32px buttons, focus ring and form fields; status labels, notifications in the bottom-left corner (errors stay until you dismiss them), tooltips you can reach with the keyboard, menus for row actions and your account, and a page header with breadcrumbs on every page. The sidebar can be resized, and collapsed with Ctrl+[; Feedback and Help sit in the top bar. Pages fit a phone without sideways scrolling, and chart labels stay the same size at every width. ## Version 17.5.48 Oct 7, 2026 2 changes · [17.5.48 on its own page](https://harnesslink.sh/releases/17.5.48) ### Fixed - Autobank no longer files a long turn under the last thing the agent said before it stopped. When a turn ends mid-work (interrupted, the harness exits, or it goes idle) on a progress line like "Looking for it in your home directory…", the entry's result lists the turn's latest progress notes, oldest first, and its title comes from your prompt. Turns that end on an answer bank exactly as before; when a turn gives several answers (for example a Claude Code Stop hook continues it), the last ones are kept. Entries already banked are not changed. - Autobank now keeps the work an agent does after its turn ended, when a finished background job, a message from another agent or a todo reminder woke it instead of you. In omp that work was dropped; in Claude Code a background-task notice became the prompt. Each such stretch is now its own entry, with a short prompt naming what woke it (for example "Continued after: Background job bg_119 has completed."), never the notice itself. `superpi cloud autobank backfill` now re-reads the transcripts in its window and adds turns earlier releases missed; it never banks a turn twice and never changes existing entries. ## Version 17.5.47 Oct 7, 2026 4 changes · [17.5.47 on its own page](https://harnesslink.sh/releases/17.5.47) ### Breaking Changes - `superpi add` no longer writes skills and agents to `~/.superpi/agent`, and `--force` no longer overwrites existing files: it only replaces SuperPi's own copies that you edited. Skills already under `~/.superpi/agent/skills` stay where they are; run `superpi add ` again to install them into your harnesses. ### Added - Your organisation's policies are now enforced, not only stored. Tool and command rules from the dashboard's Policies page, including their folder and model conditions, are checked before a tool runs in Claude Code, Codex and omp: a denied tool or command is blocked with the name of the policy, and "ask first" rules ask in Claude Code and omp (Codex blocks them, because it can't ask from a hook). Policy instructions are added at the start of each session in those harnesses. Rules are cached on the machine and refreshed every minute, so they apply offline and never slow a tool call. pi, Cursor and Antigravity are not enforced yet. `superpi` and `superpi cloud status` show which policy is active and when it was last fetched. - `superpi add ` installs the skill where each harness reads it: `~/.agents/skills` (Codex, also read by pi and Cursor), `~/.claude/skills` (Claude Code), `~/.omp/agent/skills` (omp), `~/.pi/agent/skills` (pi), `~/.gemini/antigravity-cli/skills` (Antigravity CLI) and `~/.cursor/skills` (Cursor), for every harness enabled or detected on the machine. It shows where it will write and asks first (`--yes` skips); `--harness ` targets one harness. Running it again changes nothing, and a skill of the same name that SuperPi did not install is never overwritten. `superpi add --list` shows what is installed for each harness, and `superpi remove ` removes only the files SuperPi wrote. Agents and extensions install for omp only. ### Changed - When the SuperPi service starts (including after `superpi update`), it adds the policy hook wherever SuperPi's context hooks are already installed and refreshes its omp extension, so no reinstall is needed; nothing is added where you never installed the hooks. Codex skips hooks you haven't trusted, so `superpi` shows "run /hooks in Codex" until you trust SuperPi's. ## Version 17.5.46 Oct 7, 2026 1 change ### Fixed - Ask could answer "I couldn't find this" about work you had done when the work was only recorded in the steps of a banked turn (edits, tests, commits, releases), not in its prompt or result. Ask now searches and reads those steps and cites them as what was done. In the source panel, your search words are marked as whole words instead of inside other words ("serv" no longer lights up part of "observer"). ## Version 17.5.45 Oct 7, 2026 1 change ### Fixed - Two machines with the same home folder (for example two servers both logged in as `ubuntu`) no longer overwrite each other's imported Hermes and MemPalace memories in the cloud: each machine keeps its own copy, and its earlier imports move into that machine's folder on the next import. ## Version 17.5.44 Oct 7, 2026 1 change ### Fixed - The dashboard's Overview showed "Devices seen · 7d: 0" while your machines were syncing: it only counted when each machine first signed in. It now counts a machine's sync activity, the same rule the Devices page and the owner console use. ## Version 17.5.43 Oct 7, 2026 The changelog lists no changes for this release. ## Version 17.5.42 Oct 7, 2026 6 changes · [17.5.42 on its own page](https://harnesslink.sh/releases/17.5.42) ### Added - The Owner console can act, not only read: suspend and unsuspend an account, sign it out everywhere, delete it on the user's behalf, grant or revoke an organisation's plan, record an offline licence (term, seats, price, invoice) that starts and ends on its own, transfer a team's ownership, and mark support messages resolved with a private note. Each action needs a reason and is written to the audit trail in the same step; if that write fails, nothing changes. Plans that Stripe bills are still changed only in Stripe. This replaces the `grant-plan.sh` script, which is removed. - A suspended account is stopped everywhere: the dashboard shows a "This account is suspended" page, sync and Ask (Telegram included) are refused, and the local SuperPi gateway answers harness model calls with the suspension message instead of forwarding them. Everything works again as soon as the account is unsuspended. - In Ask, clicking a source or its [n] in the answer opens a panel with all of it: the full memory entry or prompt with your search words marked, the answer recorded for that prompt, the prompts before and after it in the session, and a link to the full page. ### Changed - The website, dashboard and owner console have a new design in light and dark: one set of buttons, tables, forms, badges and charts across every page, and pages that fit a phone without sideways scrolling. Chart labels stay the same size at every width. - The Memory pop-up shows an entry as formatted text instead of raw markdown: a header with project, folder, dates, tags and a link to the session; for banked turns, the result first with the prompt above it and tool calls folded away. "Copy as text" copies it without markdown. - Ask answers read more of each source: a prompt together with the result recorded for it and the prompts around it, a memory entry's whole prompt and result, a guide section in full. ## Version 17.5.41 Oct 7, 2026 1 change ### Fixed - A harness session that started while the SuperPi service was down, restarting or full kept only SuperPi's own tools (no Vaaya, Jev or other forwarded MCP servers) until the harness was restarted. `superpi mcp` now keeps dialing the service every 30 seconds; when it answers, the session switches over and the harness is told to re-list its tools. ## Version 17.5.40 Oct 7, 2026 3 changes · [17.5.40 on its own page](https://harnesslink.sh/releases/17.5.40) ### Fixed - Deleting an account linked to Telegram failed partway, after the account's synced data was already gone, leaving an account that could still sign in. Deletion now also removes Telegram links and link codes, pending agent/skill edits and the personal organisation's Ask counter. Merging a duplicate account that had Telegram linked failed the same way; the Telegram chat now moves to the merged account. - Deleting an account whose own plan is billed through Stripe is refused until the subscription is cancelled (Plans → Manage subscription), so nobody keeps being charged for an account that no longer exists. - When the owner of a team deletes their account, the longest-standing admin (otherwise the longest-standing member) becomes the team's owner, recorded in the team's audit log, instead of the team being left without one. ## Version 17.5.39 Oct 7, 2026 The changelog lists no changes for this release. ## Version 17.5.38 Oct 7, 2026 1 change ### Fixed - SuperPi Cloud's weekly database backup and weekly cost review ran every hour once the hourly schedule was added, exporting every table each time. They run on Monday's schedule again. ## Version 17.5.37 Oct 7, 2026 1 change · [17.5.37 on its own page](https://harnesslink.sh/releases/17.5.37) ### Added - The dashboard has an Owner console for the platform owner only (pinned by user id; everyone else gets "No such page"). It shows read-only views of users, organisations, billing, support messages and its own audit trail. Billing compares each organisation's plan with its Stripe subscription and flags mismatches, and lists invoices with links to the Stripe Dashboard, where any change is made. It shows counts, sizes, dates and plan, device and token details only, never memory content, prompts, session titles or folders, or Telegram messages. Opening a user, an organisation or invoices is recorded in the audit trail. ## Version 17.5.36 Oct 7, 2026 1 change ### Fixed - The dashboard's Usage page no longer keeps reloading itself. Any refresh (a sync, returning to the tab) asked for a time range ending at that second, which nothing had cached, so the page showed loading placeholders and fetched everything again, over and over. The range now ends at the top of the next hour, so a refresh updates the figures in place. ## Version 17.5.35 Oct 7, 2026 1 change · [17.5.35 on its own page](https://harnesslink.sh/releases/17.5.35) ### Changed - The dashboard's Ask finds what you meant, not only the words you typed: an AI model picks the keywords and intent, then memories, prompt history, sessions and the SuperPi guides are searched together. Entries that hold the answer rank above the prompt that asked the question, sources appear with links straight to the entry, prompt or guide section before the answer streams in, and an answer with no support says so instead of guessing. An Ask takes 4–7 s (was up to 33 s), and the search index now keeps itself up to date every hour instead of waiting for "Rebuild index". ## Version 17.5.34 Oct 7, 2026 1 change ### Fixed - The dashboard's Usage page went blank when a model had no known price (for example calls recorded as model `unknown`): its cost came back empty instead of $0 and the page crashed. A page that hits an error now shows the error and a Retry instead of a blank screen, and the menu stays usable. ## Version 17.5.33 Oct 7, 2026 The changelog lists no changes for this release. ## Version 17.5.32 Oct 6, 2026 5 changes · [17.5.32 on its own page](https://harnesslink.sh/releases/17.5.32) ### Added - `superpi cleanup` also offers to delete the old agent's background-job output in `~/.superpi/run/daemons` (logs only), showing its size; the home screen and `superpi update` show the combined size of everything the old agent left. ### Changed - Autobank no longer banks turns or work state from temporary folders (`os.tmpdir()`, `/tmp`, `/private/tmp`, `/var/folders/*/*/T`): they were test runs and scratch sessions that filled the dashboard's Memory page. `superpi cloud autobank run` reports how many it skipped. - The dashboard's Memory page has dropdown filters (project, harness, type, machine, time) kept in the page address, shows entry titles and folder names instead of file paths, and hides temporary folders and generated index/summary files unless asked. - The gateway's response cache is capped at 128 MB (was 512 MB), and `gateway.db` now shrinks when cache entries expire or are evicted instead of keeping the space. An existing `gateway.db` holding more than 32 MB of unused space is rewritten once when the service starts (a 552 MB file became 77 MB in under a second). - The service log `~/.superpi/logs/daemon.log` no longer grows forever: past 5 MB it moves to `daemon.log.1` (replacing the previous one) and starts empty. ## Version 17.5.31 Oct 6, 2026 7 changes · [17.5.31 on its own page](https://harnesslink.sh/releases/17.5.31) ### Breaking Changes - SuperPi no longer contains its own coding agent. It now looks after the coding agents you already use (omp, Claude Code, Codex, pi, Antigravity): the gateway, shared memory, autobank, sync and restore. Commands that belonged to the old built-in agent (for example `superpi commit`, `superpi models`, `superpi worktree`, or a prompt typed after `superpi`) print one line pointing you to omp or your harness and exit with code 2. - `superpi integrate` and `superpi config` are gone. - `superpi update` no longer has `--plugins`. ### Added - Plain `superpi` shows a home screen: whether the SuperPi service is running and its version, your sign-in, sync health, autobank for each harness, what each harness is connected to (gateway, transcripts, autobank, context, memory tools) and the one thing to do next. Without a terminal it prints the same as plain text. On a machine that is not signed in yet, it runs `superpi cloud setup` instead. - Added `superpi cleanup`: it finds the git worktrees the old agent left under `~/.superpi/wt`, shows how much space they use, and deletes them only after you agree. Worktrees that still hold uncommitted or unpushed work are listed separately and are never deleted without asking. The home screen and `superpi update` offer the same cleanup when leftovers exist. ### Changed - The install is about 13 MB (was 1.7 GB) and no longer needs a native add-on. - The SuperPi service uses about 61 MB of memory (was 666 MB). The changelog starts at version 17.5.31; earlier releases have no notes here. --- Source: https://harnesslink.sh/contact # Contact Questions, enterprise enquiries, or just feedback - we read every message. --- Source: https://harnesslink.sh/terms # Terms of service Last updated: October 2026 ## Service provided as-is HarnessLink is provided **as-is and without warranty of any kind**, express or implied, including but not limited to warranties of merchantability, fitness for a particular purpose, or non-infringement. We do not guarantee uptime, data durability, or continued availability of any feature. There is no service-level agreement (SLA). We may change, suspend, or discontinue the service at any time with reasonable notice where practicable. ## Your account You must have a GitHub or Google account to sign in. You are responsible for maintaining the security of your GitHub or Google credentials and any API tokens minted through HarnessLink. Each account is personal. You may not share your account with others or create accounts on behalf of a third party without their knowledge and consent. ## Acceptable use You agree not to use HarnessLink to: - Violate any applicable law or regulation - Upload content that infringes third-party intellectual property rights - Attempt to access another user's data or circumvent the row-level isolation described in our privacy notice - Conduct automated attacks against the service or its infrastructure - Use the service to process content that is illegal in the jurisdiction where you reside ## Data and privacy Your use of HarnessLink is also governed by our [privacy notice](https://harnesslink.sh/privacy), which explains what data is stored and how to delete it. ## Subscriptions and billing Paid subscriptions (Pro and Team) are billed in advance each month through Stripe. The Free plan is not billed. ## Refund policy **Subscriptions:** You may cancel your subscription at any time directly through your billing settings. Cancellation takes effect at the conclusion of your current billing period, and you will retain full access to your plan until that date. Nothing in this policy limits or excludes your statutory consumer rights under applicable laws in England and Wales or the United Kingdom. ## Account termination You may delete your account at any time from **Settings → Account → Danger zone**. Deletion is immediate, permanent, and removes all associated data. We may suspend or terminate accounts that violate these terms, with or without notice depending on the severity of the breach. ## Changes to these terms We may update these terms from time to time. Material changes will be communicated via the email address associated with your account where reasonably practicable. Continued use of the service after changes take effect constitutes acceptance of the revised terms. ## Governing law These terms are governed by the law of England and Wales, and the courts of England and Wales have jurisdiction over any dispute about them. If you are a consumer living elsewhere in the United Kingdom, you may also bring proceedings in your local courts, and nothing in these terms removes protection that the law of the country where you live gives you. For organisations that use HarnessLink to process personal data on behalf of their team, our [Data Processing Agreement](https://harnesslink.sh/dpa) forms part of these terms. ## Contact For questions about these terms, please use our [contact form](https://harnesslink.sh/contact). --- Source: https://harnesslink.sh/privacy # Privacy notice Last updated: October 2026 ## What HarnessLink stores ### Prompt history When cloud sync is enabled, the prompts you type into your harnesses (omp, Claude Code, Codex, pi, Antigravity) are uploaded to our servers and indexed so you can search them from the dashboard. Every string value is redacted on your machine before upload - provider credentials, API keys, and other secret-shaped tokens are stripped before the data leaves it. ### Usage metrics Token counts, model names, and cost estimates for your harnesses' model calls that go through the HarnessLink gateway, in hourly totals, plus any usage HarnessLink's old built-in agent recorded. Prompts and responses passing through the gateway are not uploaded as usage, and provider account keys are not stored. ### Session transcripts When session sync is on, your harnesses' redacted JSONL transcripts are uploaded and stored in Cloudflare R2 object storage. The same client-side redaction pass applies: secret values are stripped before upload. ### Memory files When memory sync is on, your harnesses' own memory files (such as `CLAUDE.md`, `AGENTS.md` and `memories/`) and the memory bank HarnessLink writes from their finished turns are uploaded. These are redacted by the same client-side pass. ### Device information Hostname, platform, and a device identifier are stored for each machine you link. The device profile holds each harness's setup Markdown (agents, commands, rules, skills) and MCP server configurations, with secret values replaced by key names only. ### Account information Your GitHub or Google username, email address, and provider user ID, received at sign-in via OAuth. ## What HarnessLink never stores - Provider credentials (Anthropic, OpenAI, Google, etc.) - stripped client-side - Secret environment variable values - replaced with key names only - MCP server `env` and `headers` values - names only are stored - Raw session content before client-side redaction - Passwords - sign-in is GitHub or Google OAuth; no password is ever collected ## Cookies and analytics **Essential:** signing in sets one session cookie (`__Host-sp_session`) and, while you sign in, short-lived cookies that protect the sign-in from forgery. These are needed for the service to work and are set without asking. **Our own measurement:** on the public pages and in the dashboard, your browser sends us short reports so we can see which pages and features are used and how fast pages load. A report holds an event name (such as a page view, a copied install command, a started sign-in or a dashboard feature used), the page's route pattern rather than its address (for example `/history/s/:sessionId`, never the session's ID) and, for page speed, Web Vitals timings such as how long the main content took to appear. Our server adds your country, whether the device is a phone or a computer and, in the dashboard, your plan. No cookie is set and no identifier is stored in your browser. These reports never contain page addresses, query strings, IDs, search text, anything you type, or the content of your memory or sessions, and they are not linked to your account. Your IP address is used only in passing to limit abuse and is never stored. The reports are kept in Cloudflare Workers Analytics Engine (Cloudflare is already our processor) for three months. We also count requests to our API by route, status and response time, without any user ID. **Active days:** to count active users exactly, while you are signed in we record each day you used the service and the kind of client you used (CLI, dashboard, MCP or hook). This is kept with your account and deleted with it. **Global Privacy Control:** if your browser sends the Global Privacy Control signal, we send none of these reports and never load Google Analytics. **Cloudflare Web Analytics:** on the public pages (not the dashboard) we also count visits with Cloudflare's analytics, which sets no cookies and does not identify you. **Google Analytics:** only if you choose Accept in the cookie banner, the public pages load Google Analytics 4, which sets `_ga` cookies to tell visits apart for up to two years. It receives page addresses without their query string and the public-page events described above, never anything from the dashboard. Google's advertising features and signals stay off. Google processes this data as our processor under its data processing terms. You can change your choice at any time with **Cookie settings** at the bottom of every public page; choosing Reject turns it off and deletes the `_ga` cookies. Your cookie choice and theme are kept in your browser's local storage, not in cookies. When you are signed in, your theme is also saved to your account so it follows you to other browsers. ## Isolation Every row in every database is stamped with your organisation ID and user ID at write time and predicated on both at read time. No query issued by the server can return another account's data, even with a valid session. This is enforced at the database layer, not just in application logic. ## Deletion You can permanently delete your account and all associated data from **Settings → Account → Danger zone**. Deletion immediately removes: - Every row in both the control and tenant databases scoped to your account - All session transcript objects in R2 storage under your tenant prefix - All semantic search vectors in the Vectorize index associated with your content - Org policy records and policy audit log for your personal organisation - Advisory notification history tied to your account Deletion cannot be undone. However, automated weekly backups may retain a copy of your data for up to **8 weeks** after deletion. These backups are stored in a restricted R2 namespace and are not accessible to other users. They are used only for operational recovery purposes and are deleted automatically after the retention window expires. ## Infrastructure and data processors HarnessLink runs on [Cloudflare](https://cloudflare.com) Workers, D1, Vectorize, R2, Workers Analytics Engine and Web Analytics; processes payments via [Stripe](https://stripe.com); and, only with your consent, measures the public pages with [Google Analytics](https://marketingplatform.google.com/about/analytics/). These providers act as our data processors under their data processing terms. Some process data outside the UK; those transfers rely on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, or on the UK-US data bridge where the provider is certified. ## Data protection rights (UK GDPR) Under the UK General Data Protection Regulation and the Data Protection Act 2018, you hold rights including: - **Right of access:** You can inspect all data stored about your account through the web dashboard. - **Right to rectification:** You can update your profile and organisation details at any time in Settings. - **Right to erasure:** You can permanently wipe all stored data via Settings → Account → Danger zone. - **Right to restriction and objection:** You can disable cloud sync entirely using the CLI. - **Right to data portability:** All memories, session transcripts, and device snapshots remain human-readable files that you can export or sync back to your machine at any time. When organisations use HarnessLink to manage team workflows, HarnessLink operates as a Data Processor under their instruction with respect to workspace data, and as a Data Controller for primary account identity. ## Contact For privacy enquiries or data protection requests, please use our [contact form](https://harnesslink.sh/contact). Organisations using HarnessLink for a team are covered by our [Data Processing Agreement](https://harnesslink.sh/dpa). --- Source: https://harnesslink.sh/dpa # Data Processing Agreement Version 1, October 2026 ## 1. Who this agreement is between This agreement applies when an organisation (the **customer**) uses HarnessLink for a team and, in doing so, has HarnessLink (**we**) process personal data on its behalf. The customer is the controller of that data and we are its processor. It forms part of our [terms of service](https://harnesslink.sh/terms) and takes effect when the customer first syncs team data. Where this agreement and the terms differ about personal data, this agreement wins. For your own account details (your sign-in identity and billing), we are the controller; our [privacy notice](https://harnesslink.sh/privacy) covers that. ## 2. What we process - **Subject matter and purpose:** storing, syncing, searching and restoring the customer's coding-agent sessions, prompt history, memory and harness setup, and answering the customer's questions about them (Ask), as the customer's members choose to sync them. - **Duration:** for as long as the customer's organisation exists, then until deletion completes (section 6). - **Types of personal data:** members' names, email addresses and sign-in identifiers; device names; and any personal data contained in synced prompts, transcripts and memory files after the client-side redaction described in the privacy notice. - **Data subjects:** the customer's members, and people mentioned in the content they sync. ## 3. Our commitments - We process the data only on the customer's documented instructions, which are these terms and the settings the customer chooses in HarnessLink, unless the law requires otherwise; if it does, we tell the customer first unless the law forbids that. - Everyone who can access the data is bound by confidentiality. - We keep appropriate technical and organisational security measures, including: encryption in transit (HTTPS only) and at rest by our hosting provider; credentials and secret values removed on the member's machine before upload; every stored row stamped with its organisation and user and checked on every read; and owner access to accounts limited to a console that records each access in an audit trail. - We help the customer respond to requests from data subjects, and with security, breach notification, data protection impact assessments and consultation with the regulator, taking into account the nature of the processing and the information available to us. - We notify the customer without undue delay after becoming aware of a personal data breach affecting its data, with the information we have at the time. - We make available the information needed to show we meet these commitments, and allow and contribute to reasonable audits on reasonable notice, at the customer's cost. ## 4. Sub-processors The customer gives general authorisation for these sub-processors: - [Cloudflare](https://www.cloudflare.com/cloudflare-customer-dpa/): hosting, databases, file storage, search and AI processing. - [Stripe](https://stripe.com/legal/dpa): payments (billing contact details only). Each is bound by data protection terms that give at least the protection in this agreement, and we remain responsible for them. We will give notice of a new sub-processor before it processes the customer's data; the customer may object on reasonable data protection grounds, and if we cannot resolve the objection the customer may stop using the service and delete its organisation. ## 5. International transfers Where a sub-processor handles the data outside the UK, the transfer relies on the UK International Data Transfer Addendum to the EU Standard Contractual Clauses, or on the UK-US data bridge where the provider is certified. ## 6. Deletion at the end Synced data stays as files on members' machines, so the customer keeps its own copy. When the customer deletes its organisation or an account (**Settings → Account → Danger zone**), we delete the data from our databases, file storage and search index at once. Copies in our automated backups expire within 8 weeks. We keep nothing longer unless the law requires it. ## 7. Contact For data protection questions or to request a signed copy of this agreement, use our [contact form](https://harnesslink.sh/contact). --- Source: https://harnesslink.sh/docs/usage # Using HarnessLink HarnessLink is the controller for your coding agents — it routes their model calls, gives them shared memory, banks what they do, and syncs and restores your setup. You code in omp, Claude Code, Codex or pi. HarnessLink was called SuperPi until October 2026; the command is still `superpi` (see RENAME.md). Each of those programs is a **harness**: it runs a model in a loop with tools. The installer adds **omp** (upstream oh-my-pi); Claude Code, Codex, pi and Antigravity work too. `superpi` itself runs no model and no coding session: it signs you in, runs a local service beside your harnesses, syncs what they produce and serves it back as search, recall and briefs. Plain `superpi` shows the home screen — the service (running, version), sign-in, sync health, autobank per harness, what each harness is wired to (gateway, transcripts, autobank, context, memory tools) and the one next thing to do. On a machine that is not set up yet it runs `superpi cloud setup` instead. Without a terminal it prints the same as plain text. Setup is in INSTALL.md. ## Ask — search your own work **Dashboard → Ask.** A conversation over everything you have synced — memory entries, prompts and session records — and HarnessLink's own guides. ``` what did we decide about autobank backfill? → and when was that agreed? how do I restore HarnessLink on a new machine? ``` **What happens when you ask.** 1. A small, fast model pulls the keywords out of your question (and resolves a follow-up such as "and when was that?" against the thread). They are shown under your question as *Searched for*. Your own words are still searched, at lower weight, so a missed keyword cannot hide a result. 2. Memory entries, prompts, session titles, the guides (this file, `INSTALL.md`, `MEMORY_BANKING.md`, `MULTI_HARNESS.md`) and the semantic index are searched at once. 3. Sources are ranked so that what *answers* beats what *asked*: a bank entry's result or a guide section outranks the prompt that requested the work, and a prompt whose banked turn is already a source is dropped. Temporary-folder entries, generated indexes and daily summaries are never sources. 4. The sources appear straight away, each with a link to the exact place — the memory entry, the prompt inside its session, or the guide section — and the answer streams in under them. **Answers are grounded.** The answering model uses only the sources, cites them as `[n]` (click one to jump to it), never expands an acronym the sources do not expand, and treats a prompt as a request, not an outcome. When the sources do not answer the question it says "I couldn't find this in your synced work or the HarnessLink guides." and shows that as a notice rather than an answer. Citations pointing outside the source list are discarded. **Filters** narrow before the search runs: kind (memory / prompt / session / guides), project, and a date range. A project or date filter leaves the guides out. **Details of sources** opens the full evidence: one card per source, cited entries marked. Check the answer against them — that is what they are for. ### Keeping the index current The semantic index embeds new memory entries (bank entries first), sessions and prompts every hour by itself, on plans with semantic search. **Rebuild index** runs a pass now. Until an entry is embedded it is still found by its words. Typical timings: sources in about 2–3 seconds, the first words of the answer about a second later, the whole answer in under 7 seconds. ## History — every prompt, from every harness **Dashboard → History.** Every prompt you typed, newest first. Each row has a badge naming the harness it was typed into (`omp`, `claude-code`, `codex`, `pi`, `antigravity`, and `superpi` for prompts from HarnessLink's old built-in agent); click the badge, or a name in the **Harnesses** panel, to show only that harness. The HarnessLink service reads new prompts from each harness with capture on about every 30 seconds and uploads queued rows every 5–10 seconds, so a prompt usually appears within a minute. `superpi cloud sync` does both now. Cursor prompts are not captured. ## Policies — rules for your organization **Dashboard → Policies.** Write the rules your organization wants its harnesses to follow. Tool and command rules are enforced before every tool call in Claude Code, Codex and omp (see [Org policy — enforced before every tool call](https://harnesslink.sh/docs/usage#org-policy--enforced-before-every-tool-call)); pi, Cursor and Antigravity have no HarnessLink tool hook. Each rule is **effect + target + optional conditions**. | Effect | Meaning | | --- | --- | | Explicit deny | Blocked, always | | Explicit prompt | Always ask first | | Explicit allow | Outranks a lower-precedence deny or prompt; never auto-approves | | Conditional deny / prompt / allow | The same, only when conditions match | Explicit beats conditional; within each, **deny > prompt > allow**. **Targets** are a tool (`bash`, `write`, `edit`, `computer`), a shell pattern (`rm -rf *`), or a model (`claude-opus-*`, `anthropic/*`). **Conditions** are `cwd_prefix` and `model` for tools and commands, and `harness` (`claude-code`, `codex`, `omp`, `pi`, `antigravity`, `other`) for models. A model rule only allows or denies: once any allow applies to you, models no allow matches are refused. **Usage limits** (Policies → Usage limits) cap spend in USD or tokens (input, output, cache reads and cache writes) per UTC day or UTC month, either per machine or per person across all their machines, optionally for matching models only. USD is HarnessLink's estimate from list prices, not your provider's bill. A per-person limit counts a person's other machines once they sync, usually within about a minute. Model rules and limits are enforced by HarnessLink 17.5.50 and later, in the local gateway, before a model call leaves the machine: every call from Claude Code and Codex, and calls through the Anthropic and OpenAI Codex providers in omp and pi, once `superpi gateway connect` has routed them. Cursor, Antigravity and other providers go direct and are not covered. A refused call gets a 403 from the gateway naming the rule or limit, your organisation and the Policies page; for a limit it also says how much is used, of how much, and when the window resets (UTC midnight, or the first of the month). Limits are checked before each call: a response that starts under a limit finishes even if it goes over, and the next call is refused. If the policy file on a machine cannot be read, model calls are refused until the HarnessLink service rewrites it; on a machine that has never fetched a policy, nothing is enforced. `superpi` and `superpi cloud status` show each limit with its current usage. ``` Explicit deny command rm -rf * Explicit deny command terraform apply * Conditional prompt tool bash when cwd_prefix=/Users/you/Workspace Conditional allow tool read when cwd_prefix=/Users/you/Workspace ``` ## Memory **Dashboard → Memory.** What your harnesses' sessions left behind, with full-text search and dropdown filters for project (by folder name), harness, type, machine and time; the filters live in the page address, so links and Back work. Each row shows the entry's title. Temporary folders (`/tmp`, the OS temp dir) and generated files (each project's `MAIN.md` index and daily summaries) are hidden unless you ask for them. Click an entry to read it; its file and folder paths are under **Details**. Turns run in a temporary folder are not banked at all. What syncs, once setup has run (all through the `memories` sync category): - **HarnessLink's memory tree** (`~/.superpi/agent/memories`): bank entries, `MAIN.md`, daily summaries and `state/` snapshots — see MEMORY_BANKING.md. - **Each captured harness's own memory files**, in place, about every 5 minutes and on `superpi cloud sync`: Claude Code `CLAUDE.md` (global and per project) and auto memory; Codex `AGENTS.md`, `AGENTS.override.md` and `~/.codex/memories/`; omp and pi `AGENTS.md` and `memories/`; Antigravity `GEMINI.md`, rules, knowledge and brain artifacts; Cursor `~/.cursorrules`. A file whose project is known is filed under that project (`harness//…`); the rest go to a project named after the harness. Only `.md` files up to 1 MiB. Every file is redacted client-side before upload, and an unredactable file is skipped rather than sent. ### Importing older memory ```bash superpi cloud import-memories # preview superpi cloud import-memories --apply # write (setup runs this once for you) ``` Reconstructs documents from a MemPalace store and `~/.hermes` (`MEMORY.md`, `SOUL.md`, `USER.md`) into the normal memory tree, with a provenance header recording where each came from. They then sync like any other memory. Each machine files its imports under its own `machine-/` folder, so two machines with the same home path (two servers as `ubuntu`) keep separate copies instead of replacing each other's. Imports from earlier releases are moved into that folder when their content matches; anything else is left where it is. Idempotent — re-running rewrites nothing unchanged. Live harness memory such as `CLAUDE.md` is not imported: it already syncs in place. ### Recall — ask before you re-derive ```bash superpi cloud recall "rate limit" # this folder's project + linked projects superpi cloud recall "rate limit" --all # every project you own superpi cloud recall "rate limit" --project= ``` Full-text search over your banked memory. Every finished turn in each harness with autobank on (omp, pi, Claude Code, Codex; Antigravity per conversation) becomes a bank entry automatically (`memory.autoBank`, default on; subagent turns are not banked), so the outcome of past investigations is one query away — far cheaper than an agent re-deriving it. Entries banked by HarnessLink's old built-in agent stay searchable. `superpi cloud bank --title=… [--tags=…]` records something by hand; `superpi cloud link-memory --project=` makes another project's memory part of this folder's default recall scope. ### Context brief — seed a session instead of replaying one ```bash superpi cloud brief # print to stdout superpi cloud brief --budget=6000 --out=brief.md superpi cloud brief --recall="deploy freeze" # add a recall section (local index, no network) ``` A deterministic, budgeted summary of the current folder built from memory, not transcripts: the human-written part of `MAIN.md`, the newest ten bank entries, the harness's own memory files (omp's `raw_memories.md` and newest rollout summary — folders worked in upstream omp carry context there and may have no bank at all), and an optional recall section. Sections are kept whole or dropped, with a note naming what was dropped, so the brief never exceeds `--budget` characters (default 8 000). Paste it into a fresh session in any harness. Re-establishing context is the largest token cost in agent work; a brief costs a few hundred tokens where replaying the transcript it stands in for can cost millions. ### The local index — memory search without the network The HarnessLink service keeps a SQLite full-text index of this machine's memory tree at `~/.superpi/agent/memory-index.db`. `memory_search`, `memory_get`, `context_brief`'s recall and the context hooks read it first, so they answer offline, in milliseconds, at no cost. - **What is indexed:** every `.md` file under `~/.superpi/agent/memories`. A bank entry is split the way the dashboard's Ask reads it — title, tags, `## Prompt`, the `## Actions` step log (one line per tool call) and `## Result` — and ranked so a match in the Result counts most, then the step log, then the prompt. Words match across inflections ("permissions" finds "permission"). Each project's generated `MAIN.md` index and daily summaries are kept out of results, as on the dashboard. - **How it stays current:** one pass when the service starts (files whose size and modification time are unchanged are not read again), then the service's file watcher applies each add, edit, rename and delete as it happens, and a full check every 5 minutes catches anything it missed. Without the service, `superpi mcp`, the hooks and `superpi cloud brief` bring the index up to date for the projects they are about to search before searching. - **Cost:** on 2,533 memory files (15 MB) the first build took about 0.5 s and the index is 12 MB; a later service start checks every file in about 30 ms. A search takes 1–6 ms. - **Other machines:** `memory_search` also asks the cloud, for entries from your other machines and linked projects, and waits for it at most 1.5 s. When the cloud doesn't answer in time, you're offline or not signed in, you get this machine's results and one line saying so. The file is a cache. Deleting it is safe: it is rebuilt from the memory files, and an unreadable one is rebuilt automatically. ## Resuming sessions across harnesses ```bash superpi resume ``` One picker over every session on the machine that a harness can resume natively (Claude Code, Codex, pi and omp; Antigravity and Cursor transcripts are not offered, since no harness can open them), plus sessions left by HarnessLink's old built-in agent — newest first, each row ending with its replay cost. Resuming does not re-send the file: the harness rebuilds the model context, which compaction keeps bounded, so the cost shown is the context the provider actually saw on the session's last request — read from the transcript's own last usage record (`~69k tok`). A transcript with no usage record shows a bytes-based ceiling instead (`≤425k tok`). Measured live, the byte heuristic alone overstated a 17 MB session by 63×. Pick a session, then pick where to open it: omp is preselected for omp-format sessions (including the old HarnessLink agent's), claude/codex for their own. Handoff **copies** the session file into the target harness's store — never moves or overwrites it — then launches the harness's native resume. Cross- family conversion is refused rather than approximated: a claude-code transcript is not an omp session file. At **50 000 tokens and above** the harness picker gains a fifth option: *brief — seed a fresh session from project memory instead of replaying ~N tokens*. It runs `superpi cloud brief` in the session's folder and works for any family, because it is built from the folder's memory rather than the transcript. The native resume stays the default; the cheaper path is simply visible at the moment the cost is being paid. ## Profile sync — moving machines ```bash superpi cloud push-profile # snapshot this machine now (the HarnessLink service also does it every 5 minutes when something changed) superpi cloud push-profile --dry-run # print exactly what would be uploaded; uploads nothing superpi cloud restore # show what this machine would get superpi cloud restore --apply # write it (config.yml is backed up first) superpi cloud restore --approve-mcp # approve restored MCP servers left pending ``` The **device profile** holds HarnessLink's own `config.yml`, the MCP servers its hub runs and the skills and agents the old built-in agent left in its own folder — and the **setup of every harness installed here** (including skills `superpi add` put there), Markdown files only: | Harness | What travels | | --- | --- | | Claude Code (`~/.claude`) | `agents/`, `commands/`, `rules/`, `output-styles/`, `skills/`, `CLAUDE.md` | | Codex (`~/.codex`) | `prompts/`, `skills/`, `AGENTS.md` | | omp (`~/.omp/agent`), pi (`~/.pi/agent`) | `agents/`, `commands/`, `rules/`, `prompts/`, `skills/`, `AGENTS.md`, `SYSTEM.md` | Skill scripts, extensions and anything else that could run are never captured. Each file is redacted and capped at 32 KiB, and the whole profile stays under 1 MiB (instruction files first, skills last; anything left out is counted). Harness config files (`settings.json`, `config.toml`, `config.yml`, `models.yml` …) are listed by **key name only** and never restored — `superpi cloud setup` redoes the wiring instead. `restore` reads the newest profile pushed by **another** device unless you name one with `--device `. Harness files are restored additively: a missing file is created, an existing one is never overwritten, and a harness not installed on this machine is skipped with a note to install it and re-run. **Secret values are never uploaded.** MCP `env`/`headers` entries are reduced to their key *names*, so restore tells you which secrets to re-supply and cannot supply them itself. Syncing credentials would put a fleet-wide secret store behind one web session. **Restored MCP servers stay off until you approve them.** Nothing from the cloud runs on this machine without your consent: every MCP server a restore adds is written with `"enabled": false` and recorded in `~/.superpi/agent/mcp-pending.json`. `restore --apply` then shows each one with the command or URL it would run and asks `Approve? [y/N]`; without a terminal nothing is approved. `--approve-mcp` approves them all without asking — with `--apply` for this restore, alone for what an earlier restore left pending. An organization can pre-approve servers in its policy bundle with `"mcp": { "allow": ["uvx", "https://mcp.example.com/sse"] }`: entries match the exact command or URL, never the server name (the name is chosen by whoever pushed the profile). `superpi cloud setup` restores the harness files (additively) but never `config.yml` or MCP servers — run `superpi cloud restore --apply` for those. **Machine-bound servers stay disabled even when approved.** A restored stdio server whose command is an absolute path that does not exist on this machine (typically `/Users//…/some-mcp`) keeps `"enabled": false`, and the apply report lists it with the re-enable instruction. A config that fails on every session start is worse than one that says why it is off. Servers that need a per-machine credential (an http MCP answering 401) still surface at connect time; the report names the secrets they need. ## Templates — the registry ```bash superpi registry search intent superpi add intent-discovery # shows where it will write, then asks; --yes skips superpi add intent-discovery --harness claude-code # one harness only superpi add --list # what HarnessLink installed, and which harness reads it superpi remove intent-discovery # removes only what HarnessLink wrote ``` **Dashboard → Templates** lists reusable skills and agents. `superpi add ` copies each skill into the user-level skill folder of every harness enabled in `cloud.harnesses` or detected on this machine (its folder exists or its CLI is on `PATH`), so the harness loads it in its next session: | Harness | Skill folder | Source | | --- | --- | --- | | Codex | `~/.agents/skills//` | [Codex: Build skills](https://developers.openai.com/codex/skills) | | Claude Code | `~/.claude/skills//` | [Claude Code: Skills](https://code.claude.com/docs/en/skills) | | omp | `~/.omp/agent/skills//` | [omp config-usage](https://github.com/can1357/oh-my-pi/blob/main/docs/config-usage.md) | | pi | `~/.pi/agent/skills//`, also reads `~/.agents/skills/` | [pi: Skills](https://github.com/badlogic/pi-mono/blob/main/packages/coding-agent/docs/skills.md) | | Antigravity CLI | `~/.gemini/antigravity-cli/skills//` | [Antigravity: Agent skills](https://antigravity.google/docs/skills) | | Cursor | `~/.cursor/skills//`, also reads `~/.agents/skills/`, `~/.claude/skills/`, `~/.codex/skills/` | [Cursor: Agent Skills](https://cursor.com/docs/skills) | A harness that also reads a folder another harness's copy goes to (pi and Cursor read `~/.agents/skills/`; Cursor reads `~/.claude/skills/`) uses that copy instead of getting a duplicate it would load twice. Agent definitions (`agents/*.md`) go to omp only (`~/.omp/agent/agents/`); when omp is not enabled or detected they are listed as skipped, never dropped silently. HarnessLink records every path it writes in `~/.superpi/agent/addons.json`. A skill folder of the same name that HarnessLink did not write is yours: `add` skips that harness and says so (exit code 1), even with `--force`. Running `add` again is a no-op when nothing changed and updates HarnessLink's own copy when the registry has a newer one; a copy you edited is left alone unless you pass `--force`. `superpi remove ` deletes only the files HarnessLink wrote, unedited (or with `--force`), keeps anything you added to the folder, and keeps a folder another installed item still uses. The **AI-native SDLC pack** brings the intent → spec → plan artifact chain to every project: | Skill | Stage | Produces | | --- | --- | --- | | `intent-discovery` | Plan | `intent/-.intent.md` — interview the originator to completion; `intent/` is the backlog | | `spec-from-intent` | Design | `spec/.spec.md` — requirements traced to the intent, org instructions honoured by construction | | `plan-from-spec` | Build | `plan/.plan.md` — files, ordered/parallel steps, blast-radius interrogation, proof per step; implementable with no other context | | `maintenance-intent` | Maintain | a diagnosed intent from an alert, log or ticket — evidence quoted, suggestions never actions | Slugs match across the three folders so a chain is greppable end to end, and the committed/done stages bank to memory — the chain plus recall is the project's institutional record. **superpi** (`superpi add superpi`) is the cross-harness playbook. It teaches the agent in any harness — Claude Code, codex, omp, or a plain shell — to reach cloud recall and briefs, find and resume where a session stopped (`superpi sessions list --json`), and sync on demand (`superpi cloud sync --json`). ### Extensions — code that runs inside omp ```bash superpi add context-compress # asks for consent; --yes skips ``` Registry items of kind **extension** install into omp's own extension directory (`~/.omp/agent/extensions/`), because they are code the harness executes, not prose; no other harness runs omp extensions, so without omp they are reported as skipped. Only the official registry and your org's shared artifacts can supply them; third-party `@alias` sources are refused. **context-compress** keeps large tool outputs out of the model's context. On omp's `tool_result` hook, any `bash`/`eval`/`grep`/`glob`/MCP output over 8 KB is replaced by its first 40 lines, last 20 lines, every line that looks like an error or warning, and a marker: ``` …3943 lines omitted (18.3 KB) — call retrieve_output({"id":""}) for the full output ``` The original is written to `~/.superpi/agent/outputs/.txt` (0600, pruned after 14 days) and a `retrieve_output` tool returns it, or a line range of it, on demand. `read`, `edit` and `write` results are never touched — hashline anchors and diffs are what the agent edits against. The compression is a pure function of the output, applied once when the result arrives, so the provider's prompt cache stays valid. Measured on real sessions, tool results are about half of billable context and the largest 6% of them carry half of those bytes; expect a 10–20% reduction in input-side spend. Live: a 4 000-line `seq` entered context as 335 characters and the model retrieved lines 2000–2002 exactly. ### qmd — local search over your memories ```bash superpi add qmd # shows the plan, then asks once; --yes skips (required without a terminal) superpi add --list # qmd's binary, collection, models and MCP entries superpi remove qmd # removes only the MCP entries and the collection HarnessLink set up ``` [qmd](https://github.com/tobi/qmd) is a local search engine for Markdown: BM25 keywords, vector search and LLM reranking, all on this machine with GGUF models. `superpi add qmd`: 1. installs qmd with `bun install -g @tobilu/qmd` when `qmd` is not on `PATH` (qmd needs Node.js 22 or newer); 2. creates the qmd collection `harnesslink-memories` over `~/.superpi/agent/memories` (`**/*.md`) with a context that tells search what the entries are; re-running updates it, never adds a second one; 3. registers qmd's stdio MCP server (`qmd mcp`, server name `qmd`) in every enabled or detected harness HarnessLink writes MCP config for: omp (`~/.omp/agent/mcp.json`), Cursor (`~/.cursor/mcp.json`), Codex (`[mcp_servers.qmd]` in `~/.codex/config.toml`) and Claude Code (`claude mcp add --scope user qmd -- qmd mcp`; skipped when the `claude` CLI is not on `PATH`); 4. downloads qmd's three models with `qmd pull` and runs the first `qmd embed`: about 2.3 GB (embedding 334 MB, reranker 639 MB, query expansion 1.3 GB) into `~/.cache/qmd/models`. The confirmation states the size before anything is downloaded. A `qmd` MCP entry you added yourself is never overwritten or removed (the harness is listed as skipped, exit code 1); the same rule as skills, recorded in `~/.superpi/agent/addons.json`. `superpi remove qmd` leaves qmd itself, its models and your own collections in place (`bun remove -g @tobilu/qmd` uninstalls qmd). **Freshness.** While the add-on is installed, the HarnessLink service runs `qmd update` 30 seconds after memories stop changing (and once at service start), so new entries are found by keyword search within a minute. It does not embed in the background: run `qmd embed` now and then to add vectors for new entries. `qmd update` re-indexes every collection and runs each collection's update command, so when one of your collections has one (`qmd collection update-cmd`, e.g. `git pull`) the service does not run it and says so in its log; run `qmd update` yourself. ## Delegation — one harness hands a task to another ```bash superpi run --harness codex "why does the build fail?" # headless, in this directory superpi run --harness claude-code --cwd ~/src/api --timeout 5m "…" # another directory, stopped after 5 min cat task.md | superpi run --harness omp --json # task on stdin, result as JSON ``` `superpi run` runs the harness headless, streams what it does, and ends with its status, exit code and a summary; the command exits with the harness's exit code. Inside any harness, the `delegate` MCP tool does the same: `{harness, task, cwd?, timeout_s?, model?}` → `{harness, status, exit_code, summary, transcript_ref, run_id}`. A call waits about 25 s, under the 30 s MCP timeout of omp and others; a longer run comes back as `status: "running"` with its `run_id`, and `delegate_status {run_id}` waits again for the result (`cancel: true` stops it). The tools run in the calling harness's own `superpi mcp` relay, never in the HarnessLink service, so the child inherits the caller's environment and goes away with the caller's session. **How each harness is run.** No permission-bypass flag is ever passed (`--dangerously-skip-permissions`, `--yolo`, `--full-auto`, `--auto-approve`, `--dangerously-bypass-hook-trust`, …), and terminal wrapper shims on PATH (cmux's) are skipped because they add such flags. Each harness keeps its own default non-interactive permissions: | Harness | Invocation | What a delegated run may do | HarnessLink hooks in the headless run | | --- | --- | --- | --- | | Claude Code | `claude -p --output-format stream-json --verbose [--model=]`, task on stdin | Starts in Claude Code's built-in mode for `-p` (`default`, or `auto` where feature flags aren't fetched, as behind the gateway) unless your settings set `defaultMode`. Anything that would prompt is denied, and the summary lists the refused tools. | Yes: `-p` loads `~/.claude/settings.json` hooks (no `--bare`); org policy "prompt" rules become asks nobody answers, so they're denied. | | Codex | `codex exec --json [--model=] -`, task on stdin | Read-only sandbox, no approvals: it reads and answers, edits are refused. Refuses to start outside a git repository (no `--skip-git-repo-check`). | Only if you trusted HarnessLink's hooks in Codex's `/hooks`; untrusted hooks are skipped and no bypass is passed. | | omp | `omp -p --mode json [--model=]`, task on stdin | Your `tools.approvalMode` (omp's default lets tools run). | Yes: the `superpi-context.ts` extension loads in print mode; "prompt" rules block (no UI). | | pi | `pi -p --mode json [--model=] ` | pi asks before nothing; untrusted project files (extensions, settings) are skipped headless. | None: HarnessLink installs no pi hook. | | Antigravity | `agy --output-format stream-json [--model=] -p=` | `request-review`: anything that needs permission (shell commands, for example) is auto-denied; allow it with a `permissions.allow` rule in Antigravity's settings. | None: Antigravity has no documented hook. | The gateway is wired in each harness's own config (`superpi gateway connect`), so a delegated Claude Code, Codex, omp or pi run goes through it and its model rules and usage limits like any session. A harness that isn't installed is refused with ` is not installed (no on PATH); skipped.` **Limits.** - Depth: the child gets `SUPERPI_DELEGATION_DEPTH` = caller's + 1; a session at depth 2 may not delegate. A harness that strips the env from its tools (Codex gives MCP servers a minimal one) doesn't escape it: a caller whose ancestor process is a running delegated harness counts from that run. - 3 delegations at a time per machine, across every session. - Every run has a timeout (15 min by default, at most 4 h). On timeout or cancel (Ctrl-C, `cancel: true`, the calling session ending), the harness's whole process tree gets SIGTERM, then SIGKILL after 5 s. - `cwd` must exist. `superpi run` stays in the current directory unless you pass `--cwd`, which may name any existing directory. The `delegate` tool only accepts a `cwd` inside the caller's project root (its git top level). **Runs and memory.** The child runs with `SUPERPI_RUN_ID`, `SUPERPI_PHASE` = `delegate-` and `SUPERPI_ROSTER`, so it shows on the Runs page: in the caller's run when the caller has a `SUPERPI_RUN_ID`, else in the calling Claude Code or Codex session's own run (`-`, the id subagent runs use, with the caller linked as phase `main`), else in a run named after the delegation. A finished run is banked at once as one memory entry tagged `delegated`, with the delegated prompt and its result, through the autobank's parsers and claim store (the service never banks it a second time); `transcript_ref` is its `{project, rel_path}` for `memory_get`. It follows `memory.autoBank` and `superpi cloud autobank` like any session. A failed, timed-out or cancelled run banks nothing; so does a run that exits 0 without an answer (Antigravity does when its permissions refused every step), which is reported as `failed`. Each run's record and raw output stay in `~/.superpi/agent/delegations/` for 7 days. ## Runs — watch a software factory from outside ```bash export SUPERPI_RUN_ID=feature-42 SUPERPI_PHASE=build SUPERPI_ROSTER=cheap claude # or codex, omp — this session joins run feature-42 superpi cloud runs # runs, phases, tokens, cost ``` **Dashboard → Runs.** Sessions that carry a run id are grouped into runs: one row per run with its roster, harnesses, session count, tokens and cost, and a phase strip in start order (`plan → build → test → review`). Expand a run to see each phase's session. Every phase, tool call and response is already in the synced transcript, so the run view is the trace the factory pattern asks you to read instead of reaching into the box. A session joins a run in one of two ways. Neither needs a command. **1. A run in the environment.** Set `SUPERPI_RUN_ID` (letters, digits, `.`, `_`, `-`; up to 64), and optionally `SUPERPI_PHASE` and `SUPERPI_ROSTER` (lowercase letters, digits, `-`; up to 32), before you start the harness. Invalid values are ignored. - **Claude Code, Codex, omp:** HarnessLink's context hook sees the variables when the session starts or you send a prompt, and records them for that session in `~/.superpi/agent/run-links.db`. The HarnessLink service stamps the run on the session's next upload (within about 5 minutes) and on its subagents'. A session uploaded before the link existed is sent again so it joins the run. This needs the context hooks (`superpi harness context`; Codex runs a new hook only after you trust it once in `/hooks`), transcript sync for that harness, and the `sessions` sync category. A session started before the hooks were installed is not linked. - **pi, Antigravity and Cursor** have no context hook, so environment runs do not apply to them. **2. Subagents.** A session that started subagents forms a run with them automatically: run id `-`, phase `main` for the parent and the subagent's name for each child (omp and pi: the subagent file name; Codex: the agent role; Claude Code: `subagent`). This works for omp, pi, Claude Code and Codex. Subagent transcripts upload as sessions of their own but stay out of `superpi resume` and session lists. An environment run wins over subagent grouping and also covers the subagents, even when the session already reached the cloud inside its subagent run. Tokens and cost per session are computed server-side from the transcript's own usage records, for omp and Claude Code transcripts alike. ### Run tokens — the credential boundary ```bash export SUPERPI_CLOUD_TOKEN=$(superpi cloud run-token --run=feature-42 --ttl=2h) superpi cloud run-token --run=feature-42 --revoke # at teardown ``` A run token is a short-lived child of your device token: `sync:write` only by default, never broader than its parent, at most 24 hours, invalid the moment its parent is revoked, and unable to mint children of its own. Hand it to a sandbox and the box can stream traces up but cannot read your memory, sessions or profile. The token is also the run's **identity**: every session uploaded with it is stamped with that run id server-side, whatever the client says. A sandboxed Claude Code or Codex needs no environment plumbing to be attributed — the credential does it. One level of nesting, enforced by credentials rather than by trust. ## Cost **Dashboard → Overview** shows month-to-date spend by model. **Usage** is the analytical view: time series, per-model breakdown, gateway savings. Both read your harnesses' model calls through the HarnessLink gateway, plus any usage the old built-in agent recorded. `$/Mtok` is **blended** across input, output and cache tokens. A headline input price is misleading when cache writes dominate, which they often do. The **Cache savings** card shows how much of your context is served from the provider's prompt cache: hit rate (cache reads ÷ (cache reads + fresh input)), the cached-token count, and a tokens-weighted *≈N× cheaper than uncached* estimate — cache reads bill at roughly a tenth of fresh input, so `N = (input + cache) ÷ (input + 0.1 × cache)`. It is labelled an estimate and uses no per-model price table; it is hidden until cache data exists. Costs reported from your machine (the gateway's catalog estimates, and the old built-in agent's own figures) are cross-checked against a server-side rate card. Where they disagree, both are shown — the divergence is the signal. A model with no list price on file is marked **unverified** rather than being given a fabricated rate. A weekly email flags specific, actionable findings — cache writes that never get read, spend concentrated on one model, prompt caching left unexploited, run-rate spikes. Each cites the numbers that triggered it. Findings are throttled per issue, so a standing one stays quiet for 28 days. ## Harnesses — installing and updating HarnessLink accompanies any of the supported coding-agent harnesses. Use `superpi harness` to see what is installed on the current machine and to install additional ones. ```bash superpi harness list # table: id, binary state, real path, capture, install hint superpi harness install # install a harness via bun install -g superpi harness install --yes # skip the confirmation prompt ``` Valid harness ids and their packages: | id | binary | npm package | | --- | --- | --- | | `omp` | `omp` | `@oh-my-pi/pi-coding-agent` | | `claude-code` | `claude` | `@anthropic-ai/claude-code` | | `codex` | `codex` | `@openai/codex` | | `gemini` | `gemini` | `@google/gemini-cli` | | `pi` | `pi` | `@mariozechner/pi-coding-agent` | | `dsh` | `dsh` | `@deepseek-ai/dsh` | ### Binary state column - **installed vX.Y.Z** — binary found, realpath is a genuine install. - **shim (cmux)** — `which ` resolves to a PATH shim managed by cmux-cli (usually under the OS temp directory). The harness is not actually installed here; select `install` to install it properly. - **missing** — binary not found in PATH. The `update` picker (`superpi update`) also shows shim and missing harnesses and lets you install them in one step. ### Capture state is separate The **capture** column shows whether HarnessLink's cloud sync is reading this harness's sessions, memory and prompt history. That is managed independently: ```bash superpi cloud harnesses # list capture state superpi cloud harnesses enable # turn on cloud sync for a harness superpi cloud harnesses disable # turn it off ``` Autobank (the memory bank of finished turns) is a separate switch per harness, because it works locally and does not depend on cloud sync: ```bash superpi cloud autobank # status: per harness on/off, turns banked, today, last banked superpi cloud autobank enable # turn it on; banks that harness's last 30 days right away superpi cloud autobank disable # stop banking (existing entries stay) superpi cloud autobank backfill [--days=N] [id…] # re-scan the last N days (default 30); never banks a turn twice ``` Installing a harness with `superpi harness install` turns on neither. Run `superpi cloud setup` again, or the commands above. The HarnessLink service picks up a harness turned on after it started, without a restart. ### Installing at setup time Pass `--with=` to the installer to install harnesses alongside omp: ```bash curl -fsSL https://harnesslink.sh/install.sh | bash -s -- --with=claude-code,codex ``` The installer verifies the registry's `bin` field before running `bun install -g `, and `--yes` is implied by `--with` (consent is given by including the flag). ## Command reference ```bash # Home and housekeeping superpi # home screen: service, sign-in, sync, each harness's wiring, next step (first run: cloud setup; plain text when not a terminal) superpi cleanup # remove what the old built-in agent left (git worktrees in ~/.superpi/wt, background-job logs in ~/.superpi/run/daemons), with consent; never silently drops uncommitted work # Setup and the HarnessLink service superpi cloud setup # the onboarding: plan → sign-in (required) → sync, service, every harness, restore, verify superpi gateway start # install the HarnessLink service (launchd / systemd --user / logon task) and start it; restarts an older build superpi gateway service install|uninstall|restart|status # manage that supervised service directly superpi gateway status # gateway health, harness wiring, today's requests and savings, cloud sync health superpi gateway connect [id] # route a harness's model calls through the gateway (all detected when omitted; starts the service) superpi gateway disconnect [id] # put back the harness's own provider settings superpi gateway run [--port=] # the gateway alone, in this terminal (debugging) superpi daemon install|uninstall # same as gateway service install|uninstall superpi daemon status # is the service process running, and which harnesses it captures superpi daemon start [-f] # unsupervised background copy (no auto-restart, no OS limits); -f runs it in this terminal superpi daemon stop # stop the running service process # Harnesses superpi harness list # binary state, path, capture, install hint superpi harness install [--yes] superpi harness select [id] [--enable|--disable] [--hook] [--all] # capture on/off and MCP registration, interactive without flags superpi harness hook [id] # register HarnessLink's MCP memory tools (every installed harness when omitted) superpi harness context [id] [--remove] # context hooks for Claude Code, Codex and omp superpi cloud harnesses [enable|disable ] # transcript and prompt-history capture per harness # Cloud account and sync superpi cloud login [--url=] [--token] # link this machine (turns cloud sync on); --token reads a dashboard-minted spk_ token from stdin superpi cloud status # sync on/off, every sync category on/off, token, API base, per-store pending / failed / last success superpi cloud sync [--json] [--retry-dead] # ingest harness prompt history, then upload everything pending now; --retry-dead requeues failed rows first superpi cloud sync --disable # stop one category (history|sessions|memories|usage|gatewayUsage|profile); its queued rows are discarded superpi cloud sync --enable # turn it back on (from now; nothing typed meanwhile is backfilled) superpi cloud logout # unlink and stop capturing superpi cloud backfill [--force] # Moving machines superpi cloud push-profile [--dry-run] # snapshot machine setup (HarnessLink's and every harness's); --dry-run prints it superpi cloud restore [--device=] [--apply] [--approve-mcp] [--install-tools] [--yes] superpi cloud pull-sessions [--all] superpi cloud pull-history superpi cloud pull-memories [--all] superpi cloud adopt [--from=] # map another machine's folder to this one # Memory superpi cloud autobank [status|enable |disable |backfill [--days=N] [id…]] [--json] # memory bank of every harness's finished turns superpi cloud import-memories [--apply] [--gateway=] # MemPalace and ~/.hermes (setup runs it once) superpi cloud recall [--project=|--all] superpi cloud brief [--budget=] [--recall=] [--out=] superpi cloud bank --title= [--tags=a,b] [--body=] superpi cloud link-memory --project= # Sharing, runs, sessions superpi cloud share | shared | pull-shared [--yes] # org-shared artifacts (Team and Enterprise plans) superpi cloud runs [--limit=] # runs: phases, tokens, cost superpi cloud run-token --run= [--ttl=2h] [--scopes=sync:write] [--revoke] superpi sessions list [--project=] [--limit=] [--json] # sessions from every harness on this machine (read-only) superpi sessions search [--project=] [--limit=] [--json] superpi resume # cross-harness session picker superpi run --harness [--cwd ] [--timeout ] [--model ] [--json] "" # hand a task to another harness, headless (see Delegation) # Updates, templates, MCP superpi update [--check] [--force] # harness picker: omp, HarnessLink itself, claude, codex, …; offers to clean up ~/.superpi/wt superpi add [--harness ] [--yes] [--force] # install a registry skill into every enabled or detected harness's skill folder (agents, extensions: omp only) superpi add --list # what HarnessLink installed, per harness superpi add qmd [--harness ] [--yes] [--force] # qmd: local BM25 + vector search over your memories, as an MCP server in each harness (downloads ~2.3 GB of models) superpi remove [--yes] [--force] # remove only what `superpi add` wrote superpi registry search|list|sources|add-source # browse registries, add a third-party source (`add` is an alias of `registry`) superpi mcp [--cwd=] [--harness=] # what a harness runs: relay into the per-machine MCP hub superpi mcp register [--harness=omp,claude-code,codex] [--yes] # wire into harnesses superpi mcp register --status # show registration status superpi mcp print [--harness=] [--format=json|toml] # print the MCP entry for any client superpi context-hook # what a harness's context hook runs (reads hook JSON on stdin); installed by `superpi harness context` # Other superpi kb search|ingest|status … # alias `knowledge`: a separate semantic knowledge base in your own Cloudflare account (Workers AI + Vectorize) superpi telegram link|status|unlink # link a Telegram chat to your cloud account to ask about your memory and sessions from it superpi completions bash|zsh|fish # print a shell completion script # Root flags superpi --help | --version superpi --smoke-test # load every command and exercise the gateway and the MCP relay end to end superpi --profile # run against a named profile instead of the default ``` Commands that belonged to HarnessLink's old built-in agent are gone: launching a coding session, any first argument starting with `-` other than the root flags above (`-p`, `--model` …), and `acp`, `agents`, `auth-broker`, `auth-gateway`, `bench`, `browser-relay`, `cleanse`, `commit`, `compress`, `config`, `dry-balance`, `eval`, `factory`, `gallery`, `gc`, `grep`, `grievances`, `install`, `integrate`, `join`, `marketplace`, `models`, `plugin`, `provider`, `q`, `read`, `say`, `search`, `setup`, `share`, `shell`, `ssh`, `stats`, `ste`, `tiny-models`, `token`, `ttsr`, `usage`, `worktree` and `wt`. Running one prints a single line saying it was part of the old built-in agent and to use omp or your harness instead, and exits 2. ## Memory inside every harness — the MCP server Every harness registers the same command, `superpi mcp`. Wire it into a harness once and your memory is a tool the model can call directly — no manual `superpi cloud recall` round trips. **The hub.** `superpi mcp` is a small relay. It forwards the harness's JSON-RPC 2.0 stdio traffic to the **MCP hub**, one per machine, inside the HarnessLink service. The hub: - serves HarnessLink's own tools (below) plus the MCP servers in HarnessLink's own `~/.superpi/agent/mcp.json`, starting each of those servers **once** and sharing it across every session; - hides from a session the servers its harness already runs itself (`--harness=` tells the hub which harness is asking; `register` writes it for you); - serves at most **64 sessions** at a time; the 65th gets HarnessLink's own tools in-process, without the shared servers; - starts nothing while the containment watchdog is tripped (see [The gateway](https://harnesslink.sh/docs/usage#the-gateway--every-model-call-goes-through-harnesslink)). When the service is not running, `superpi mcp` serves HarnessLink's own tools in-process, so memory tools keep working. ### Tools | Tool | Description | | --- | --- | | `memory_search` | Full-text search over memory: this machine's from the local index (always, offline included), plus your other machines' from the cloud when it answers within 1.5 s; an entry held by both appears once. Default scope is this project plus its linked projects. Use `scope: "all"` only when the user asks to search globally or names something that may belong to another project. | | `memory_get` | Pull one entry's full content by `project` + `rel_path` (values come from a `memory_search` hit): from this machine when the file is here (an entry banked moments ago included), otherwise from the cloud. | | `memory_bank` | Record a durable memory for this project — a decision, an outcome, a fact. Syncs to the cloud and becomes searchable everywhere. | | `context_brief` | A budgeted brief of this project from memory (human notes, recent work, harness memory, optional recall from the local index). Use at the start of a session instead of replaying transcripts. Never waits on the network. | | `session_list` | Sessions from every harness on this machine, newest first, with whether each can be resumed here. | | `session_get` | One session by id: owning harness, transcript path, and the exact resume command. | | `cloud_sync` | Upload everything pending now (queued rows, finished sessions, memory files) and report what was pushed. | | `kb_search`, `kb_ingest` | A separate semantic knowledge base for documents and code, in **your own** Cloudflare account (`CF_API_TOKEN` / `CLOUDFLARE_API_TOKEN` and `CF_ACCOUNT_ID`). Without credentials it falls back to local embeddings. It is not your HarnessLink Cloud memory. | | `mcp_list_servers` | The downstream MCP servers the hub proxies, their status and tools. | | `delegate` | Hand a task to another harness on this machine (`claude-code`, `codex`, `omp`, `pi`, `antigravity`) and wait for its answer: `{harness, task, cwd?, timeout_s?, model?}` → `{harness, status, exit_code, summary, transcript_ref, run_id}`. Runs with that harness's default permissions, in a cwd under your project root. See [Delegation](https://harnesslink.sh/docs/usage#delegation--one-harness-hands-a-task-to-another). | | `delegate_status` | A `delegate` run that outlived the call (`status: "running"`): waits up to ~25 s and returns its result; `cancel: true` stops it. | | `recall_memory`, `record_learning`, `search_knowledge` | Aliases of `memory_search`, `memory_bank` and `kb_search`. | The hub also lists the tools of the MCP servers it proxies. **Scope semantics for `memory_search`** (the same for the local index and the cloud): - `"linked"` (default) — current project + projects listed in `//linked.txt`. Stay here unless the user asks otherwise. - `"project"` — current project only. - `"all"` — no project filter; searches everything in the account. Use when the user says "all my memory", "across projects", or names something that clearly belongs elsewhere. Signed out, `memory_search` still answers from this machine and says that other machines' memories need `superpi cloud login`. ### Register in your harnesses ```bash superpi mcp register # default: omp + any other detected harness binaries superpi mcp register --yes # non-interactive (skip confirmation prompts) superpi mcp register --harness=omp,claude-code,codex superpi mcp register --status # show what is already registered ``` Config written per harness: | Harness | File | Entry | | --- | --- | --- | | `omp` | `~/.omp/agent/mcp.json` | `mcpServers.superpi = { type: "stdio", command: "superpi", args: ["mcp", "--harness", "omp"] }` | | `claude-code` | user scope | `claude mcp add --scope user superpi -- superpi mcp --harness claude-code` | | `codex` | `~/.codex/config.toml` | `[mcp_servers.superpi]` block running `superpi mcp --harness codex` | | `cursor` | `~/.cursor/mcp.json` | same shape as `omp`, with `--harness cursor` | A preset is only shipped for a client whose config path and format we verified against that client's own documentation — today that is Cursor. Every other client still gets the canonical block: print it and paste it into that client's config under the key it documents (VS Code: `servers`, Zed: `context_servers`, OpenCode: `mcp` with `command` as one array). ```bash superpi mcp print # canonical `mcpServers` block (JSON) superpi mcp print --format toml # TOML form superpi mcp print --harness=omp # exactly what register writes for a known harness ``` The block is the only thing on stdout; the note naming where it goes is written to stderr, so `superpi mcp print | jq` and `superpi mcp print > mcp.json` stay clean. An unknown `--harness` id exits non-zero with the valid ids listed rather than falling back to the generic block. ### In the onboarding `superpi cloud setup` registers the memory tools for every detected omp, Claude Code and Codex as part of its automatic checklist ("Memory tools (MCP)" per harness; turn it off per harness under **c** customize). A failure shows the exact `superpi mcp register --harness= --yes` command to retry it. ## Context hooks — memory before the model thinks MCP tools only run when the model decides to call them. Context hooks run first, on every session and prompt, so the model starts with your memory instead of having to go looking for it. ```bash superpi harness context # install into every detected harness superpi harness context codex # one harness superpi harness context --remove # undo (only HarnessLink's entries are touched) ``` | Harness | Where | Mechanism | | --- | --- | --- | | Claude Code | `~/.claude/settings.json` | `SessionStart` + `UserPromptSubmit` + `PreToolUse` + `Stop` + `PreCompact` command hooks | | Codex | `~/.codex/hooks.json` | the same minus `Stop`; Codex runs a new hook only after you trust it once in `/hooks` | | omp | `~/.omp/agent/extensions/superpi-context.ts` | a managed extension on `before_agent_start`, `tool_call`, `agent_end` and `session_before_compact` | Each hook calls `superpi context-hook`, which injects: - **On session start:** your organization's policy instructions (the global text plus every scoped instruction whose conditions match), then the project's context brief (the same one `superpi cloud brief` prints), opened by the handoff of an unfinished task when there is one (see [Session handoff](https://harnesslink.sh/docs/usage#session-handoff--a-new-session-instead-of-compaction)). The whole injection stays under 9,500 characters for Claude Code and omp (Claude Code's cap is 10,000) and 7,000 for Codex (under its 2,500-token preview limit). - **On each prompt:** up to three bank entries whose title or tags share at least two distinctive words with the prompt, ranked by how well their full text matches it, each with the `project` and `rel_path` that `memory_get` takes. Words that appear in most of the project's entries (usually the project's own name) don't count. Nothing is injected when nothing matches. It reads the [local memory index](https://harnesslink.sh/docs/usage#the-local-index--memory-search-without-the-network) and memory files only (about 75 ms per prompt including process start). It never calls the cloud, gives up after 1.5 seconds (10 seconds at a turn's end or before a compaction, where it reads the transcript), and exits 0 on any error, so a broken or missing HarnessLink can't block the harness. Existing hooks and settings are kept, running it again changes nothing, and a settings file that isn't valid JSON is left alone and reported instead of overwritten. `superpi cloud setup` installs them for every detected harness as its "Context hooks" step. ### Org policy — enforced before every tool call The same hooks enforce the rules your org sets on the dashboard's [Policies](https://harnesslink.sh/policies) page. Before each tool call the harness asks `superpi context-hook`, which reads the policy the HarnessLink service keeps in `~/.superpi/agent/cloud-policy.json` (refreshed every minute while you're signed in, whatever your sync settings). It never calls the cloud on this path. | Rule | Claude Code | Codex | omp | | --- | --- | --- | --- | | deny (tool or command) | blocked | blocked | blocked | | prompt | you're asked | blocked (Codex hooks cannot ask) | you're asked; blocked with no UI | | allow | outranks a lower-precedence restriction; never auto-approves | same | same | Tool names on the dashboard use omp's vocabulary (`bash`, `write`, `edit`, `read`, `web_search`, `task`, …); Claude Code's `Bash`, `Write`, `Edit`, `WebSearch`, `Task` and Codex's `Bash` and `apply_patch` (counts as `edit` and `write`) map onto them, and MCP tools match by their full name. Command rules use `*` wildcards and match any part of a compound command (`cd x && rm -rf y` meets `rm -rf *`). A rule conditioned on a model applies when the harness's model is unknown, unless it is an allow. If the policy can't be fetched, the last one keeps applying, however old it is. If the cached file is unreadable, every tool call is blocked until the service rewrites it. On a machine that has never fetched a policy, nothing is enforced. pi, Cursor and Antigravity have no HarnessLink tool hook, so rules are not enforced there, and Codex's hosted web search bypasses hooks. Plain `superpi` and `superpi cloud status` show the active rules, when they were last fetched, and where they are not enforced. A refusal names the rule and links the Policies page. You don't need to reinstall after an update. When the HarnessLink service starts, it adds the hooks added since (policy, session handoff) wherever HarnessLink's context hooks are already installed, and refreshes its omp extension. It never adds hooks to a harness where you haven't installed them. Codex runs a new hook only after you trust it: until you open `/hooks` in Codex and trust HarnessLink's entries, Codex skips them, and plain `superpi` shows "run /hooks in Codex" as the next step. ### Session handoff — a new session instead of compaction A long session gets slower and dearer on every request, and compaction then squeezes it into a lossy summary. HarnessLink instead moves the task to a new session that starts from memory. **Checkpoint.** For every session the autobank keeps a task checkpoint in `state/--.md` under the project's memory, updated as the transcript grows: the goal (the session's first prompt, plus the latest request), the next step (the todo in progress, else the last assistant message), the latest tool calls, decisions (assistant and, where the transcript keeps it, reasoning sentences that state a choice), the files edited, and the todo list or plan. It is capped at 4,000 characters. Its `status` is `open`, `done` (every todo finished) or `picked_up` (a new session resumed it). **When to hand off.** The hooks read the context size from the transcript's last usage record (Claude Code, omp, pi) or Codex's `token_count`, never from a character estimate; omp reports its own. The handoff point is `context.handoffAt` in `~/.superpi/agent/config.yml`: ```yaml context: handoffAt: auto # default: half the context window or 100k tokens, whichever is smaller # handoffAt: 80000 # a token count # handoffAt: "40%" # a share of the window # handoffAt: off # never steer, never block compaction ``` The window is the one the harness states (Codex, omp), else the model's family default (Claude 200k, or 1M once a session is past 200k). | Moment | Claude Code | Codex | omp | | --- | --- | --- | --- | | A turn ends past the handoff point, task open | the model is asked to save a handoff with `memory_bank` (tag `handoff`) and tell you to start a new session (`/clear`); asked again only after the context grows by another half of the handoff point, never while a Stop hook is already continuing the turn | — | a handoff is saved and a notice tells you to start a new session (`/new`) | | Automatic compaction, context under 90% of the window | a handoff is saved and the compaction is skipped; the reason is shown | the same (`continue: false`) | the same (cancelled); an overflow recovery is never cancelled | | Automatic compaction at 90% or more, or `/compact` | a handoff is saved, then it compacts | the same | the same | Each safe point also banks the checkpoint as a bank entry tagged `handoff` (one per session, rewritten in place), so the handoff syncs to your other machines. omp's extension API cannot open a new session from a hook, so HarnessLink only tells you to. **Resuming.** When a session starts fresh (`startup`), after `/clear`, or after a compaction, the newest open checkpoint of the project (this session's own first, at most three days old) and the newest handoff note go first in the brief, under "Resume: unfinished task from an earlier session", capped at 5,000 characters and never dropped for budget. Both are then marked picked up, so the next session starts clean; a checkpoint reopens if its session does more work. Resuming a transcript (`--resume`) injects no handoff. ## The gateway — every model call goes through HarnessLink HarnessLink runs a local gateway on `127.0.0.1:4747`. Once a harness is connected, its model calls go through HarnessLink first, then to the provider. Your harness keeps its own login: HarnessLink passes the credential through and never stores provider keys. A HarnessLink Cloud account is required — without a sign-in the gateway answers every call with "HarnessLink Cloud sign-in required". ```bash superpi gateway connect # start the HarnessLink service if needed, then point every detected harness at it superpi gateway connect omp # or just one harness superpi gateway start # start the service on its own (now and at every login) superpi gateway status # service, sign-in, per-harness wiring, today's savings superpi gateway disconnect # restore direct provider access ``` | Harness | What `connect` changes | | --- | --- | | Claude Code | `env.ANTHROPIC_BASE_URL` in `~/.claude/settings.json` (your claude.ai login keeps working) | | Codex | top-level `openai_base_url` in `~/.codex/config.toml` (ChatGPT login or API key, detected from `auth.json`) | | omp | `providers.anthropic.baseUrl` and `providers.openai-codex.baseUrl` in `~/.omp/agent/models.yml` | | pi | the same two providers in `~/.pi/agent/models.json` | | Antigravity | not supported yet — signed-in Antigravity sends its traffic straight to Google | Restart a harness after connecting it. `disconnect` puts back exactly what was there before, including a base URL you had set yourself. **The service.** `superpi gateway connect` and `superpi gateway start` register `superpi daemon run` with the platform's supervisor: a LaunchAgent on macOS, a `systemd --user` unit on Linux, a logon task on Windows. Where there is no supervisor (a container, WSL without systemd) it starts the daemon in the background and says it will not survive a reboot. `connect` needs a HarnessLink Cloud sign-in and waits until the gateway answers before it changes any harness; if the service cannot start, nothing is connected. The service (`superpi daemon run`) hosts the gateway, the MCP hub, the containment watchdog, gateway-usage sync, prompt-history ingest from every harness with capture on, cloud sync and the harness transcript watcher. When it is down, connected harnesses get "connection refused" — there is no silent bypass around HarnessLink. `superpi daemon start` runs the same loop without a supervisor: no restart after a crash or reboot and no OS resource limits — use it only where `gateway start` cannot install a service. **Limits.** The daemon cannot run away, however many sessions use it. A watchdog inside it checks the daemon's child-process tree every 5 seconds; above 200 processes or 2048 MB of combined resident memory it kills that tree (never the daemon), refuses to start MCP servers for 5 minutes, and records the trip in `~/.superpi/agent/run/watchdog.json`. `superpi gateway status` shows a red line for a trip in the last 24 hours, and `/_superpi/health` reports the watchdog. The OS adds a backstop: the systemd unit sets `TasksMax=512`, `MemoryHigh=2G` and `MemoryMax=3G` (`TasksMax` counts threads — the daemon alone runs about 40 and each node-based MCP server about 12, twice that under `npx`, so 256 would cap you at about nine MCP servers). The LaunchAgent sets `NumberOfProcesses` to 4096: macOS applies that limit to every process the user owns, not just the daemon's tree, and a desktop session already runs about 500, so a tree-sized value would make every process start in the daemon fail. Windows has no OS limit (Bun cannot place the daemon in a job object); the watchdog is the bound there. **Disk.** The service writes its output to `~/.superpi/logs/daemon.log`. Past 5 MB (checked at start and hourly) it is copied to `daemon.log.1`, replacing the previous copy, and emptied in place, so the log never holds more than about 10 MB. `gateway.db` gives back the space of cache entries it drops: once more than 8 MB is free it shrinks the file. A `gateway.db` created before this was in place is rewritten once by the service when it holds more than 32 MB of free space; the service log records the size before and after, and gateway requests wait for it (about 0.7 s for a 550 MB file). **Token savings.** Two mechanisms, both reported per harness on the dashboard's Usage page under *Gateway savings*: - **Exact-match cache.** An identical model request replays the stored response without calling the provider (response header `x-superpi-gateway: hit`). Per-request identifiers that harnesses stamp on every call (Codex item ids and turn metadata, the Claude-Code billing hash, `metadata`, `prompt_cache_key`) are ignored when matching. Streams over WebSocket (Codex's default transport) and requests chained with `previous_response_id` are never cached, because they depend on server-side state. Entries live 24 hours in `gateway.db`, capped at 128 MB (`gateway.cache.ttlHours`, `gateway.cache.maxMB`, `gateway.cache.enabled`). An Anthropic request is answered from it only when the stored response is less than a minute old (a retry or a duplicate). A later identical request is usually a harness keeping Anthropic's prompt cache alive (omp repeats its last request about 4.5 minutes later), so it goes to Anthropic and its response replaces the stored one. Send `x-superpi-cache: bypass` to skip it for one call, or `x-superpi-cache: off` to also keep that call's conversation out of keep-warm (below). - **Provider prompt caching.** Most tokens in an agent loop are the same conversation prefix re-sent every turn; providers bill those at a large discount when they are cache reads. The gateway records every cache read and, for Anthropic, every cache write split by TTL (5-minute and 1-hour). *Cache assist.* An Anthropic request that sets no `cache_control` anywhere gets two breakpoints: top-level automatic caching (Anthropic caches up to the last block and moves the breakpoint forward as the conversation grows) and one on the stable prefix — the last system block, or the last tool when there is no system prompt. A request that sets any breakpoint of its own is forwarded untouched. The Usage page counts assisted requests and the cache reads they earned. *TTL.* `gateway.cache.anthropicTtl` (`5m`, the default, or `1h`) sets the TTL of the breakpoints the assist adds; it never changes a harness's own breakpoints. Anthropic's cache entry lives 5 minutes from the start of the last request that wrote or read it. A 5-minute write costs 1.25x input, a 1-hour write 2x input, a read 0.1x or less. So `1h` pays off when you come back to a conversation 5 to 60 minutes after its last turn (a long review, a meeting, a slow tool run): without it the whole prefix is written again at 1.25x instead of read at 0.1x. With turns less than 5 minutes apart it only adds the 0.75x-input premium on every write. *Rewrites.* The gateway notices when a conversation writes again a prefix that was already cached, and sorts those tokens by the gap since the conversation's previous request: under 5 minutes (the prefix changed or a breakpoint fell outside Anthropic's 20-block lookback), 5 to 60 minutes (the 5-minute entry expired; 1h would have kept it) and over an hour. The Usage page shows what the rewrites cost and what `1h` would have saved against what it would have cost extra. It is an estimate: a harness that edits earlier turns in place also shows up as rewrites. *Keep-warm.* When an Anthropic conversation goes quiet (a subagent waiting for its parent, you reading a diff), the gateway keeps its 5-minute cache alive: 4 minutes 45 seconds after the start of the conversation's latest request it sends that request again, byte for byte, reads the response only up to its first event (which reports the usage) and closes the connection. That costs one cache read of the prefix (0.1x input or less) plus the small uncached tail, instead of writing the whole prefix again at 1.25x when you come back. It repeats every 4 minutes 45 seconds until the conversation has had no request of its own for `gateway.cache.keepWarmMinutes` (35 by default; `0` turns keep-warm off). Any request of the conversation, including a harness's own cache-warming request (omp warms its main session at 4 minutes 30 seconds), resets the timer, so nothing is warmed twice. Only conversations with at least 20,000 cached tokens in the 5-minute tier are warmed: never a conversation whose last cache write was 1-hour, one that sets no `cache_control`, a request body over 16 MB, or a request sent with `x-superpi-cache: off`. A conversation whose latest response called the `yield` tool (an omp subagent finishing its run) is not warmed until its next turn: most finished subagents never resume, so refreshing them cost about twice what it saved. A request sent without streaming is replayed as a stream: `stream` is not part of the cached prompt, so it reads the same entry. Warming stops for a conversation when a refresh misses (it reads less than 90% of what it was keeping, so it wrote the prefix again) until the conversation's next real turn, and for good on any provider error or rate limit; it is never retried. The requests it replays, credentials included, are held in memory only (at most 64 MB, the conversations with the fewest cached tokens dropped first) and never written to disk or logs. The Usage page counts the refreshes and what they cost (also included in the gateway's spend, but not in its request count), and the cached tokens they rescued: a real turn that came back 5 minutes or more after the previous one and read what a refresh had kept, with the write it avoided less the read as the saving. Costs are estimates from the bundled model catalog; a model the catalog does not price shows tokens saved without a dollar figure. --- Source: https://harnesslink.sh/docs/install # Installing HarnessLink HarnessLink is the controller for your coding agents — it routes their model calls, gives them shared memory, banks what they do, and syncs and restores your setup. You code in omp, Claude Code, Codex or pi. HarnessLink was called SuperPi until October 2026; the command is still `superpi` (see RENAME.md). This guide covers a completely fresh machine through to the HarnessLink service running with your harnesses wired into it. ## What you actually need | Requirement | Why | Auto-installed? | | --- | --- | --- | | **macOS, Linux, or Windows 10+** | Supported platforms | — | | **Bun ≥ 1.3.14** | The CLI runs on Bun, not Node | yes (bun.sh) | | A harness to code in | HarnessLink runs no model itself; model credentials stay with each harness | omp is installed for you (`--no-omp` skips it); it signs in on first run | No GitHub account, token or `git` is needed, and nothing is compiled: the installer fetches the source tarball from harnesslink.sh and installs its production dependencies with Bun. **Alpine (musl).** The installer adds bun's `libstdc++` and `libgcc` via apk. The npm omp package ships only glibc natives, so on musl omp comes from the upstream `omp-linux-musl-` release binary instead, checked against the release's `SHA256SUMS.txt`. `omp update` keeps using the musl asset. The installer also installs **omp** (`@oh-my-pi/pi-coding-agent`, upstream oh-my-pi) — a harness to code in — and links it beside `superpi`. Pass `--no-omp` to skip that; Claude Code, Codex and pi work just as well. ## Windows ```powershell irm https://harnesslink.sh/install.ps1 | iex ``` The PowerShell one-liner downloads and runs `install.ps1` from harnesslink.sh. Open PowerShell and paste it. **Prerequisites** | Requirement | Why | Auto-installed? | | --- | --- | --- | | **Windows 10+** | `tar.exe` ships with Windows 10; PowerShell 5.1 always present | — | | **Bun ≥ 1.3.14** | The CLI runs on Bun, not Node | yes (`irm bun.sh/install.ps1 \| iex`) | | A harness to code in | HarnessLink runs no model itself | omp is installed for you (`-NoOmp` skips it) | The installer downloads the source tarball from `https://harnesslink.sh/superpi-src.tar.gz`, extracts it with the `tar.exe` that ships with Windows 10+ and installs its production dependencies with Bun. No git, GitHub or compiler involved. **Installer parameters.** `irm … | iex` cannot pass parameters. To pass them, download the script and run it as a file: ```powershell irm https://harnesslink.sh/install.ps1 -OutFile install.ps1 powershell -NoProfile -ExecutionPolicy Bypass -File .\install.ps1 -Yes ``` | Parameter | Effect | | --- | --- | | `-DryRun` | Print what it would do; change nothing; exit 0 | | `-NoOmp` | Skip installing omp | | `-Yes` | Unattended: skip the onboarding and print `Finish setup: superpi cloud setup` instead | There is no `--with` or `--cloud` equivalent on Windows. Install other harnesses afterwards with `superpi harness install `, and run `superpi cloud setup` yourself after a `-Yes` install. **Troubleshooting — Windows** **`irm` blocked by execution policy** The default Windows policy may block running scripts downloaded from the internet. Bypass it for the current shell only (it is not a system-wide change): ```powershell Set-ExecutionPolicy -Scope Process Bypass irm https://harnesslink.sh/install.ps1 | iex ``` **`superpi: command not found` / `superpi.cmd` not recognised** Bun's bin directory (`%USERPROFILE%\.bun\bin`) is not on `PATH`. Add it permanently in **System Settings → Environment Variables**, or for the current session: ```powershell $env:PATH = "$env:USERPROFILE\.bun\bin;$env:PATH" ``` **Bun install fails behind a proxy** Set `HTTPS_PROXY` before running the installer: ```powershell $env:HTTPS_PROXY = 'http://proxy.corp.example.com:8080' irm https://harnesslink.sh/install.ps1 | iex ``` **Environment variables for custom installs** ```powershell $env:SUPERPI_DIR = 'D:\dev\superpi-src' # where to put the source $env:SUPERPI_SITE = 'https://harnesslink.sh' # tarball + installer base URL irm https://harnesslink.sh/install.ps1 | iex ``` ## Install ```bash curl -fsSL https://harnesslink.sh/install.sh | bash ``` harnesslink.sh serves the repository's `install.sh` verbatim; it is the only source and needs no authentication. From 17.5.55 the installer (and `superpi update`) also links `harnesslink` and `hlk` to the same command; `hlk` is skipped if another program already owns that name. All three behave identically, and this guide uses `superpi`. On Windows they are `superpi.cmd`, `harnesslink.cmd` and `hlk.cmd`. ### Options ```bash bash install.sh --help --dir Source location (default: ~/.superpi-src) --no-omp Skip installing omp (a harness to code in) --with= Also install the listed harnesses after omp (comma-separated) Valid ids: omp claude-code codex gemini pi dsh Example: --with=claude-code,codex --cloud Run the onboarding even with --yes (it still needs a terminal: sign-in happens in your browser) --yes Assume yes for anything that modifies the system ``` The installer is **re-runnable**: every step checks before acting, so running it again updates rather than reinstalls. ### Manual install If you would rather see each step: ```bash mkdir -p ~/.superpi-src && curl -fsSL https://harnesslink.sh/superpi-src.tar.gz | tar -xz -C ~/.superpi-src cd ~/.superpi-src bun install --production sh scripts/link-superpi.sh # links superpi (plus harnesslink and hlk) into ~/.bun/bin bun install -g @oh-my-pi/pi-coding-agent # omp, a harness to code in ``` ## Verify ```bash superpi --version superpi --smoke-test superpi # the home screen: service, sign-in, sync, each harness's wiring ``` `--smoke-test` loads every command and exercises the gateway and the MCP relay end to end in a throwaway directory, so a broken install fails here rather than on first use. ## First run — the onboarding An interactive install ends by opening `superpi cloud setup` directly (no extra question: its first screen is the confirmation). `--yes`, CI and other headless runs skip it and print `Finish setup: superpi cloud setup` instead. Run it any time: ```bash superpi cloud setup # the onboarding: plan → sign in → everything else automatic superpi cloud status # sync health afterwards superpi gateway status # gateway + cloud sync health ``` 1. **Plan.** One screen lists everything that turns on — all of it on by default: sign in, cloud sync, the HarnessLink service, then each harness found on this machine with the features it supports here, then restoring from the cloud (sessions, history, memories, harness setup) and importing old memories. Per-harness features and where each applies: | Feature | What it does | Harnesses | | --- | --- | --- | | Gateway routing | model calls go through the local gateway | Claude Code, Codex, omp, pi | | Transcript sync | session transcripts, prompt history and the harness's own memory files upload | every harness with an adapter: Claude Code, Codex, omp, pi, Cursor, Antigravity (see MULTI_HARNESS.md for what each one actually yields) | | Autobank | every finished turn becomes a memory bank entry, starting with the last 30 days; todo and plan snapshots too (see MEMORY_BANKING.md) | omp, pi, Claude Code, Codex, Antigravity — not Cursor | | Context hooks | project brief, matching memories and your org's policy instructions injected before the model answers; org tool and command rules checked before every tool call | Claude Code, Codex, omp | | Memory tools (MCP) | `superpi mcp` registered so the model can call memory tools | omp, Claude Code, Codex | A feature only appears when the harness is detected (its binary on `PATH`, or its data directory present). A **What syncs** block lists every sync category (prompt history from every harness, session transcripts, memories, usage from HarnessLink's old built-in agent, gateway usage, device profile), all ✓. **Enter** sets it all up, **c** customizes (toggle any sync category, harness or feature, including restore), **q** quits. 2. **Sign in.** A HarnessLink Cloud account is required. The device code is shown large, the browser opens on the approval page (**o** reopens it, **c** copies the code), and a spinner waits for your approval. Already signed in? It shows the account and moves on. Cancelling (**Esc**) or failing stops with "Setup is not complete: a HarnessLink Cloud account is required — run `superpi cloud setup` again" and exit code 1. 3. **Everything else runs by itself** on a live checklist (spinner → ✓ or ✗ with a one-line detail): cloud sync on, with your sync category choices → the HarnessLink service (launchd on macOS, a `systemd --user` unit on Linux, a logon task on Windows) → per harness: gateway routing, transcript sync, autobank, context hooks (see USAGE.md), memory tools → restore (additive: never overwrites a local file): sessions, prompt history, memories, harness setup (agents, commands, skills, rules), old memories (MemPalace, Hermes) → verify (the gateway answers and is signed in, one prompt-history pass over every harness, the memory bank from every harness, a real sync round trip, sync health). A failed step does not stop the ones after it. The HarnessLink service notices harnesses turned on after it started; it does not need a restart. 4. **Summary.** ✓/✗ per step with the retry command for each failure, what is on now, and the standalone command for every piece. Every piece stays a command of its own for manual setups: | Piece | Command | Undo | | --- | --- | --- | | Sign in (required) | `superpi cloud login` | `superpi cloud logout` | | Cloud sync (on whenever signed in) | `superpi cloud sync` | `cloud.sync: false` in config.yml, or `SUPERPI_CLOUD_SYNC=0` | | What syncs (every category on by default) | `superpi cloud sync --enable ` | `superpi cloud sync --disable ` | | HarnessLink service | `superpi gateway start` | `superpi gateway service uninstall` | | Gateway routing | `superpi gateway connect [id]` | `superpi gateway disconnect [id]` | | Transcript sync | `superpi cloud harnesses enable ` | `superpi cloud harnesses disable ` | | Autobank | `superpi cloud autobank enable ` | `superpi cloud autobank disable ` | | Context hooks | `superpi harness context [id]` | `superpi harness context [id] --remove` | | Memory tools (MCP) | `superpi mcp register --harness= --yes` | | | Restore | `superpi cloud pull-sessions --all` · `superpi cloud pull-history` · `superpi cloud pull-memories --all` · `superpi cloud restore --apply` | | | Import old memories | `superpi cloud import-memories --apply` | | | Check it all | `superpi gateway status` · `superpi cloud status` · `superpi cloud autobank status` | | Without a terminal, `superpi cloud setup` prints this list and exits 1. The hosted service at [harnesslink.sh](https://harnesslink.sh) is the default. To run against your own Cloudflare stack instead, set it up first — see CLOUD_SETUP.md. The dashboard's **Setup** page shows an eight-step checklist and ticks each step off from your real cloud data; the public copy lives at [harnesslink.sh/docs#connect-the-cloud](https://harnesslink.sh/docs#connect-the-cloud). The canonical definitions are code, not prose: `cloud/web/src/lib/setupSteps.ts` — update that file and this table together. | # | Step | Command | Optional | | --- | --- | --- | --- | | 1 | Install and sign in — the installer puts HarnessLink and omp on the machine and opens `superpi cloud setup`, which turns on cloud sync, the service and, per harness found, gateway routing, transcript sync, autobank, context hooks and memory tools | `curl -fsSL https://harnesslink.sh/install.sh \| bash` | | | 2 | Cloud sync on — signing in turns it on; plain `superpi` shows sync health on its home screen | `superpi cloud status` | | | 3 | First sync completed — prompt in any connected harness (omp, Claude Code, Codex, pi, Antigravity) | `superpi cloud sync` | | | 4 | Profile pushed — the service uploads it by itself and whenever it changes (HarnessLink's config and MCP server names, plus each harness's agents, commands, rules, skills; never secret values); this refreshes it now | `superpi cloud push-profile` | | | 5 | Code intelligence wired | `curl -fsSL https://get.gortex.dev \| sh` | ✓ | | 6 | HarnessLink skills folder in the profile — skills and agents the old built-in agent left in HarnessLink's own folder (`~/.superpi/agent`) travel inside the profile so a new machine can restore them (skills `superpi add` installs live in the harnesses' own skill folders; the Claude Code, omp and pi copies travel with that harness's setup); the dry run lists every file it carries | `superpi cloud push-profile --dry-run` | ✓ | | 7 | Memories in the cloud — each harness's memory files and memory bank upload by themselves; setup imports older MemPalace and `~/.hermes` memories once | `superpi cloud import-memories --apply` | ✓ | | 8 | Adopt on another machine — `config.yml` backed up before it is replaced, harness files only created, MCP servers disabled until approved | `superpi cloud restore --device --apply --install-tools` | ✓ | ## Updating ```bash superpi update ``` A picker over every harness on the machine — omp first, then HarnessLink itself, then Claude Code, Codex and others that are installed — running each one's own updater. HarnessLink updates itself by re-running the installer from harnesslink.sh. Non-interactive runs update HarnessLink directly. **Old-agent leftovers.** HarnessLink's old built-in agent left git worktrees in `~/.superpi/wt` (they can reach many GB) and the output of its background jobs in `~/.superpi/run/daemons` (logs only, often hundreds of MB). `superpi update` and the `superpi` home screen offer to remove them, showing their combined size; `superpi cleanup` does it on demand. Nothing is deleted without your yes, and worktrees with uncommitted changes are listed and never deleted without saying so. **An update tidies after itself.** Re-running the installer over `~/.superpi-src`: - removes whatever the previous version shipped that this one does not: whole directories (the old built-in agent, the native addon and their build outputs) and single files alike — a plain extract only adds and overwrites; - rebuilds `node_modules` from scratch when the set of packages changed, so the old tree's dependencies (1.4 GB before HarnessLink became a controller) do not linger, and says how much space it freed; - removes a `.git` left by a pre-cutover clone, so `superpi update` never turns into a private-repository credential prompt; - keeps build products of what it still ships (`node_modules`, `dist`, generated sources) and dotfiles at the root of the tree. A bazel cache an old native build left elsewhere is named, never deleted. The installer refuses to install over a git checkout at a custom `--dir`, or over any non-empty directory that is not already a HarnessLink install — it would otherwise overwrite and prune your files. ## Troubleshooting **`superpi: command not found`** `~/.bun/bin` is not on your `PATH`. Add it and open a new shell: ```bash export PATH="$HOME/.bun/bin:$PATH" ``` **`superpi` says you are not signed in, or shows an empty setup** Check which config directory is in use — a stray `SUPERPI_CONFIG_DIR` (or, from 17.5.55, `HARNESSLINK_CONFIG_DIR`) in your environment will point the CLI at an empty profile: ```bash echo "$HARNESSLINK_CONFIG_DIR $SUPERPI_CONFIG_DIR" # expect both empty ``` Both names work; when both are set, `HARNESSLINK_CONFIG_DIR` wins. `SUPERPI_CONFIG_DIR` accepts either a **relative name** (resolved under `$HOME`, default `.superpi`) or an **absolute path** (used as-is as the full config root). A relative name such as `cfg` resolves to `$HOME/cfg`; an absolute path such as `SUPERPI_CONFIG_DIR=/tmp/cfg` uses `/tmp/cfg` directly. To run against a different profile, set `SUPERPI_CONFIG_DIR` to an absolute path, or set `HOME` to redirect all relative resolution. ## Uninstalling Undo the wiring **before** deleting anything. The harnesses' own configs point at HarnessLink (gateway base URLs, hooks, MCP entries); deleting the `superpi` binary first leaves them pointing at nothing, and connected harnesses then fail with "connection refused". ```bash superpi gateway disconnect # put back each harness's own provider settings superpi harness context --remove # remove HarnessLink's context hooks (Claude Code, Codex, omp) superpi gateway service uninstall # stop and remove the LaunchAgent / systemd unit / logon task superpi cloud logout # optional: unlink this machine from your account superpi add --list # optional: registry add-ons HarnessLink put in harness skill folders superpi remove # remove each one (only the files HarnessLink wrote) ``` Then remove HarnessLink's MCP entry from each harness you registered it in: | Harness | How | | --- | --- | | Claude Code | `claude mcp remove --scope user superpi` | | Codex | delete the `[mcp_servers.superpi]` block from `~/.codex/config.toml` | | omp | delete `mcpServers.superpi` from `~/.omp/agent/mcp.json` | | Cursor | delete `mcpServers.superpi` from `~/.cursor/mcp.json` | Finally remove HarnessLink itself: ```bash rm -f ~/.bun/bin/superpi rm -rf ~/.superpi-src rm -rf ~/.superpi # ⚠️ also deletes local history, memory and sessions ``` On Windows, delete `%USERPROFILE%\.bun\bin\superpi.cmd` and `%USERPROFILE%\.superpi-src` instead. This leaves omp, pi, Claude Code, Codex and every other harness installed — they are separate programs. In particular, `~/.bun/bin/pi` is the pi harness, not part of HarnessLink. Remove a harness with its own uninstaller if you want it gone. --- Source: https://harnesslink.sh/docs/memory-banking # Memory Banking **How finished turns from every harness become Markdown memory — and what reads it** --- ## In one paragraph A **turn** is one prompt you send to a harness plus everything its agent does until it stops and hands control back to you. When a turn finishes, HarnessLink writes a short Markdown **bank entry**: your prompt, the tools the agent called, and its final answer. Entries live in a per-project folder on your disk and upload to HarnessLink Cloud like any other memory file. Recall, briefs, context hooks and the MCP memory tools all read them. The **HarnessLink service** produces them by reading each harness's transcripts on disk — omp, pi, Claude Code, Codex and Antigravity. This is **autobank**. `superpi cloud setup` turns it on for every one of those harnesses it finds, and the first pass for a harness banks its last 30 days. Cursor is not supported. Entries that HarnessLink's old built-in agent banked in-process stay in the tree and keep syncing; nothing produces new ones. ## Background and origin HarnessLink already runs an append-only memory-gateway pattern: a `MemorySyncUploader` background process scans the memories tree (`~/.superpi/agent/memories/`), uploads every `.md` file it finds to the cloud D1 store, and the reverse `pull-memories` command rehydrates the local tree from the cloud. This upload/pull pipeline already works and ships zero server changes for storage — any `.md` file placed in the right directory is picked up automatically. The memory banking feature builds on that foundation by adding a new write path: when an agent turn settles, a Markdown artifact representing that turn is appended to the project-scoped memory tree. No changes to the upload infrastructure, the D1 schema, or the pull endpoint are required. --- ## Layout All files live inside the existing memories root (`getMemoriesDir()`, default `~/.superpi/agent/memories/`). Project directories use the same slug encoding as the existing pipeline: ``` / / ← e.g. --Users-me-Workspace-myapp-- bank/ --.md ← one entry per finished turn (append-only) MAIN.md ← index controller summaries/ .md ← daily roll-up (additive, never deleted) state/ --.md ← latest todos / plan / checkpoints of one harness session ``` The project is the turn's working directory, so a turn from Claude Code and a turn from omp in the same folder land in the same project. ### Bank entry file Each file is a self-contained Markdown artifact with YAML frontmatter: ```markdown --- id: 2026-08-28T10-30-00-000Z ts: "2026-08-28T10:30:00.000Z" title: "Fix the authentication bug" tags: - bash - read - write cwd: "/Users/me/Workspace/myapp" session_id: "01929fae..." harness: claude-code turn_key: "claude-code:01929fae...:4b1c..." source: autobank:claude-code --- ## Prompt The user's request (capped at 2 000 chars). ## Actions - bash: {"command":"npm test"} - write: {"path":"/src/auth.ts","content":"..."} ## Result The final assistant response (capped at 4 000 chars). ``` **File-safe ISO** replaces `:` and `.` with `-` so filenames work on all filesystems. The double-dash `--` separator distinguishes the timestamp prefix from the slug, since the timestamp itself contains only single dashes after the replacement. The time is when the turn finished, not when it was banked, so a backfilled entry sorts where it happened. **`harness`, `turn_key` and `source`.** Autobank entries carry `harness: `, `turn_key: ::` and `source: autobank:`. Older entries from HarnessLink's old built-in agent carry `source: superpi-autobank` and no `harness` or `turn_key`. **Per-file byte cap**: each entry is checked against `MEMORY_UPLOAD_MAX_BYTES` (1 MB) — the same ceiling the `MemorySyncUploader` enforces — and the Result section is trimmed if the file would exceed it. In practice, the character caps (2 000 / 4 000 chars) keep entries well under 10 KB. ### MAIN.md An index controller file per project. Human-written notes above the marker comments are preserved verbatim across every regeneration: ```markdown # Project Memory Add context, architecture notes, or reminders here. Everything above the markers is untouched by the banker. - 2026-08-28T10:30:00.000Z — Fix the authentication bug (bank/2026-08-28T10-30-00-000Z--fix-the-authentication-bug.md) - 2026-08-27T14:00:00.000Z — Add user preferences endpoint (bank/...) ``` The index is rebuilt newest-first, capped at 200 rows, once per autobank pass for each project that pass touched. ### Daily summaries Each project's past days that have bank entries but no summary file are compacted into `summaries/YYYY-MM-DD.md`: ```markdown # 2026-08-27 - Fix the authentication bug [bash, read, write] - Add user preferences endpoint [bash] ``` Compaction is purely additive: existing summary files are never touched — the bank is append-only by design. ### Work state (`state/`) For each harness session, autobank also keeps one file with that session's latest **todos**, **plan** and **checkpoints**: `state/--.md`. Frontmatter: `harness`, `session_id`, `cwd`, `updated` (time of the newest change), `kinds`. Sections: - `## Todos` — `- [x]` done, `- [~]` in progress, `- [!]` blocked, `- [-]` abandoned, `- [ ]` pending - `## Plan` - `## Checkpoints` — the last 10 | Harness | Read from | | --- | --- | | omp, pi | the todo tool's results and manual todo edits, `/local/PLAN.md`, checkpoint/rewind calls | | Claude Code | `~/.claude/tasks//*.json`, legacy `~/.claude/todos/…`, `TodoWrite` calls, `~/.claude/plans/.md`, `ExitPlanMode` plans | | Codex | `update_plan` calls (not those made inside code-mode `exec` scripts) | The file is checked whenever the session's transcript grows, rewritten only when its content changes, and never deleted. Like bank entries, it uploads through the normal memory sync. --- ## When banking fires ### Autobank The HarnessLink service runs an **autobank pass** when it starts, every 30 seconds, every 2 seconds while a backfill is still draining, and once in every `superpi cloud sync`. A pass reads up to about 8 MB of new transcript per harness. It only reads files; it never writes to a harness's store. | Harness | Transcripts read | A turn is finished when | | --- | --- | --- | | omp | `~/.omp/agent/sessions//*.jsonl` | the assistant stops (`stop`, `length`, `aborted`), the next prompt arrives, or the session exits. An `error` stop waits, because a retry continues the turn | | pi | `~/.pi/agent/sessions//*.jsonl` | same as omp | | Claude Code | `~/.claude/projects//.jsonl` | a `turn_duration` record, the next real prompt, or an interrupt. A plain `end_turn` stop is not enough on its own, because a Stop hook can still continue the turn | | Codex | `~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl` | `task_complete`. Interrupted turns (`turn_aborted`) are never banked | | Antigravity | `~/.gemini/antigravity-cli/conversation_summaries.db` and `history.jsonl` | — see below | **Quiet transcripts.** For omp, pi and Claude Code, a turn that has an answer and no tool call still pending is also banked once its transcript has been quiet for 5 minutes, so the last turn of a session is not lost. A turn still waiting on a tool is never banked this way; after 7 days of silence it is dropped. Codex turns settle only on `task_complete`. **Antigravity** keeps no readable per-turn transcript, so it gets **one entry per conversation**: the conversation title, its first prompt, and a result of step count, last activity and up to the last 20 prompts. The entry is dated by the conversation's first prompt. When the conversation's step count or last-modified time changes, the same entry is rewritten in place. Child conversations, conversations with no workspace folder, and conversations last modified before the backfill window are skipped. **Not banked:** subagent turns (omp/pi `/` subagent files, Claude Code `subagents/` and sidechain lines, Codex subagent threads), turns a branched or forked omp/pi session copies from its parent session (they are banked once, from the parent), and **Cursor**, which is not supported. **Backfill.** The first pass after a harness is turned on banks the turns that finished in the **last 30 days**, then follows new turns. Transcripts not modified in those 30 days are not read. `superpi cloud autobank backfill --days=N` widens the window and re-reads every transcript once. **Exactly once.** Each turn is banked at most once, keyed by its `turn_key`, across restarts, log rotation and backfills. A pass stopped in the middle of a write loses no turns: another pass takes over its reservation after 10 minutes. Read positions, unfinished turns and banked keys live in `~/.superpi/agent/harness-autobank.db`. **Switches.** `cloud.autobank` in `config.yml` lists the harnesses with autobank on (`superpi cloud autobank enable|disable `; setup turns it on for every detected one). On a machine set up before autobank existed the key is absent, and autobank follows `cloud.harnesses` (the harnesses already captured), so updating HarnessLink turns it on without re-running setup; once the key is written — by setup, `enable` or `disable` — that list is used, even when empty. Autobank works locally: it does not depend on any sync category, and its files upload through the normal `memories` category. Turning a harness off — with `disable`, by removing it from `cloud.autobank`, or with `memory.autoBank: false` — pauses it. Entries already banked stay. When it is turned back on, it banks the last 30 days, not everything from the time it was off. ### Trivial-turn filter For every harness except Antigravity, a turn is skipped when: - No tool calls were made **and** the result text is shorter than 200 characters. This excludes brief conversational exchanges that carry no durable signal — simple acknowledgements, one-line answers, and error recoveries — while banking every meaningful working session. Antigravity conversations are always banked. ### The master switch `memory.autoBank` (boolean, default `true`) is the master switch. Setting it to `false` in `config.yml` stops all banking and `state/` snapshots for every harness. It is read on every autobank pass, so it takes effect without a restart. ### Safety invariants - **Banking never breaks a session.** Autobank runs in the HarnessLink service, outside every harness, and only reads their files. Errors are caught and logged; a disk-full or permission error produces a log warning, not a crash. - **New entries reach the cloud on the next memory sync** of the HarnessLink service, or at once with `superpi cloud sync`. --- ## Why zero server changes The `MemorySyncUploader` scans the entire memories tree for `.md` files and uploads any that are new or changed. `bank/*.md` and `summaries/*.md` are plain Markdown files in the same directory tree. No new file categories, no schema migrations, no API additions are needed. The cloud store receives them on the next scan, and `pull-memories` delivers them to any other machine that pulls. The MAIN.md index file is also in the tree and reaches the cloud, giving remote sessions a human-readable overview of the project's banked history. ## Consumers of the bank Banking is the compression step; four surfaces consume it, so the distilled record replaces raw transcripts wherever context is re-established: - **Recall** — `superpi cloud recall ` and `GET /v1/memories/index/search` run the shared FTS core over bank entries (own project + `linked.txt` projects by default). - **Context brief** — `superpi cloud brief` (`src/cloud/brief.ts`) assembles a budgeted brief from the human part of `MAIN.md`, the newest ten bank entries, the harness's own memory files (`raw_memories.md`, newest rollout summary) and an optional recall section from the local index below. Sections are whole-or-dropped under `--budget`. - **Resume broker** — `superpi resume` offers the brief beside native resume once a transcript's estimated replay cost reaches 50 000 tokens (`src/cli/resume-broker.ts`). - **MCP server** — `superpi mcp` exposes `memory_search`, `memory_get`, `memory_bank` and `context_brief` (plus the aliases `recall_memory` and `record_learning`) so any coding harness wired to the server can search, fetch and bank memory inline without leaving the session (`src/mcp/server/superpi-server.ts`; `src/cloud/brief-wiring.ts`). The full tool list is in USAGE.md. - **Context hooks** — `superpi context-hook` injects the brief at session start and up to three matching bank entries on each prompt in Claude Code, Codex and omp. - **Local memory index** — `~/.superpi/agent/memory-index.db` (`src/memories/local-index.ts`, ADR-43): SQLite FTS5 over the whole tree, a bank entry split into title, tags, prompt, step-log digest and result. The service keeps it current from its file watcher; `memory_search`, the brief's recall and the hooks read it first, and `memory_get` reads the file on this machine before asking the cloud. See USAGE.md. Nothing here changes how banking writes; these are readers of the same tree. --- ## Implementation files | File | Role | | --- | --- | | `packages/superpi/src/memories/banker.ts` | Core implementation: entries, `MAIN.md`, summaries, `state/` files | | `packages/superpi/src/cloud/harness-autobank.ts` | Autobank: the pass over each harness's transcripts, cursors, backfill | | `packages/superpi/src/cloud/harness/turn-parsers.ts` | Per-harness turn and work-state parsers | | `packages/superpi/src/cloud/autobank-cli.ts` | `superpi cloud autobank` | | `packages/superpi/src/cloud/config.ts` | `memory.autoBank` master switch (read from `config.yml`, default true) | | `packages/superpi/test/memory-banker.test.ts` | Unit tests | --- Source: https://harnesslink.sh/docs/multi-harness # What HarnessLink captures from each harness HarnessLink is the controller for your coding agents — it routes their model calls, gives them shared memory, banks what they do, and syncs and restores your setup. You code in omp, Claude Code, Codex or pi. A **harness** is a coding agent that runs a model with tools: omp, Claude Code, Codex, pi, Antigravity, Cursor. HarnessLink is not one of them. It never patches a harness: it reads the files each one already writes, and — with your consent, through `superpi cloud setup` — adds its own entries to a harness's config (gateway base URL, context hooks, MCP server). This is what each harness yields after a default install and setup: | | omp | pi | Claude Code | Codex | Antigravity | Cursor | | --- | --- | --- | --- | --- | --- | --- | | Prompt history | ✓ | ✓ | ✓ | ✓ | ✓ | — | | Session transcripts | ✓ | ✓ | ✓ | ✓ | ✓ (`brain//.system_generated/logs/transcript_full.jsonl`) | `~/.cursor/sessions/*.jsonl` only | | Subagent transcripts | ✓ | ✓ | ✓ | ✓ | — | — | | Memory bank (autobank) | every finished turn (not subagents) | every finished turn (not subagents) | every finished turn (not subagents) | every finished turn (not subagents) | one entry per conversation | — not supported | | Work state (`state/`) | todos, plan, checkpoints | todos, plan, checkpoints | todos, plans | plans | — | — | | Own memory files | `AGENTS.md`, `memories/` | `AGENTS.md`, `memories/` | `CLAUDE.md` (global and per project), auto memory | `AGENTS.md`, `AGENTS.override.md`, `memories/` | `GEMINI.md`, rules, knowledge, brain artifacts | `~/.cursorrules` | | Setup in the device profile | agents, commands, rules, prompts, skills, `AGENTS.md`, `SYSTEM.md` | same as omp | agents, commands, rules, output styles, skills, `CLAUDE.md` | prompts, skills, `AGENTS.md` | — | — | | Gateway routing | ✓ | ✓ | ✓ | ✓ | — (traffic goes straight to Google) | — | | Context hooks | ✓ | — | ✓ | ✓ | — | — | | Org policy (tool and command rules) | ✓ (`tool_call` extension) | ✗ no tool hook | ✓ (`PreToolUse`) | ✓ (`PreToolUse`; prompt rules block; hosted web search not hookable) | ✗ no documented tool hook | ✗ no tool hook | | Org policy instructions | ✓ | — | ✓ | ✓ | — | — | | Org model rules and usage limits (gateway, 17.5.50+) | Anthropic and OpenAI Codex providers | Anthropic and OpenAI Codex providers | ✓ | ✓ | ✗ traffic goes straight to Google | ✗ not routed | | Memory tools (MCP) | ✓ | — | ✓ | ✓ | — | `--harness=cursor` by hand | | Runs from `SUPERPI_RUN_ID` | ✓ | — | ✓ | ✓ | — | — | | Runs from subagents | ✓ | ✓ | ✓ | ✓ | — | — | | Delegation target (`superpi run`, `delegate`) | `omp -p --mode json` | `pi -p --mode json` | `claude -p --output-format stream-json` | `codex exec --json` (read-only sandbox, git repos only) | `agy --output-format stream-json` (commands auto-denied) | — | How each piece works: history, transcripts and runs in USAGE.md; the memory bank and `state/` in MEMORY_BANKING.md; setup and its switches in INSTALL.md. **Cursor is not supported** beyond the two files named above. Its chats live in an editor database HarnessLink does not read, so Cursor prompts and turns are not captured or banked. Collection runs inside the **HarnessLink service** (`hnl daemon run`, supervised by launchd, `systemd --user` or a logon task), which the CLI installs. --- Source: https://harnesslink.sh/harnesses/claude-code # HarnessLink for Claude Code Claude Code gets everything HarnessLink does: its transcripts and prompts are captured, every finished turn becomes a memory entry, a project brief and related memories arrive through Claude Code's own hooks, and the model can search the same memory your other harnesses write. ## What HarnessLink captures from Claude Code | Feature | In Claude Code | Details | | --- | --- | --- | | Prompt history | Yes | Your prompts, read from the session transcripts. | | Session transcripts | Yes | `~/.claude/projects//.jsonl` and subagent transcripts, uploaded moments after they change. | | Memory bank (autobank) | Yes | Every finished turn becomes a memory entry (subagents are skipped). | | Gateway routing | Yes | `env.ANTHROPIC_BASE_URL` in `~/.claude/settings.json` points at `http://127.0.0.1:4747/claude-code/anthropic`. Claude Code keeps its own login. | | Context hooks | Yes | `SessionStart`, `UserPromptSubmit`, `PreToolUse`, `Stop` and `PreCompact` in `~/.claude/settings.json`. | | Memory tools (MCP) | Yes | Added with `claude mcp add --scope user`, so it lands in the user-scope `mcpServers` of `~/.claude.json`. | | Org policy rules | Yes | Checked in `PreToolUse` before a tool runs; "ask first" rules ask you. | | Skills from templates | Yes | `hnl add ` installs into `~/.claude/skills`. | | Resume in another harness | Yes | `hnl resume` reopens a session with `claude --resume`. | ## Set up Claude Code 1. Install HarnessLink on macOS or Linux ([Windows](https://harnesslink.sh/docs#windows) has its own one-liner). ``` curl -fsSL https://harnesslink.sh/install.sh | bash ``` 2. Sign in once in your browser; setup then turns on what each harness on the machine supports. ``` hnl cloud setup ``` 3. Or turn the pieces on one at a time. Each is its own command, so you can redo or undo it later. ``` hnl gateway connect claude-code hnl cloud harnesses enable claude-code hnl cloud autobank enable claude-code hnl harness context claude-code hnl mcp register --harness=claude-code --yes ``` 4. Check what is connected: plain `hnl` shows, for each harness, the gateway, transcripts, autobank, context and memory tools. ``` hnl ``` ## How memory reaches Claude Code **At session start** the `SessionStart` hook adds your organisation's policy instructions, then a brief of the project: `MAIN.md`, recent memory entries and harness memory, up to 9,500 characters (Claude Code takes at most 10,000). **On each prompt** the `UserPromptSubmit` hook adds up to 3 memory entries that share at least two distinctive words with what you typed, from any harness that banked them. The hooks read files on the machine only (the local memory index and `MAIN.md`); they never call the cloud, so they stay fast and work offline. **When the model needs more** it calls the memory tools. The MCP server is the HarnessLink service's own (`superpi mcp`). Its tools include `memory_search` (search your memory across projects and machines), `memory_get` (read one entry in full), `memory_bank` (record a decision or outcome), `context_brief` (a budgeted brief of the project), `session_list` and `session_get`. **Near the context limit** the `Stop` hook asks the model to save a handoff with `memory_bank` and to suggest `/clear`; `PreCompact` saves the handoff before Claude Code compacts. ## Limits - The MCP server is registered only when the `claude` command is on your PATH. - The gateway sees model calls only after `hnl gateway connect claude-code`; until then usage and model rules do not apply. ## Guides - [Installing HarnessLink](https://harnesslink.sh/docs/install): The full HarnessLink install guide: requirements, Windows, install options, verifying, the first-run onboarding, updating, troubleshooting and uninstalling. - [Memory Banking](https://harnesslink.sh/docs/memory-banking): How HarnessLink turns each finished turn in omp, Claude Code, Codex, pi and Antigravity into a Markdown memory entry, when banking runs, and what reads it. - [What HarnessLink captures from each harness](https://harnesslink.sh/docs/multi-harness): What HarnessLink captures from omp, Claude Code, Codex, pi, Antigravity and Cursor after setup, and how it stays a controller rather than a harness. ## Other harnesses - [Codex](https://harnesslink.sh/harnesses/codex): Hooks, MCP memory tools, gateway and autobank - [omp](https://harnesslink.sh/harnesses/omp): Context extension, MCP memory tools, gateway and autobank - [pi](https://harnesslink.sh/harnesses/pi): Transcripts, autobank and gateway - [Antigravity](https://harnesslink.sh/harnesses/antigravity): Transcripts and one memory entry per conversation - [Cursor](https://harnesslink.sh/harnesses/cursor): MCP memory tools, by hand; chats not captured [All harnesses](https://harnesslink.sh/harnesses) · [Install guide](https://harnesslink.sh/docs) · [Pricing](https://harnesslink.sh/pricing) · [Integrations](https://harnesslink.sh/integrations) --- Source: https://harnesslink.sh/harnesses/codex # HarnessLink for Codex Codex gets the full set: its transcripts and prompt history are captured, every finished turn is banked, context hooks bring a project brief and related memories into each session, and the MCP memory tools search what Claude Code, omp and pi banked too. ## What HarnessLink captures from Codex | Feature | In Codex | Details | | --- | --- | --- | | Prompt history | Yes | `~/.codex/history.jsonl`. | | Session transcripts | Yes | `~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl`, uploaded moments after they change. | | Memory bank (autobank) | Yes | Every finished turn becomes a memory entry (subagent threads are skipped). | | Gateway routing | Yes | A top-level `openai_base_url` in `~/.codex/config.toml`: `.../codex/chatgpt/codex` with a ChatGPT login, `.../codex/openai` with an API key. | | Context hooks | Yes | `SessionStart`, `UserPromptSubmit`, `PreToolUse` and `PreCompact` in `~/.codex/hooks.json` (no `Stop`). | | Memory tools (MCP) | Yes | `[mcp_servers.superpi]` in `~/.codex/config.toml`, running `superpi` with `args = ["mcp", "--harness", "codex"]`. | | Org policy rules | Partly | Checked in `PreToolUse`. "Ask first" rules block, because Codex cannot ask from a hook. | | Skills from templates | Yes | `hnl add ` installs into `~/.agents/skills`, which Codex reads. | | Resume in another harness | Yes | `hnl resume` reopens a session with `codex resume`. | ## Set up Codex 1. Install HarnessLink on macOS or Linux ([Windows](https://harnesslink.sh/docs#windows) has its own one-liner). ``` curl -fsSL https://harnesslink.sh/install.sh | bash ``` 2. Sign in once in your browser; setup then turns on what each harness on the machine supports. ``` hnl cloud setup ``` 3. Or turn the pieces on one at a time. ``` hnl gateway connect codex hnl cloud harnesses enable codex hnl cloud autobank enable codex hnl harness context codex hnl mcp register --harness=codex --yes ``` 4. Trust the new hooks once in Codex: run `/hooks` there. Codex skips hooks you have not trusted, and `hnl` reminds you until you do. 5. Check what is connected: plain `hnl` shows, for each harness, the gateway, transcripts, autobank, context and memory tools. ``` hnl ``` ## How memory reaches Codex **At session start** the `SessionStart` hook adds your organisation's policy instructions and a brief of the project, up to 7,000 characters (Codex shows longer hook output only as a preview). **On each prompt** the `UserPromptSubmit` hook adds up to 3 memory entries that share at least two distinctive words with your prompt, wherever they were banked: a decision made in Claude Code reaches Codex this way. The hooks read files on the machine only (the local memory index and `MAIN.md`); they never call the cloud, so they stay fast and work offline. **When the model needs more** it calls the memory tools. The MCP server is the HarnessLink service's own (`superpi mcp`). Its tools include `memory_search` (search your memory across projects and machines), `memory_get` (read one entry in full), `memory_bank` (record a decision or outcome), `context_brief` (a budgeted brief of the project), `session_list` and `session_get`. **Before Codex compacts** the `PreCompact` hook saves a handoff entry, so a new session (`/new`) can pick the task up. ## Limits - Codex runs a new or changed hook only after you trust it in `/hooks`. - Org policy: "ask first" rules block in Codex, and Codex's hosted web search cannot be hooked. - There is no `Stop` hook for Codex, so it does not prompt for a handoff; `PreCompact` still saves one. - The MCP server is registered only when the `codex` command is on your PATH. ## Guides - [Using HarnessLink](https://harnesslink.sh/docs/usage): Using HarnessLink day to day: Ask, history, policies, shared memory, resuming sessions across harnesses, profile sync, templates, delegation, runs and cost. - [Memory Banking](https://harnesslink.sh/docs/memory-banking): How HarnessLink turns each finished turn in omp, Claude Code, Codex, pi and Antigravity into a Markdown memory entry, when banking runs, and what reads it. - [What HarnessLink captures from each harness](https://harnesslink.sh/docs/multi-harness): What HarnessLink captures from omp, Claude Code, Codex, pi, Antigravity and Cursor after setup, and how it stays a controller rather than a harness. ## Other harnesses - [Claude Code](https://harnesslink.sh/harnesses/claude-code): Hooks, MCP memory tools, gateway and autobank - [omp](https://harnesslink.sh/harnesses/omp): Context extension, MCP memory tools, gateway and autobank - [pi](https://harnesslink.sh/harnesses/pi): Transcripts, autobank and gateway - [Antigravity](https://harnesslink.sh/harnesses/antigravity): Transcripts and one memory entry per conversation - [Cursor](https://harnesslink.sh/harnesses/cursor): MCP memory tools, by hand; chats not captured [All harnesses](https://harnesslink.sh/harnesses) · [Install guide](https://harnesslink.sh/docs) · [Pricing](https://harnesslink.sh/pricing) · [Integrations](https://harnesslink.sh/integrations) --- Source: https://harnesslink.sh/harnesses/omp # HarnessLink for omp omp is the harness the installer adds by default. HarnessLink captures its prompts, transcripts, todos and plans, banks every finished turn, brings memory into each session through a managed omp extension and gives the model the MCP memory tools. ## What HarnessLink captures from omp | Feature | In omp | Details | | --- | --- | --- | | Prompt history | Yes | `~/.omp/agent/history.db`. | | Session transcripts | Yes | `~/.omp/agent/sessions//*.jsonl`, subagents included, uploaded moments after they change. | | Memory bank (autobank) | Yes | Every finished turn becomes a memory entry, plus todo, plan and checkpoint snapshots. | | Gateway routing | Yes | `providers.anthropic.baseUrl` and `providers.openai-codex.baseUrl` in `~/.omp/agent/models.yml`. | | Context hooks | Yes | A managed extension, `~/.omp/agent/extensions/superpi-context.ts`, since omp has no settings-file hooks. | | Memory tools (MCP) | Yes | `mcpServers.superpi` in `~/.omp/agent/mcp.json`. | | Org policy rules | Yes | Checked in the extension's `tool_call` handler; "ask first" opens a confirm dialog. | | Skills from templates | Yes | `hnl add ` installs into `~/.omp/agent/skills`; agents and extensions install for omp only. | | Resume in another harness | Yes | `hnl resume` reopens a session with `omp --resume`. | ## Set up omp 1. Install HarnessLink. The installer also installs omp (`@oh-my-pi/pi-coding-agent`) unless you pass `--no-omp`. ``` curl -fsSL https://harnesslink.sh/install.sh | bash ``` 2. Sign in once in your browser; setup then turns on what each harness on the machine supports. ``` hnl cloud setup ``` 3. Or turn the pieces on one at a time. ``` hnl gateway connect omp hnl cloud harnesses enable omp hnl cloud autobank enable omp hnl harness context omp hnl mcp register --harness=omp --yes ``` 4. Check what is connected: plain `hnl` shows, for each harness, the gateway, transcripts, autobank, context and memory tools. ``` hnl ``` ## How memory reaches omp **At session start** the extension's `before_agent_start` handler adds your organisation's policy instructions and a brief of the project, up to 9,500 characters. **On each prompt** it adds up to 3 memory entries that share at least two distinctive words with your prompt, from any harness. The hooks read files on the machine only (the local memory index and `MAIN.md`); they never call the cloud, so they stay fast and work offline. **When the model needs more** it calls the memory tools. The MCP server is the HarnessLink service's own (`superpi mcp`). Its tools include `memory_search` (search your memory across projects and machines), `memory_get` (read one entry in full), `memory_bank` (record a decision or outcome), `context_brief` (a budgeted brief of the project), `session_list` and `session_get`. **Near the context limit** the extension tells you to start a new session with `/new`, and saves a handoff before omp compacts. ## Limits - Org model rules and usage limits apply to omp's Anthropic and OpenAI Codex providers, the two the gateway routes. ## Guides - [Installing HarnessLink](https://harnesslink.sh/docs/install): The full HarnessLink install guide: requirements, Windows, install options, verifying, the first-run onboarding, updating, troubleshooting and uninstalling. - [Memory Banking](https://harnesslink.sh/docs/memory-banking): How HarnessLink turns each finished turn in omp, Claude Code, Codex, pi and Antigravity into a Markdown memory entry, when banking runs, and what reads it. - [What HarnessLink captures from each harness](https://harnesslink.sh/docs/multi-harness): What HarnessLink captures from omp, Claude Code, Codex, pi, Antigravity and Cursor after setup, and how it stays a controller rather than a harness. ## Other harnesses - [Claude Code](https://harnesslink.sh/harnesses/claude-code): Hooks, MCP memory tools, gateway and autobank - [Codex](https://harnesslink.sh/harnesses/codex): Hooks, MCP memory tools, gateway and autobank - [pi](https://harnesslink.sh/harnesses/pi): Transcripts, autobank and gateway - [Antigravity](https://harnesslink.sh/harnesses/antigravity): Transcripts and one memory entry per conversation - [Cursor](https://harnesslink.sh/harnesses/cursor): MCP memory tools, by hand; chats not captured [All harnesses](https://harnesslink.sh/harnesses) · [Install guide](https://harnesslink.sh/docs) · [Pricing](https://harnesslink.sh/pricing) · [Integrations](https://harnesslink.sh/integrations) --- Source: https://harnesslink.sh/harnesses/pi # HarnessLink for pi HarnessLink captures pi's prompts and transcripts, banks every finished turn into the memory your other harnesses search, and routes pi's Anthropic and OpenAI Codex calls through the local gateway. pi has no hooks HarnessLink can use, so memory does not flow back into a pi session. ## What HarnessLink captures from pi | Feature | In pi | Details | | --- | --- | --- | | Prompt history | Yes | Your prompts, read from the session transcripts. | | Session transcripts | Yes | `~/.pi/agent/sessions//*.jsonl`, uploaded moments after they change. | | Memory bank (autobank) | Yes | Every finished turn becomes a memory entry, plus todo, plan and checkpoint snapshots. | | Gateway routing | Yes | `providers.anthropic.baseUrl` and `providers.openai-codex.baseUrl` in `~/.pi/agent/models.json`. | | Context hooks | No | pi has no hook HarnessLink can install. | | Memory tools (MCP) | No | There is no MCP preset for pi. | | Org policy rules | No | Not enforced: pi has no tool hook. | | Skills from templates | Yes | `hnl add ` installs into `~/.pi/agent/skills`; pi also reads `~/.agents/skills`. | | Resume in another harness | Yes | `hnl resume` reopens a pi session through omp. | ## Set up pi 1. Install HarnessLink on macOS or Linux ([Windows](https://harnesslink.sh/docs#windows) has its own one-liner). ``` curl -fsSL https://harnesslink.sh/install.sh | bash ``` 2. Sign in once in your browser; setup then turns on what each harness on the machine supports. ``` hnl cloud setup ``` 3. Or turn the pieces on one at a time. ``` hnl gateway connect pi hnl cloud harnesses enable pi hnl cloud autobank enable pi ``` 4. Check what is connected: plain `hnl` shows, for each harness, the gateway, transcripts, autobank, context and memory tools. ``` hnl ``` ## How memory reaches pi HarnessLink does not add memory to a pi session: pi has neither context hooks nor an MCP preset. What you do in pi still counts. Every finished turn is banked, so Claude Code, Codex and omp find it through their hooks and memory tools, and it shows on the dashboard's Memory and History pages. ## Limits - No context hooks and no MCP memory tools in pi. - Org policy rules are not enforced in pi. Model rules and usage limits apply to its Anthropic and OpenAI Codex providers through the gateway. ## Guides - [Using HarnessLink](https://harnesslink.sh/docs/usage): Using HarnessLink day to day: Ask, history, policies, shared memory, resuming sessions across harnesses, profile sync, templates, delegation, runs and cost. - [Memory Banking](https://harnesslink.sh/docs/memory-banking): How HarnessLink turns each finished turn in omp, Claude Code, Codex, pi and Antigravity into a Markdown memory entry, when banking runs, and what reads it. - [What HarnessLink captures from each harness](https://harnesslink.sh/docs/multi-harness): What HarnessLink captures from omp, Claude Code, Codex, pi, Antigravity and Cursor after setup, and how it stays a controller rather than a harness. ## Other harnesses - [Claude Code](https://harnesslink.sh/harnesses/claude-code): Hooks, MCP memory tools, gateway and autobank - [Codex](https://harnesslink.sh/harnesses/codex): Hooks, MCP memory tools, gateway and autobank - [omp](https://harnesslink.sh/harnesses/omp): Context extension, MCP memory tools, gateway and autobank - [Antigravity](https://harnesslink.sh/harnesses/antigravity): Transcripts and one memory entry per conversation - [Cursor](https://harnesslink.sh/harnesses/cursor): MCP memory tools, by hand; chats not captured [All harnesses](https://harnesslink.sh/harnesses) · [Install guide](https://harnesslink.sh/docs) · [Pricing](https://harnesslink.sh/pricing) · [Integrations](https://harnesslink.sh/integrations) --- Source: https://harnesslink.sh/harnesses/antigravity # HarnessLink for Antigravity HarnessLink reads what the Antigravity CLI (`agy`) writes: your prompts, each conversation's transcript and its summary, banked as one memory entry per conversation. Antigravity's model traffic goes straight to Google and it has no hooks or MCP preset, so HarnessLink does not route or add to its sessions. ## What HarnessLink captures from Antigravity | Feature | In Antigravity | Details | | --- | --- | --- | | Prompt history | Yes | `~/.gemini/antigravity-cli/history.jsonl`. | | Session transcripts | Yes | `~/.gemini/antigravity-cli/brain//.system_generated/logs/transcript_full.jsonl`, uploaded moments after it changes. Sub-agent conversations stay out. | | Memory bank (autobank) | Partly | One entry per conversation, from Antigravity's conversation summaries, not one per turn. | | Gateway routing | No | Not supported: signed-in traffic goes directly to Google. | | Context hooks | No | Not available. | | Memory tools (MCP) | No | There is no MCP preset for Antigravity. | | Org policy rules | No | Not enforced: there is no documented tool hook. | | Skills from templates | Yes | `hnl add ` installs into `~/.gemini/antigravity-cli/skills`. | | Resume in another harness | No | `hnl resume` does not offer Antigravity sessions. | ## Set up Antigravity 1. Install HarnessLink on macOS or Linux ([Windows](https://harnesslink.sh/docs#windows) has its own one-liner). ``` curl -fsSL https://harnesslink.sh/install.sh | bash ``` 2. Sign in once in your browser; setup then turns on what each harness on the machine supports. ``` hnl cloud setup ``` 3. Or turn the pieces on one at a time. ``` hnl cloud harnesses enable antigravity hnl cloud autobank enable antigravity ``` 4. Check what is connected: plain `hnl` shows, for each harness, the gateway, transcripts, autobank, context and memory tools. ``` hnl ``` ## How memory reaches Antigravity HarnessLink does not add memory to an Antigravity session: there are no hooks or MCP preset to do it with. Each conversation is banked as one entry, so Claude Code, Codex and omp can find what you did in Antigravity, and the dashboard shows the conversation as turns: your words, its thinking, each tool call and the answer. ## Limits - No gateway routing, so no usage records, model rules or usage limits for Antigravity. - No context hooks, MCP memory tools or org policy rules. - Autobank writes one entry per conversation, not one per turn. ## Guides - [Using HarnessLink](https://harnesslink.sh/docs/usage): Using HarnessLink day to day: Ask, history, policies, shared memory, resuming sessions across harnesses, profile sync, templates, delegation, runs and cost. - [Memory Banking](https://harnesslink.sh/docs/memory-banking): How HarnessLink turns each finished turn in omp, Claude Code, Codex, pi and Antigravity into a Markdown memory entry, when banking runs, and what reads it. - [What HarnessLink captures from each harness](https://harnesslink.sh/docs/multi-harness): What HarnessLink captures from omp, Claude Code, Codex, pi, Antigravity and Cursor after setup, and how it stays a controller rather than a harness. ## Other harnesses - [Claude Code](https://harnesslink.sh/harnesses/claude-code): Hooks, MCP memory tools, gateway and autobank - [Codex](https://harnesslink.sh/harnesses/codex): Hooks, MCP memory tools, gateway and autobank - [omp](https://harnesslink.sh/harnesses/omp): Context extension, MCP memory tools, gateway and autobank - [pi](https://harnesslink.sh/harnesses/pi): Transcripts, autobank and gateway - [Cursor](https://harnesslink.sh/harnesses/cursor): MCP memory tools, by hand; chats not captured [All harnesses](https://harnesslink.sh/harnesses) · [Install guide](https://harnesslink.sh/docs) · [Pricing](https://harnesslink.sh/pricing) · [Integrations](https://harnesslink.sh/integrations) --- Source: https://harnesslink.sh/harnesses/cursor # HarnessLink for Cursor Cursor support is partial. You can register HarnessLink's MCP server in Cursor by hand, so its model can search and read the memory your other harnesses bank, and HarnessLink syncs `~/.cursor/sessions/*.jsonl` and `~/.cursorrules`. Cursor's chats live in an editor database HarnessLink does not read, so they are not captured or banked. ## What HarnessLink captures from Cursor | Feature | In Cursor | Details | | --- | --- | --- | | Prompt history | No | Not captured: Cursor keeps chats in an editor database HarnessLink does not read. | | Session transcripts | Partly | `~/.cursor/sessions/*.jsonl` only. | | Memory bank (autobank) | No | Not supported. | | Gateway routing | No | Not routed. | | Context hooks | No | Not available. | | Memory tools (MCP) | Partly | `mcpServers.superpi` in `~/.cursor/mcp.json`, registered by hand; setup does not do it for you. | | Org policy rules | No | Not enforced: there is no tool hook. | | Skills from templates | Yes | `hnl add ` installs into `~/.cursor/skills`; Cursor also reads `~/.agents/skills`, `~/.claude/skills` and `~/.codex/skills`. | | Resume in another harness | No | `hnl resume` does not offer Cursor sessions. | ## Set up Cursor 1. Install HarnessLink on macOS or Linux ([Windows](https://harnesslink.sh/docs#windows) has its own one-liner). ``` curl -fsSL https://harnesslink.sh/install.sh | bash ``` 2. Sign in once in your browser; setup then turns on what each harness on the machine supports. ``` hnl cloud setup ``` 3. Register the MCP memory tools in Cursor yourself; setup does not. ``` hnl mcp register --harness=cursor --yes ``` 4. Sync Cursor's session files and `~/.cursorrules` if setup did not turn that on. ``` hnl cloud harnesses enable cursor ``` ## How memory reaches Cursor **Through the memory tools**, once registered. The MCP server is the HarnessLink service's own (`superpi mcp`). Its tools include `memory_search` (search your memory across projects and machines), `memory_get` (read one entry in full), `memory_bank` (record a decision or outcome), `context_brief` (a budgeted brief of the project), `session_list` and `session_get`. Nothing is added to a Cursor chat on its own: Cursor has no hooks HarnessLink can use, so the model reaches memory only when it calls a tool. ## Limits - Cursor prompts and chats are not captured or banked. - No gateway routing, context hooks or org policy rules. ## Guides - [Using HarnessLink](https://harnesslink.sh/docs/usage): Using HarnessLink day to day: Ask, history, policies, shared memory, resuming sessions across harnesses, profile sync, templates, delegation, runs and cost. - [Installing HarnessLink](https://harnesslink.sh/docs/install): The full HarnessLink install guide: requirements, Windows, install options, verifying, the first-run onboarding, updating, troubleshooting and uninstalling. - [What HarnessLink captures from each harness](https://harnesslink.sh/docs/multi-harness): What HarnessLink captures from omp, Claude Code, Codex, pi, Antigravity and Cursor after setup, and how it stays a controller rather than a harness. ## Other harnesses - [Claude Code](https://harnesslink.sh/harnesses/claude-code): Hooks, MCP memory tools, gateway and autobank - [Codex](https://harnesslink.sh/harnesses/codex): Hooks, MCP memory tools, gateway and autobank - [omp](https://harnesslink.sh/harnesses/omp): Context extension, MCP memory tools, gateway and autobank - [pi](https://harnesslink.sh/harnesses/pi): Transcripts, autobank and gateway - [Antigravity](https://harnesslink.sh/harnesses/antigravity): Transcripts and one memory entry per conversation [All harnesses](https://harnesslink.sh/harnesses) · [Install guide](https://harnesslink.sh/docs) · [Pricing](https://harnesslink.sh/pricing) · [Integrations](https://harnesslink.sh/integrations)