macOS: VS Code Recent Documents can invalidate active vp inode, breaking all shims until reinstall

Start with the #807 precedent and the referenced XNU code paths for vnode code-signature invalidation. Reproduce the macOS sequence using vp create, code ., and the listed shim commands, then investigate the active Mach-O and shim recovery path. Done means opening or restoring Vite+ paths in VS Code does not leave vp, node, nr, or other shims unusable.

Describe the bug

On macOS, the active Vite+ Mach-O can become permanently invalid for that inode after VS Code rebuilds its Recent Documents list. Once this happens, every Vite+ shim that points to the same binary (vp, node, nr, npm, and others) is killed at exec with:

SIGKILL (Code Signature Invalid)

Reinstalling Vite+ fixes the commands only because the new installation uses a new inode. The original file remains byte-for-byte valid and still passes codesign --verify, but macOS continues to reject execution from its old inode.

This incident happened immediately after vp create, but the evidence below shows that vp create did not overwrite or modify the binary. The invalidation happened after code ., while VS Code/CoreServices was rebuilding bookmarks for Vite+ paths stored in Application Recent Documents.

Why this is actionable in Vite+:

• All Unix shims resolve to one active, ad-hoc/linker-signed vp Mach-O, so one invalidated vnode breaks the whole managed runtime.
• There is no non-Mach-O launcher or recovery path capable of replacing/retrying the invalid inode after exec starts failing.
• Vite+ already handles the same macOS inode/code-signature failure class for local bootstrap in #807, but not when the active vnode is invalidated externally.

Expected behavior: opening a project in VS Code, or restoring Vite+ paths from Recent Documents, must not make vp, node, and every other managed command unusable until reinstall/reboot.

I am not currently planning to submit a PR.

Reproduction

No project repository is needed — this is a machine-level Vite+ shim failure. The observed shell sequence and preserved runtime evidence are below.

Steps to reproduce

Observed stateful sequence:

1. Use Vite+ v0.2.4 on macOS 26.5.2 arm64.

2. Have Vite+ shim paths in VS Code's recent documents. On this machine, these had previously been opened:

   code "$HOME/.vite-plus/bin/trellis"
   code "$HOME/.vite-plus/bin/"
   

   VS Code's persisted com.microsoft.vscode.sfl4 resolved entries included:

   $HOME/.vite-plus
   $HOME/.vite-plus/0.2.4
   

3. Create a library and open it:

   vp create
   cd fe-qualitiy-share
   code .
   

4. Run any Vite+ shim:

   vp --version
   node -v
   nr
   

5. Each process is terminated by SIGKILL (Code Signature Invalid).

Important control: the same old vp inode executed successfully after vp create completed. It only became invalid during the subsequent VS Code Recent Documents rebuild.

The trigger depends on persisted VS Code/macOS Recent Documents state, so a clean-machine reproduction may first require seeding those Vite+ paths.

System Info

The global CLI was reinstalled to recover the shell. The affected v0.2.4 binary and inode are still preserved. Current full output:

$ vp env current
Environment:
  Version  24.18.0
  Source   lts

Tool Paths:
  node  /Users/jacobzha/.vite-plus/js_runtime/node/24.18.0/bin/node
  npm   /Users/jacobzha/.vite-plus/js_runtime/node/24.18.0/bin/npm
  npx   /Users/jacobzha/.vite-plus/js_runtime/node/24.18.0/bin/npx

Package Manager:
  Name          pnpm
  Version       11.17.0
  Source        devEngines.packageManager
  Source Path   /Users/jacobzha/Documents/workspace/jacob-open-source/fe-qualitiy-share/package.json
  Project Root  /Users/jacobzha/Documents/workspace/jacob-open-source/fe-qualitiy-share
  Bin Path      /Users/jacobzha/.vite-plus/package_manager/pnpm/11.17.0/pnpm/bin/pnpm

$ vp --version
vp v0.2.6

Local vite-plus:
  vite-plus  v0.2.4

Tools:
  vite             v8.1.3
  rolldown         v1.1.4
  vitest           v4.1.10
  oxfmt            v0.57.0
  oxlint           v1.72.0
  oxlint-tsgolint  v0.24.0
  tsdown           v0.22.3

Environment:
  Package manager  pnpm v11.17.0
  Node.js          v24.18.0

