You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Nix: v2.2.0 build fails with node_modules hash mismatch #59882
Dependency changes merge before the hash bot updates nix/hashes.json, while check-nix.yml only evaluates derivations. Please build dependencies in required PR checks and before releases, including on hash-bot PRs.
Plugins
No response
OpenCode version
v2.2.0
Steps to reproduce
Try install the pinned v2.2.0 release using the flake
Thanks for the report. I could reproduce the hash mismatch on dev, but not on the v2.2.0 tag itself.
I used Nix 2.35.4 on x86_64-linux, building with the flake's own flake.lock (no inputs.nixpkgs.follows):
v2.2.0 (1097e26): nix build .#opencode.node_modules succeeds with the pinned hash. The full nix build .#opencode also succeeds and reports opencode v2.2.0+1097e26.
Latest dev (950111f): nix build .#opencode.node_modules fails with exactly your hashes (specified: sha256-WTBGUXIj…, got: sha256-I3JJjXdM…). nix/hashes.json on dev is stale. The hash-bot PR chore: update nix node_modules hashes #59827, still open, is meant to update it.
The script below runs both builds.
If your CI fails on the v2.2.0 tag, does your flake set inputs.opencode.inputs.nixpkgs.follows? A different nixpkgs brings a different bun version, which changes the node_modules hash (#49063). That would explain a mismatch on the release even when the pinned hash is correct for the flake's own inputs.
#!/usr/bin/env bash# Reproduces #59882: the Nix node_modules fixed-output derivation hash in# nix/hashes.json is stale on `dev`, while the v2.2.0 tag builds fine.# Needs Nix with flakes enabled (nix-command flakes), x86_64-linux.set -u
REPO=${REPO:-https://github.com/anomalyco/opencode}echo"== v2.2.0 tag (flake's own nixpkgs lock) =="
nix build --no-link --print-build-logs "git+${REPO}?ref=refs/tags/v2.2.0#opencode.node_modules"2>&1| grep -iA2 "mismatch" \
||echo"v2.2.0 node_modules: built OK with pinned hash"echo"== dev =="
nix build --no-link --print-build-logs "git+${REPO}?ref=dev#opencode.node_modules"2>&1| grep -iA2 "mismatch" \
||echo"dev node_modules: built OK with pinned hash"
Also seeing this on aarch64-darwin (macOS 26.6.2, Determinate Nix 3.15.0 / Nix 2.33.0) with v2.2.3 and v2.2.5. I'm building from the tags with the flake's own lock, no follows:
Looks like the same cause described above. The v2.2.5 tag still has the nix/hashes.json from 85d7397, and bun.lock changed in the 20 commits after that.
Would it be possible to update the hashes before tagging a release? Then the tagged flake would build as-is. For now I'm overriding the node_modules hash locally.
suspiciously, the way the repo generatres these very hashes changed from opencode-agent to github-actions recently, and i have to wonder if the gh actions hasher is broken?
For those in need, this is the kind of override you need in your nixos config:
opencode=opencode.packages.${system}.default.overrideAttrs(old:
pkgs-unstable.lib.optionalAttrs(old.version=="2.2.6+dc2ffcf"&&pkgs-unstable.bun.version=="1.4.4"){# This release's upstream hash differs with Bun 1.4.4; local and CI outputs match.node_modules=old.node_modules.override{hash="sha256-O2hF8pGUSArKgYBeP99oOW3iXVVZl5bV5WPTp3E7JIA=";};});
Activity
opencodejr commentedon Oct 28, 2026
Thanks for the report. I could reproduce the hash mismatch on
dev, but not on the v2.2.0 tag itself.I used Nix 2.35.4 on x86_64-linux, building with the flake's own
flake.lock(noinputs.nixpkgs.follows):1097e26):nix build .#opencode.node_modulessucceeds with the pinned hash. The fullnix build .#opencodealso succeeds and reportsopencode v2.2.0+1097e26.dev(950111f):nix build .#opencode.node_modulesfails with exactly your hashes (specified: sha256-WTBGUXIj…,got: sha256-I3JJjXdM…).nix/hashes.jsonondevis stale. The hash-bot PR chore: update nix node_modules hashes #59827, still open, is meant to update it.The script below runs both builds.
If your CI fails on the v2.2.0 tag, does your flake set
inputs.opencode.inputs.nixpkgs.follows? A different nixpkgs brings a different bun version, which changes the node_modules hash (#49063). That would explain a mismatch on the release even when the pinned hash is correct for the flake's own inputs.Related:
Reproduction script (repro.sh)
Run it:
bash repro.shclementpoiret commentedon Nov 2, 2026
For context, il happens to nearly all releases, making opencode hard to install on NixOS using the flake. E.g., current v2.2.5 is also broken
mplibunao commentedon Nov 2, 2026
Also seeing this on aarch64-darwin (macOS 26.6.2, Determinate Nix 3.15.0 / Nix 2.33.0) with v2.2.3 and v2.2.5. I'm building from the tags with the flake's own lock, no
follows:Looks like the same cause described above. The v2.2.5 tag still has the
nix/hashes.jsonfrom 85d7397, andbun.lockchanged in the 20 commits after that.Would it be possible to update the hashes before tagging a release? Then the tagged flake would build as-is. For now I'm overriding the
node_moduleshash locally.clementpoiret commentedon Nov 2, 2026
I made a PR to fix this, I'm waiting for the final review, but I think #59403 may solve this entirely
machineonamission commentedon Nov 3, 2026
i also am experiencing this
suspiciously, the way the repo generatres these very hashes changed from opencode-agent to github-actions recently, and i have to wonder if the gh actions hasher is broken?
https://github.com/anomalyco/opencode/commits/production/nix/hashes.json
Temporarily disable opencode
flake update; disable opencode and azure-cli until upstream fixes
NoobInTheNet commentedon Nov 10, 2026
Same on v2.2.6 (dc2ffcf) on aarch64-darwin, building the tag with the flake's own lock (no
follows):The aarch64-darwin value in
nix/hashes.jsonis the same ondevtoday, so the tag does not build from the flake on this platform. v2.1.2 builds.clementpoiret commentedon Nov 10, 2026
For those in need, this is the kind of override you need in your nixos config: