ORG2 offers six download links and not one of them is pinned to a version

Six download links and not one of them is pinned to a version

The top of the page is a row of direct download links covering five platforms in six formats: a disk image for macOS on Apple silicon, a Windows installer, a Windows MSI, a Linux AppImage and a Debian package. Every one of those links points at the repository's latest release URL rather than at a numbered release, and every filename in them contains the word latest as well. So the page has no way to express a version, and a reader who downloads today and a reader who downloads next month get different builds from the same link. That is fine for a project that wants people on the newest build, and it is wrong for a team that needs to say which build a colleague is running. The one concession to pinning is a separate link to the full asset list of the latest release, which at least lets a reader see what else exists.

The counts disagree about how many agents are supported

The page describes the same capability four times and gives four numbers. The repository description says a built-in harness and twenty or more command line tools. One feature card says sessions can be managed across ten or more applications and tools. Another says replay works from the native harness and fifteen or more command line agents. And the visible support list names nine: its own harness plus the command line tools of Cursor, Claude Code, Codex, Kiro, GitHub Copilot, OpenCode and DeepSeek Harness, with the list continuing past what the page shows. None of those numbers is wrong on its own terms, and together they mean a reader cannot use the page to answer the question they are probably asking, which is whether the agent they already use is on the list.

The manifest is one patch behind the newest release

The package manifest declares version 2.0.8. The newest release is 2.0.9, published three days before the manifest's last commit, and the two before it are a patch and a release six days apart in total. So the tree sits one patch behind its own tag, which is the opposite of the more common pattern where the manifest runs ahead of the last release and the release catches up later. For a desktop application distributed as downloaded binaries it barely matters, since users get a release, not a branch. For anyone building from source, or for a script that reads the manifest to decide what to install, it means the manifest is not a reliable statement of the current version and the tag list is.

The package is named for something else entirely

The product is called ORG-2 in the heading, ORG2 in the description and the repository name, and its internal package is named with a spelling that appears nowhere else on the page. The manifest's name field uses that spelling, its description names the product, and the repository root carries a hidden directory whose name matches the package rather than the product. There is also an archive directory at the root, which is the place where code that is no longer shipped but not yet deleted tends to accumulate. None of this is a problem for a user, and all of it makes the repository harder to search for, since the name people hear, the name the package carries and the name the repository uses are three different strings.

Two bundlers are maintained side by side

The script list has development and build entries for two different bundlers. One set runs a webpack development server, the other runs a bundler that is not webpack through its own server script, and the Tauri launch commands exist for each. There are also two development modes layered on top: a light mode that sets two environment variables and disables source maps, and a mobile mode that sets a remote native flag and reuses the same server. So a contributor has three axes to choose from rather than one, and the script names are the only documentation for what the axes mean. For a project whose pitch is that a team runs its agents together, a build with that many modes is a fair amount of surface for a repository whose visible product is a single desktop binary.

Python scripts download the sidecar binaries

Two scripts in the list are Python and they both download things: one fetches something generic and one fetches sidecars, which in a desktop application means the helper executables the main binary shells out to. Meanwhile the rest of the toolchain is Node and Rust, and the container-free build path starts by deleting the build directory and the bundler cache before running the production bundler. There is also a shell script for monitoring processor use during development and a diagnostics tool with its own test suite run by Node's built-in test runner. A build that mixes three languages is not unusual for a desktop application, and each addition raises the bar for a contributor's machine, which is why the sidecar step is worth noticing: it means a build can fail on a network or antivirus problem rather than on anything in the source.

Sixteen readmes, a half empty grid, and an unfinished column

The translation row at the top links sixteen readme files, covering both simplified and traditional Chinese plus fourteen other languages, all under a documentation directory rather than at the repository root. The feature grid below it is a two column table where the second column is empty in all eight rows, so half the table renders as whitespace; it reads as a grid that was half built and then abandoned rather than a layout. The capabilities list below that mixes shipped features with work in progress, marking only the self-hosted database collaboration line as unfinished and leaving the organisational alignment surfaces unmarked. A reader scanning quickly will reasonably assume all ten items in that list work today.

Editorial conclusion

Use ORG2 if you want a record of how your coding agents actually worked, replayable and commentable, rather than only the diff they left, because that is the one thing it does that a pull request viewer cannot. Three things to know before you adopt it. Pin a downloaded artefact yourself, because none of the page's links names a version and every one of them resolves to whatever shipped last. Treat the agent support list as a moving claim rather than a compatibility table, since the page counts its supported tools three different ways and the list was still growing when it was written. And note that the parts of the pitch around organisational alignment are marked as unfinished or unmarked, so the session record is the product and the rest is direction.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes