diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index 0b2b1b8fc7..3cd21240da 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -1034,6 +1034,22 @@ jobs:
         run: |
           rm -rf target/perry-auto-* target/debug/libperry_ext_*.a 2>/dev/null || true
 
+      # This job runs `cargo test -p perry`, whose integration tests shell out
+      # to node scripts under scripts/ -- and those scripts assert
+      # `process.versions.node` equals the .node-version pin, because the
+      # loader/byte behaviour they gate on is version-specific. Without this
+      # step the job inherits whatever node the ubuntu-latest image happens to
+      # ship (22.23.2 on 2026-09-16), so
+      # `bun_embedded_compression::standalone_compressed_asset_regression`
+      # fails that assertion and takes the whole job red on main. Pinned from
+      # the FILE, never a literal: check_node_version_consistency.py (a lint
+      # step) requires every literal `node-version:` to be a registered
+      # exemption, and this is not one.
+      - name: Setup Node.js for the node-backed integration tests
+        uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
+        with:
+          node-version-file: .node-version
+
       - name: Run cargo test
         # The exclusions below are maintained once in
         # workspace-architecture.json and consumed by ci_test_scope.py:
@@ -1296,6 +1312,18 @@ jobs:
         run: |
           rm -rf target/perry-auto-* target/debug/libperry_ext_*.a 2>/dev/null || true
 
+      # Same reason as the `cargo-test` job: these shards run `-p perry`
+      # integration tests that shell out to node scripts asserting
+      # `process.versions.node` equals the .node-version pin. Which shard a
+      # node-backed test lands in is decided by ci_cargo_test_shard.py, so
+      # leaving this job unpinned makes the failure move with the sharding
+      # rather than stay fixed. From the FILE, not a literal — see
+      # check_node_version_consistency.py.
+      - name: Setup Node.js for the node-backed integration tests
+        uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
+        with:
+          node-version-file: .node-version
+
       - name: Run perry integration shard ${{ matrix.shard }}
         env:
           CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS: "-C linker-features=-lld"
diff --git a/changelog.d/10383-pin-node-cargo-test.md b/changelog.d/10383-pin-node-cargo-test.md
new file mode 100644
index 0000000000..5765916814
--- /dev/null
+++ b/changelog.d/10383-pin-node-cargo-test.md
@@ -0,0 +1,13 @@
+Pin Node from `.node-version` in the `cargo-test` and `cargo-test-perry` jobs.
+Neither ran `setup-node`, so both inherited whatever Node the `ubuntu-latest`
+image ships — 22.23.2 against a 26.5.1 pin — and
+`bun_embedded_compression::standalone_compressed_asset_regression` failed the
+`process.versions.node` assertion that `scripts/test-bun-embedded-compression.mjs`
+opens with, taking the whole job red on `main`. That assertion is the point of
+the test: the loader and byte behaviour it gates on is version-specific.
+
+Both jobs are pinned, not just the one observed failing — which shard a
+node-backed test lands in is decided by `ci_cargo_test_shard.py`, so pinning one
+would move the failure with the sharding instead of removing it. Pinned from the
+file rather than a literal, because `check_node_version_consistency.py` requires
+every literal `node-version:` to be a registered exemption.