Coordigent npm launcher

Coordigent's coord CLI and coord-mcp MCP server, from npm:

npm i -g coordigent
coord connect

npm i -g coordigent puts three commands on PATH: coord runs coord, coord-mcp runs coord-mcp, and coordigent runs coord (or coord-mcp with mcp first, below). So every coord … command in the docs works as written. Without installing: npx coordigent connect.

As an MCP server (stdio), for any MCP client, and the npm entry of the MCP Registry listing:

{ "mcpServers": { "coordigent": { "command": "npx", "args": ["-y", "coordigent", "mcp"] } } }

coord-mcp [args], and coordigent mcp [args], run coord-mcp [args] after the same first-run download and checks. Everything the launcher prints goes to stderr, so stdout stays the MCP channel. coord-mcp reads the login from ~/.tower/config.json (npx coordigent login) and the repo from the folder it starts in, or COORDIGENT_REPO.

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 (or coord-mcp) 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 %USERPROFILE%\.coordigent\bin on Windows (as install.ps1). TOWER_BIN_DIR overrides both. The launcher never edits PATH: npm's global bin folder, already on it, holds the coord, coord-mcp and coordigent commands, which run the binaries there.
• Which bin runs what: each bin is its own file: bin/coord.js always runs coord, bin/coord-mcp.js always runs coord-mcp, and bin/coordigent.js (the launcher itself) reads mcp from its first argument. Not one file checking the name it was run as: on Windows npm's .cmd shim runs node <bin file>, so the file is all that says which command was typed.
• Next to install.sh: a coord from the installer (~/.tower/bin) and one from npm can both be on PATH. Whichever comes first starts, and both run the same ~/.tower/bin/coord, so it does not matter which. An npm global prefix of ~/.tower would link npm's coord into the folder the binaries go in; the launcher refuses that with a message rather than run itself.
• Updating and removing: coord update updates the binaries, as for any install; npm update -g coordigent updates only this launcher. To remove everything, coord uninstall first (binaries, hooks, ~/.tower), then npm rm -g coordigent. Removing only the package leaves the binaries in place, and running npm's coord after coord uninstall downloads them again.
• 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, bin/coord.js, bin/coord-mcp.js, LICENSE (MIT), README.md and package.json, if bin does not map coord, coord-mcp and coordigent to those three files, if any of them is not executable, or if it gains an install-time script. The tests also pack the package and npm i -g the tarball into a scratch prefix, then run each linked command. 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 --access public publishes it (no provenance: npm only attests public source repos, and this repo is private). 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;
• mcpName is not com.coordigent/coordigent, which the MCP Registry reads from the published version to accept the listing's npm entry;
• 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)

1. 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.)
2. 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.
3. 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.
4. On the same page, under Publishing access, choose Require two-factor authentication and disallow tokens. Trusted publishing still works; a leaked token cannot publish.
5. Open a PR that removes "private": true from packaging/npm/package.json, and bumps version if step 2 published the current one. Merge it.
6. 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>. Bump version and packages[0].version in the root server.json in the same PR (a test holds them equal), and after npm has published, publish the listing (docs/operations.md, "MCP Registry").