Skip to content
Logo

Install

macOS, Linux, and Windows. Homebrew on macOS and Linux; Scoop on Windows; a plain release zip anywhere, or cargo-binstall where a Rust toolchain already exists.

brew install tenequm/tap/pond

Windows

Scoop is the Windows channel:

scoop bucket add tenequm https://github.com/tenequm/scoop-bucket
scoop install tenequm/pond

Buckets are git clones, so scoop bucket add needs git on PATH - if it fails with "Git is required for buckets", run scoop install git and retry. No Scoop yet? Install it first, from a normal (non-admin) PowerShell - its installer refuses an elevated shell, and it lives entirely in your user profile. It needs an execution policy of RemoteSigned or looser:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force
irm get.scoop.sh | iex

Scoop installs pond as a portable zip: the shim puts pond on PATH, the bucket updates itself from each GitHub release, and scoop update pond upgrades in place. What it fetches is pond-x86_64-pc-windows-msvc.zip (~77 MB download, ~223 MB unpacked), attached to every release. No Scoop at all? Unpack that zip anywhere, put the directory on PATH, and you are done - nothing else to install. The build is x86_64; on Windows 11 on ARM it installs and runs under the built-in x64 emulation (Windows 10 on ARM has no x64 emulation, and Scoop resolves it to a 32-bit entry this manifest does not carry). winget is not available yet - the manifest is in review; winget install tenequm.pond starts working once it merges.

Already have a Rust toolchain? cargo binstall pond-db fetches the same prebuilt zip with no git, protoc, or NASM involved - but it installs pond.exe only, so scheduled sync (which runs through pondw.exe) needs the Scoop or zip install.

Installed with an agent session already running? The new PATH entry reaches only processes started after the install - open a fresh terminal (and restart the agent client) if pond reports not found.

The zip carries completion scripts for PowerShell, bash, zsh, and fish. Register the PowerShell one by dot-sourcing it from your $PROFILE; with Scoop the file is at ~\scoop\apps\pond\current\completions\_pond.ps1. On a fresh machine $PROFILE may not exist yet - create it first with if (!(Test-Path $PROFILE)) { New-Item -ItemType File -Path $PROFILE -Force | Out-Null } (a bare New-Item -Force would truncate an existing profile).

Building from source instead needs two tools the prebuilt binary spares you: protoc, because protobuf-src cannot vendor it on Windows, and NASM, for aws-lc-sys. Embeddings, if you enable them, run on the CPU backend.

Scheduled sync

pond schedule start registers a Task Scheduler job. Run it from a normal shell, not an elevated one: a task registered elevated is owned by Administrators, and every later pond schedule start/stop from a normal shell fails with Access denied (pond warns before registering elevated, and the error names the recovery if you're already caught). After moving pond between install channels - a manual zip to Scoop, say - run pond schedule start once so the task points at the new binaries; pond status flags a registration whose launcher no longer exists.

Over SSH

A bucket install's shim works over SSH - pond resolves and spawns from remote PowerShell, cmd, and Git Bash sessions alike (inside WSL, call it as pond.exe: interop appends the Windows PATH but does not infer the extension). If yours fails with "Could not create process" while local shells work fine, the shim itself is stale - seen once with a shim created by a hand-pinned manifest install - and reinstalling from the bucket (scoop uninstall pond; scoop install tenequm/pond) regenerates it. As a stopgap, call the exe directly: ~\scoop\apps\pond\current\pond.exe.

Defender and where the store lives

A pond store is many small files, and Defender's real-time scanning charges per file touched - excluding pond's directory (%LOCALAPPDATA%\pond by default, holding the store, cache, and state) is worth it if sync or search feels slow. Keep the store on an NTFS volume: local stores commit through a hard-link-and-rename dance that NTFS documents and pond has verified there, while ReFS volumes - including Dev Drive - are unverified for that path. A UNC path is rejected outright at the store URL, because the layers underneath silently drop the host component and the store would open somewhere else; a mapped network drive has the same fault but cannot be told apart from a local drive, so pond cannot reject it for you - point the store at a local drive or a remote scheme (s3://, gs://, az://).

Long paths

The Windows binary ships a manifest declaring long-path awareness, which only takes effect on machines where the LongPathsEnabled policy is also set. Nothing in pond's own path handling depends on it - it is insurance for the bundled C libraries and for tools pond spawns. Cloning this repository is the one case that genuinely needs it, and needs it in git rather than in pond: git config --global core.longpaths true - some test fixtures nest encoded project slugs past 260 characters. Build and test from a clone with an explicit --target x86_64-pc-windows-msvc; without it cargo applies the repo's +crt-static flag to build scripts and proc-macros too, which then fail to load.

WSL

Running the Linux binary under WSL works when both the agent session files and the pond store live on the ext4 side. Do not point either across /mnt/c: throughput collapses and Windows-side writes are missed.

Updating

brew upgrade pond / nix profile upgrade pond / scoop update pond / cargo binstall pond-db (re-run) / a fresh zip - and pond --version to check what you're on. Keep every machine that writes to a shared store on the same version: a store-schema release migrates the store in place, after which older binaries stop syncing until they upgrade (see Several machines, one bucket).

Next: Quickstart.