[Bug]: pi-fff 0.10.1 can retain fff-node/native 0.8.1 and hit known macOS SIGSEGV #710

Which fff frontend?

Node SDK (@ff-labs/fff-node) through the @ff-labs/pi-fff Pi extension.

Related project: packages/pi-fff.

has logs

No FFF log is available. pi-fff does not pass logFilePath to FileFinder.create(), so the Node SDK does not create the template-described log file.

macOS generated two Node crash reports. Both report EXC_BAD_ACCESS / SIGSEGV in libfff_c.dylib on an fff-bg-N thread.

Description

@ff-labs/pi-fff@0.10.1 declares its Node SDK dependency as "@ff-labs/fff-node": "*". An existing npm lockfile retained @ff-labs/fff-node@0.8.1 and @ff-labs/fff-bin-darwin-arm64@0.8.1, even though the installed Pi extension and latest SDK/native packages are 0.10.1.

That dependency skew caused the Pi host Node process to crash twice while FFF watched a development directory undergoing Git worktree filesystem churn.

Installed dependency tree

@ff-labs/pi-fff@0.10.1
├─ @ff-labs/fff-bun@0.10.1
│  └─ @ff-labs/fff-bin-darwin-arm64@0.10.1
└─ @ff-labs/fff-node@0.8.1
   └─ @ff-labs/fff-bin-darwin-arm64@0.8.1

pi-fff@0.10.1/package.json currently contains:

{
  "dependencies": {
    "@ff-labs/fff-bun": "*",
    "@ff-labs/fff-node": "*"
  }
}

Current npm latest versions checked after the crash:

@ff-labs/pi-fff                 0.10.1
@ff-labs/fff-node               0.10.1
@ff-labs/fff-bin-darwin-arm64   0.10.1

Environment

macOS 26.5.2 (25F84)
Apple Silicon arm64
Node v24.16.0
@ff-labs/pi-fff 0.10.1
@ff-labs/fff-node 0.8.1 (transitive lock resolution)
@ff-labs/fff-bin-darwin-arm64 0.8.1
Pi coding agent host

Reproduction observed

1. Start Pi in a parent development directory with pi-fff enabled.
2. Let FFF scan/watch that directory.
3. Create a Git worktree as a new child directory, e.g. git worktree add <child-path> <branch>.
4. During/just after the filesystem churn, the Pi Node process exits with SIGSEGV.

This occurred twice within approximately 14 minutes. The shell only reported:

zsh: segmentation fault  pi

The worktree command was interrupted after branch creation, leaving the branch but no completed worktree.

Crash signature

Both reports:

Exception: EXC_BAD_ACCESS / SIGSEGV
Faulting image: libfff_c.dylib
Native UUID: 0d1b8100-751d-3645-881b-44663ede3f6d
Faulting threads: fff-bg-3, fff-bg-4

Latest faulting stack begins:

libfff_c.dylib +385524
libfff_c.dylib +812552
libfff_c.dylib +562740
libfff_c.dylib +813028
libfff_c.dylib +562740
libfff_c.dylib +813028
...

This matches the published 0.8.1 native UUID and top-frame signature documented in #515, and the filesystem-churn scenario in #476. Both issues are closed, but pi-fff@0.10.1 can still install/retain that old native implementation because of the wildcard dependency plus npm lockfile behavior.

Expected

Updating/installing pi-fff@0.10.1 should not leave it running against a known-crashing fff-node/native 0.8.1 dependency.

Suggested fix

Please pin or range @ff-labs/fff-node and @ff-labs/fff-bun to the matching compatible release instead of * (for example, the workspace-synchronized 0.10.1 version/range), so updating pi-fff reliably updates the native SDK implementation containing prior crash fixes.

It may also help for pi-fff to expose/pass a logFilePath, since currently a native crash cannot provide the FFF log requested by this issue template.

I can provide the two .ips crash reports if needed.