fspy misses Bun file reads on Linux (glibc), so cached tasks replay stale output

[chenxin-yan]

Note: This issue was written by an AI agent (Claude) on behalf of @chenxin-yan. The reproduction below was run and checked; the suspected cause is marked as unconfirmed.

On Linux with glibc, automatic input tracking does not see files that Bun reads. A cached task that runs bun then replays stale output after one of those files changes. The same read done by node is tracked correctly.

This is the Linux counterpart of #532. #542 fixed it for macOS only.

Reproduction

package.json:

{ "name": "vt-bun-repro", "private": true, "type": "module", "devDependencies": { "vite-plus": "1.0.0" } }

vite.config.ts:

import { defineConfig } from "vite-plus";

export default defineConfig({
  run: {
    tasks: {
      "read-node": `node -e "console.log(require('fs').readFileSync('data.txt', 'utf8'))"`,
      "read-bun": `bun -e "console.log(require('fs').readFileSync('data.txt', 'utf8'))"`,
    },
  },
});

echo v1 > data.txt
npm install
npx vp run read-node && npx vp run read-bun   # populate the cache
echo v2 > data.txt
npx vp run read-node
npx vp run read-bun

Output after the change:

$ node -e "..." ○ cache miss: 'data.txt' modified, executing
v2
$ bun -e "..." ◉ cache hit, replaying
v1

bun build behaves the same way: editing its entry file is not detected. We first saw this through crust build, which bundles with an embedded Bun. Edits to the CLI's TypeScript sources replayed a stale bundle, while reads done by Node were tracked. Listing the sources in cache.input works around it.

Environment

• vite-plus 1.0.0 (also 1.0.0-rc.1)
• Bun 1.4.2, and the Bun embedded in @crustjs/crust 0.5.0
• Node 26.10.0 and 24.21.0
• Linux 6.18 x86_64, glibc 2.42 (NixOS)

Suspected cause (unconfirmed)

According to crates/fspy/README.md, fspy on glibc Linux uses LD_PRELOAD for dynamically linked executables, and seccomp_unotify only for fully static binaries. Bun is dynamically linked against glibc (ldd lists libc.so.6), so only the preload path applies. Under strace, Bun's reads of the edited files appear as ordinary openat system calls. They seem to be issued directly rather than through the interposed libc functions. I have not confirmed this inside Bun's source.

Ask

Observe Bun's file accesses on Linux, for example through the seccomp path. Alternatively, fail closed or warn when a traced process's reads cannot be observed. Silently replaying stale output means a cached build or check can pass on changed inputs.

[wan9chi]

The suspected cause is correct. We are designing a new linux backend implementation to solve this.