HarnessClaw ships three installers, updates itself, and skips Linux entirely

Three artifacts are published and none of them is for Linux

The download table is the clearest statement of what this project supports. There are three ready-to-run builds: `HarnessClaw-<version>-mac-arm64.dmg` for Apple Silicon, `HarnessClaw-<version>-mac-x64.dmg` for Intel Macs, and `HarnessClaw-<version>-win-x64.exe` for Windows on x64.

Both Mac architectures are covered separately, so a Retina laptop and an older Intel machine are not left to run under emulation. What is missing is Linux entirely, and the gap is not only in the table. The build scripts offer `yarn dist:mac` and `yarn dist:win` as the platform-specific targets, and no Linux counterpart appears next to them, so there is no documented path to produce one either.

The naming convention is worth noting if you script a download: the version segment is substituted into the filename, and the product name is capitalized as HarnessClaw while the package name in package.json stays lowercase as harnessclaw.

An rpm or AppImage is not offered for the same reason, and the getting-started section reinforces the point: building from source is described as needed only for development. A user who wants to run the app, not modify it, is expected to use a prebuilt artifact.

Installed builds replace themselves, so the version you run is not the one you downloaded

The download section says installed builds update themselves: the app checks for new releases on start and installs them in the background, so you only need to download once.

That is convenient and it removes your ability to stay on a known version. There is no documented in-app way to pin a release, no changelog picker, and no mention of a way to turn the check off.

The build scripts make the publishing side visible. `yarn dist` runs prepare, build, and then electron-builder with `--publish never`, so a local package never touches the release feed. `yarn release` runs the same chain with `--publish always`. Only the second one can move the tag that the startup update check then finds, which is why the two are kept as separate scripts rather than one script with a flag.

Two electron-builder config files exist and every script points at the .cjs one

The repository root contains `electron-builder.config.cjs` and, next to it, `electron-builder.yml`. Both are electron-builder configuration, and electron-builder would normally discover one of them on its own.

Every script in package.json overrides that discovery by naming the config file explicitly. The dist script, the mac target, the win target, and the release script all pass `--config electron-builder.config.cjs`, so the `.yml` is never the file being read when a build runs.

Nothing in the README mentions either file. If you are changing packaging behaviour, the config you want is the `.cjs` one, and the `.yml` sitting beside it is either a leftover or a reference copy that will drift silently.

Development mode is a separate entry point again: `yarn dev` runs electron-vite dev, and `yarn preview` runs electron-vite preview on the built output. Linting is `eslint . --ext .ts,.tsx`, and the project splits its TypeScript configuration three ways, with tsconfig.json alongside tsconfig.node.json and tsconfig.web.json for the Electron main process and the renderer.

The SQLite dependency is a fork and a native module, so install does more than download

The database line in the tech stack names Better SQLite3, and the link points at `github.com/JoshuaWise/better-sqlite3`, a fork rather than the upstream project. That detail matters more than it looks, because a native module has to be compiled or fetched per platform and per Electron ABI.

The install chain reflects that. `postinstall` runs `electron-builder install-app-deps`, so a plain `yarn install` already rebuilds native dependencies against the Electron version. A separate `ensure:electron-native` script runs a helper from scripts/, and `dev:vscode` chains that script in front of `yarn dev` for one specific editor setup.

git clone https://github.com/harnessclaw/harnessclaw.git
cd harnessclaw
yarn install

The binary preparation scripts are per platform too: `prepare:bin:mac:arm64`, `prepare:bin:mac:x64`, and `prepare:bin:win:x64` all exist, and `prepare:bin:release` passes an engine source flag that the default does not. There is a `bundle:tools` script as well, so bundled executables are a separate build concern from the packaged app.

package.json is still on a beta version and one release tag is not semver

The version field in package.json reads `0.0.24-beta.0`. The most recent listed release is tagged v0.0.24-beta.0 and dated 2026-07-02, and the default branch was last pushed on 2026-08-27. So the version in the manifest has not moved while commits have continued to land.

The release list also contains a tag called `statistic-2026-06`, which is not a semantic version at all. It sits in the same tag namespace as v0.0.23 and v0.0.24-beta.0, so any tooling that assumes every tag parses as semver, including a version resolver walking the tag history, has to cope with it.

For a changelog there is a directory and two scripts rather than a single file: `changelog:extract` and `changelog:build` run helpers from scripts/, and the root holds both CHANGELOG.md and CHANGELOG_zh.md alongside a `changelog/` directory.

The reward workflow creates tags and comments with the default GITHUB_TOKEN

HarnessClaw pays for contributions through an issue template and three automation steps. You open an issue with the `Reward Task` template and state the bounty amount and currency. When a linked pull request closes that issue and is merged, GitHub Actions creates a `reward-<issue-number>` tag and comments the split result on the issue. On the first day of each month, Actions aggregates the previous month's reward tags and publishes a `statistic-YYYY-MM` release summary.

The last line of that section is the one to weigh. The automations use the default `GITHUB_TOKEN`, and the README states that no extra personal access token is required for the current workflows. That is a deliberate simplification: workflow permissions then come from the repository's default token settings rather than from a stored secret.

The monthly `statistic-YYYY-MM` release is also where the non-semver tag comes from, which connects the reward process directly to the versioning problem above.

Both kinds of tag also share a namespace with the `reward-<issue-number>` tags the same workflow creates, so the repository's tag list mixes semver, monthly statistics, and per-issue rewards in one place.

Three top-level documents are bilingual and one support channel has no link

The repository keeps parallel documentation in two languages at the root: README.md and README_zh.md, CHANGELOG.md and CHANGELOG_zh.md, CONTRIBUTING.md and CONTRIBUTING_zh.md. The contributing guide is the substantial one, covering setup, a first pull request, commit rules, and the paid reward tasks, and the release rules for commits, releases, and the changelog live separately in docs/release-rules.md.

The support section lists three channels. Community discussion points at GitHub Discussions and bug reports point at Issues. The third is a WeChat Work Group, and the bullet has no link or handle attached to it, so there is no way to reach it from the README.

The README also asks readers to star the repository and says plainly why: it is how new people find the project. That is worth weighing when you read the feature list, which is five bullets long and pairs an agent manager, a chat interface, ClawHub skill discovery, session tracking, and a settings page.

Editorial conclusion

HarnessClaw is a sensible choice if you are on macOS or Windows and want one window for agent sessions, skills from ClawHub, and chat, and you are willing to let the app replace itself in the background. It is the wrong choice on Linux, where no artifact is published and the build scripts carry no Linux target, and it is a poor fit if you need a pinned version, because the installed build checks for new releases on start and installs them itself. Before you trust it with agent work, look at what the self-update path does and whether you want a signed artifact, confirm your platform's native module rebuild succeeds, since the SQLite dependency is a fork and a native module at that, and remember that package.json is still carrying a beta version.

Frequently asked questions

Official sources

1. harnessclaw/harnessclaw on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases