Install & init
The current release is v9.0.2. Haft runs locally and plugs into an existing coding agent. Claude Code and Codex are the stable v9 hosts.
Install the binary
curl -fsSL https://raw.githubusercontent.com/m0n0x41d/haft/main/install.sh | bash
The installer places haft in a writable binary directory,
normally ~/.local/bin. v9 has no Elixir, OTP, BEAM, or bundled
agent-runtime requirement.
Initialize one new project
cd /path/to/project
haft init # interactive host selection in a terminal
haft init --claude # Claude MCP, skills, and CLAUDE.md section
haft init --codex # Codex MCP, skills, and AGENTS.md section
haft init --core-only # project memory only; no host setup
haft init --all # both stable host integrations
In a terminal, bare haft init opens a host picker with nothing
preselected. Scripts and CI must pass an explicit flag; Haft fails before
writing rather than guessing. See host setup
for project-local skills and experimental adapters.
Restart the host after init or upgrade. A running MCP process keeps using the binary and skill catalog it already loaded.
Upgrade an initialized project
Install the new binary and fully restart or reconnect the coding-agent
host. The new haft serve process applies only project-ledger
migration boundaries that the release explicitly declares startup-safe.
The current 57 -> 58 transition first publishes a verified
private SQLite snapshot beside the ledger. A current database is not
rewritten and no backup is created.
Do not re-run haft init after every release just to maintain the
database. Re-init remains the operation for bootstrap, changing host
targets, or refreshing Haft-owned skills and managed instruction carriers.
If startup reports a manual chain, use the exact
haft project migrate command in that diagnostic; missing
binding, future schema, integrity, and stale WAL/SHM states have separate
recovery instructions.
Verify the connection
haft version
haft doctor
Fully restart the coding agent, open the project again, and ask for
/h-status. Restart matters: an already running MCP process keeps
the old binary and skill catalog in memory even after the files on disk
change.
Already on v9.0.0 or v9.0.1?
Upgrade to v9.0.2 and run haft init once for the host you use.
From v9.0.0, this also applies database migration 58, which removes legacy
affected_files rows that v9's project-relative path rule cannot
represent. v9.0.2 also fixes conventional monorepo scope detection; the v9
capability and authority boundaries are unchanged.
Upgrading from v8.1?
Stop Haft writers and back up both the project .haft/ directory
and ~/.haft/projects/<project-id>/haft.db before the first v9
start. The database migration is forward-only across this boundary.
After a successful install, v9 removes only
~/.haft/runtimes/open-sleigh/current. It preserves
~/.open-sleigh/ user data and
~/.haft/runtimes/haft-embed/. Migrate scripts that call
haft run or haft harness to work performed by the
host agent or by a separately operated runner.
Follow the complete v8.1 to v9.0 migration and rollback guide before opening a working project ledger with v9.