OpenSpec 1.15 ships standalone binaries and update previews

A release about installation and change review

OpenSpec published version 1.15.0 at 00:50 UTC on October 24, 2026, adding standalone binaries that do not require Node.js and an update preview for AI coding integrations. Teams maintaining common procedures across assistants should trial it on a sample repository and review its plan before allowing writes to a working project.

This October 26 report covers the October 24 release, rather than presenting it as a release from today. OpenSpec is a command-line product. Its actual feature interface is a terminal session, not a newly invented graphical editor.

Standalone installation removes one prerequisite

OpenSpec organizes specifications and proposed changes before implementation by an AI assistant. Version 1.15 adds binaries for macOS, Linux and Windows, on x64 and ARM64; Linux builds distinguish glibc and musl. Release assets include SHA256SUMS for integrity checks.

An npm installation requires an appropriate Node.js environment. Standalone binaries remove that setup step for developer machines and automated checks. Existing package-manager installation methods remain supported, so teams need not migrate every machine at once.

Removing the Node.js prerequisite does not remove bundled runtime code or supply-chain risk. Operators still need an authentic download source, the correct platform, an integrity check and a recorded version. A checksum detects a mismatch with a published artifact; it does not establish the publisher’s trustworthiness by itself.

Read the plan before granting permission to write

openspec update --dry-run reports files an update would add, change or delete. The --json option provides structured output for automation. Friday Works suggests reviewing that plan before allowing an unattended process to update integration files.

Read every target path, including paths outside the repository. In Friday Works’ isolated fixture, the plan included OpenSpec’s user-level configuration. Preserve local customizations and establish ownership before running the actual update.

The trial used the official standalone ARM64 1.15.0 binary with a matching checksum. Hashes of the generated sample project remained unchanged after dry-run. This verifies that tested case, not every integration or every file elsewhere on the machine.

An interactive CLI session can also retain a shell-completion hint preference in user-level configuration. Treat dry-run as a preview of update changes rather than a filesystem sandbox. Use an isolated account or configuration directory when the environment must prohibit writes to the normal user profile.

Interpret the remaining changes narrowly

The release says several JSON commands avoid loading a spinner package, reducing startup work while preserving their output format. That is not a measured performance improvement on Friday Works’ machines, and it does not justify promising a particular percentage of savings.

Version 1.15 also matches removed requirements by exact name during verification, preventing a similarly named replacement from being mistaken for the original. This improves specification handling; it does not guarantee that generated implementation code satisfies every requirement.

Run one small, reviewable trial

Copy a project with a few locally customized integration files, record its Git state and run the preview. Review all planned changes and establish the purpose and ownership of any user-level paths before applying them.

After applying the update to the copy, inspect the diff, run the project’s relevant checks and exercise a small task with the configured assistant. The useful outcome is preserved business constraints and correct behavior, not merely successful CLI execution or a well-formatted specification.

Next steps

Friday Works recommends testing against a copy and keeping evidence before changing a customer-facing system.