coordigent

Coordigent npm launcher

Runs Coordigent's coord CLI from npm:

npx coordigent connect        # once, or:
npm i -g coordigent && coordigent connect

(Not on npm yet: package.json stays "private": true until the trusted publisher is set up; see Publishing.)

The package holds one Node file and no binaries. On first run it downloads coord and coord-mcp for this machine from the server's /install/<artifact>, checks each against the SHA-256 published in /install/version, and puts them where the installers do. After that, and on every later run, it runs coord with the same arguments and exits with its exit code. Because the binaries live where install.sh puts them, coord update and every MCP config keep working unchanged.

• Platforms: macOS arm64 and x64 (an x64 Node under Rosetta gets the arm64 build), glibc Linux x64 and arm64, Windows x64. Anything else, and Alpine/musl, exits 1 before downloading.
• Where: ~/.tower/bin, or %LOCALAPPDATA%\Coordigent\bin on Windows (as install.ps1). TOWER_BIN_DIR overrides both. The directory is not added to PATH; coordigent <command> is.
• Which server: COORDIGENT_SERVER_URL, then TOWER_SERVER_URL, then the serverUrl saved in ~/.tower/config.json, then https://coordigent.com: the order coord itself uses. A machine with no config yet gets one naming that server, with no token, as install.sh writes.
• Checks: both binaries are downloaded and checked before either is written, so a refusal leaves nothing installed. A digest mismatch, a 429 from the per-address download limit ("Try again in N minute(s)") and an unreachable server each exit 1 with one message. A server that publishes no checksum installs with an "installing unverified" warning, as install.sh does. What the checksums do and do not protect against is in docs/operations.md.
• No install scripts. Nothing runs at npm install; --ignore-scripts changes nothing.

Maintaining it

Tests: bun test packaging/npm from the repo root (a local fake server stands in for /install). CI runs npm pack --dry-run on it (.github/workflows/ci.yml, job npm-package) and fails if the tarball holds anything but bin/coordigent.js, README.md and package.json, or gains an install-time script. Both that check and the release checks are scripts/release-checks.js, which is not shipped.

Publishing

.github/workflows/publish-npm.yml publishes on a tag npm-v<version> (the v* tags publish the container image and never touch npm), or by hand from Actions with an existing tag. It uses npm trusted publishing: no NPM_TOKEN; npm trades the job's GitHub OIDC token for a one-time credential, and npm publish --provenance --access public attaches a provenance statement. Before publishing, scripts/release-checks.js release <tag> refuses, with the reason, when:

• the tag is not exactly npm-v plus package.json's version;
• the name is not coordigent;
• package.json still has "private": true. It stays until the steps below are done, so until then every run of the workflow fails at that check and publishes nothing.

Turning it on (Ali, once)

• On npmjs.com, sign in as the account that will own coordigent, with two-factor authentication on. (npm view coordigent returned 404 on 2026-10-17: the name was free.)
• npmjs.com sets a trusted publisher on the package's own settings page, so the package must exist first. If coordigent is not yet on npm, publish the current version once by hand: in a clean checkout of main, cd packaging/npm, delete the "private": true line locally (do not commit it), run npm publish --access public and approve with 2FA, then git checkout package.json. That one version has no provenance; every later one does.
• Open npmjs.com → coordigent → Settings → Trusted Publisher, choose GitHub Actions, and enter: organization or user startupproj, repository coordigent, workflow filename publish-npm.yml, environment empty. Save.
• On the same page, under Publishing access, choose Require two-factor authentication and disallow tokens. Trusted publishing still works; a leaked token cannot publish.
• Open a PR that removes "private": true from packaging/npm/package.json, and bumps version if step 2 published the current one. Merge it.
• Tag the merge commit and push the tag: git tag npm-v<version> <commit> && git push origin npm-v<version>. The workflow publishes; the version page on npmjs.com then shows its provenance, linked to that run.

Each later release: bump version in a PR, merge, push npm-v<version>.