feat: FUSE mount for relayfile VFS with permission enforcement

[khaliqgant]

Summary

• Adds a FUSE-based filesystem mount backed by the relayfile HTTP API using hanwen/go-fuse/v2
• Every syscall (open, read, write, readdir, stat) becomes an HTTP call to relayfile with a scoped Bearer token
• Permission enforcement at the OS level: ignored files → ENOENT, readonly files → EPERM on write
• Local LRU cache with configurable TTL (files 2s, dirs 5s) and WebSocket-based cache invalidation
• Per-agent mounts avoid concurrency bottleneck — each agent gets its own mount with its own token
• Optimistic locking via If-Match revision headers, 409 → retry

New files

• internal/mountfuse/ — fs.go, dir.go, file.go, client.go, cache.go, wsinvalidate.go
• cmd/relayfile-mount/fuse_mount.go — FUSE runner with //go:build !nofuse tag
• cmd/relayfile-mount/main.go — --fuse flag and --mode=fuse|poll support

How it works

Agent reads file → FUSE kernel intercept → mountfuse daemon
  → GET /v1/workspaces/{ws}/fs/file?path=/src/app.ts
  → Authorization: Bearer <scoped-token>
  → Returns content (or ENOENT/EPERM based on ACL)

Test plan

• go build ./internal/mountfuse/... passes
• go build ./cmd/relayfile-mount/... passes
• go test ./internal/mountfuse/... -short passes
• Manual FUSE mount test with macFUSE/libfuse installed
• Integration test with relayfile server + scoped tokens

🤖 Generated with Claude Code

---

[devin-ai-integration]

Devin Review found 4 new potential issues.

View 30 additional findings in Devin Review.

[devin-ai-integration]

🟡 Missing saveState() after revertReadonlyFile in HandleLocalChange Remove/Rename path

When a readonly file is locally deleted (Remove/Rename), revertReadonlyFile modifies s.state.Files[remotePath] (setting ReadOnly, Dirty, etc.) but the caller returns its result directly without calling s.saveState(). This means the reverted state is held only in memory and lost if the process restarts before the next timed sync cycle. Compare with the Write/Create path at line 454-458 which correctly calls s.saveState() after handleLocalWriteOrCreate.

Affected code path

Lines 459-462 return directly from revertReadonlyFile without saving:

case op&(fsnotify.Remove|fsnotify.Rename) != 0:
    tracked, exists := s.state.Files[remotePath]
    if exists && tracked.ReadOnly {
        return s.revertReadonlyFile(ctx, remotePath, localPath, tracked, "")
    }

But the non-readonly path at lines 464-467 correctly saves state.

Suggested change

	if exists && tracked.ReadOnly {
	return s.revertReadonlyFile(ctx, remotePath, localPath, tracked, "")
	if exists && tracked.ReadOnly {
	if err := s.revertReadonlyFile(ctx, remotePath, localPath, tracked, ""); err != nil {
	return err
	}
	return s.saveState()

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 Version bump uses root package.json starting at 0.0.0, producing incorrect version numbers

The publish workflow's version bump step was changed to operate on the root package.json (which has "version": "0.0.0" per package.json:3) instead of packages/sdk/package.json (previously used). When a relative bump like patch is selected, npm version patch on the root will produce 0.0.1 instead of incrementing from the actual published version of the packages (e.g., core is at 0.1.0). This means the first non-custom-version publish from this workflow would reset all package versions to an unexpectedly low number like 0.0.1.

Prompt for agents

In .github/workflows/publish.yml, the version bump step at line 91-92 reads CURRENT_VERSION from the root package.json which is at 0.0.0. It should either: (1) read the current version from one of the actual published packages (e.g. packages/core/package.json or packages/sdk/package.json) before bumping, or (2) set the root package.json version to match the current published version, or (3) always derive the version from an existing package. The key change needed is around line 91: CURRENT_VERSION should come from a package with the real published version, and npm version should be run against that package or the root version should be seeded correctly.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Devin Review found 2 new potential issues.

View 29 additional findings in Devin Review.

[devin-ai-integration]

🔴 requireSignature documented default is true (fail-closed) but code defaults to false (fail-open)

The JSDoc on requireSignature states "Defaults to true (fail-closed)" but the implementation at line 121 uses options.requireSignature === true, which evaluates to false when the option is undefined (the default). This means callers who omit requireSignature — trusting the documented default — will get fail-open behavior where webhooks are accepted without signature verification, directly contradicting the documented security guarantee.

Suggested change

	const requireSignature = options.requireSignature === true;
	const requireSignature = options.requireSignature !== false;

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🔴 Bare * wildcard in scopeMatchesPath matches across directory boundaries

When a scope path ends with * (but not /*), the check at line 263 does strings.HasPrefix(filePath, scopeDir) where scopeDir has the trailing * stripped. For a scope like relayfile:fs:read:/src*, scopeDir becomes /src, so HasPrefix("/srcevil/secret.txt", "/src") returns true — granting unintended access to paths outside the intended /src directory tree. The /* variant (line 260) correctly appends / to prevent this, but the bare * variant does not.

Example of unintended match

Scope: relayfile:fs:read:/src*

• Line 255: scopeDir = TrimSuffix("/src*", "/*") → "/src*" (unchanged)
• Line 256: scopeDir = TrimSuffix("/src*", "*") → "/src"
• Line 263: HasPrefix("/srcevil/secret.txt", "/src") → true ← unintended match

Suggested change

	if strings.HasSuffix(scopePath, "*") && strings.HasPrefix(filePath, scopeDir) {
	return true
	}
	if strings.HasSuffix(scopePath, "*") && (strings.HasPrefix(filePath, scopeDir+"/") || filePath == scopeDir) {
	return true
	}

---

Was this helpful? React with 👍 or 👎 to provide feedback.