coordigent

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)

• 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>. 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").