$ sw_vers
ProductName:    macOS
ProductVersion: 26.5.2
BuildVersion:   25F84

$ uname -m
arm64

$ code --version
1.130.0
1b6a188127eeaf9194f945eb6eb89a657e93c54c
arm64

Affected global runtime:

vp v0.2.4
Mach-O thin arm64
UUID AE58E66B-8D3B-33C0-9AB1-F031C072C9C6

Used Package Manager

pnpm

Logs

Exact timeline:

10:28:32  vp create
10:29:39  the same old vp inode still executes successfully
10:29:46  code .

10:29:48.831  Code[44880:c85e7]  CFURLCreateBookmarkData
10:29:48.831  kernel[0:c85e7]     Invalidated flags, old 20020003 new 20020002
10:29:48.832  Code[44880:c85e7]  inserts Recent Documents item
                                      0F6552C6-674C-43E5-9EC6-A931997E96F6

10:29:49.616  kernel  load_code_signature:
                         embedded signature doesn't match attached signature
10:29:49.616  kernel  proc 44950:
                         load code signature error 2 for file "vp"

10:29:50.776  the user's nr invocation fails with the same error

The persisted VS Code Recent Documents archive maps item 0F6552C6-674C-43E5-9EC6-A931997E96F6 to:

/Users/jacobzha/.vite-plus/0.2.4

The kernel and VS Code entries have the same thread ID (c85e7). This was the only Invalidated flags event between 10:20 and 10:45. Every subsequent signature-load failure named vp.

The flags precisely show CS_VALID being cleared:

old 0x20020003:
  CS_SIGNED        0x20000000
  CS_LINKER_SIGNED 0x00020000
  CS_ADHOC         0x00000002
  CS_VALID         0x00000001

new 0x20020002:
  CS_VALID removed

This matches the binary:

$ codesign -dvvv ~/.vite-plus/0.2.4/bin/vp
CodeDirectory v=20400 ... flags=0x20002(adhoc,linker-signed)
Signature=adhoc

Disk evidence:

path   /Users/jacobzha/.vite-plus/0.2.4/bin/vp
inode  280661373
size   8404640
birth  2026-07-16 11:50:46
mtime  2026-07-16 11:50:46
ctime  2026-07-16 11:50:46
sha256 c372d2c2da14b1e2086a4965ced59359616d885501426669c07c244c7d854273

The whole ~/.vite-plus/0.2.4 tree had no ctime/mtime change during the incident. vp create only installed pnpm under:

~/.vite-plus/package_manager/pnpm/11.17.0

Decisive copy experiment:

original old inode:
  codesign --verify --deep --strict -> valid
  execution                          -> SIGKILL / exit 137

plain cp to a new inode:
  identical SHA256
  identical embedded signature
  codesign --verify --deep --strict -> valid
  execution                          -> vp v0.2.4 / exit 0

This matches XNU behavior:

• csvnode_invalidate_flags() clears CS_VALID when a vnode may have been modified:
  https://github.com/apple-oss-distributions/xnu/blob/main/bsd/kern/kern_cs.c#L494-L545
• XNU refuses to revalidate an invalidated blob and explicitly says to reboot or create a new file:
  https://github.com/apple-oss-distributions/xnu/blob/main/bsd/kern/ubc_subr.c#L5586-L5591
• load_code_signature() emits the observed generic mismatch when an attached blob has lost CS_VALID:
  https://github.com/apple-oss-distributions/xnu/blob/main/bsd/kern/mach_loader.c#L3565-L3581

Related Vite+ precedent:

• #807: https://github.com/voidzero-dev/vite-plus/pull/807
• Commit message: fix: use timestamped local-dev dirs to avoid SIGKILL on macOS
• It documents the same stale inode/code-signature mechanism for an in-place local bootstrap overwrite. v0.2.4 already contains that fix; the vp create vite:library call graph does not reach bootstrap, upgrade, installer, shim refresh, or any writer of the active Mach-O.

Validations

• Read the Contributing Guidelines.
• Check that there isn't already an issue for the same bug.
• Confirm this is a Vite+ issue and not an upstream issue (Vite, Vitest, tsdown, Rolldown, or Oxc).
• The provided reproduction is a minimal reproducible example.