Seems like the new ASIF sparse image format will solve a lot of this, combined with their new containerization framework

https://eclecticlight.co/2025/06/12/macos-tahoe-brings-a-new...

Recently, macOS added a built-in FUSE-like API:

https://developer.apple.com/documentation/fskit

No idea what the performance is like.

However, over the last few years, Apple’s compilers have gotten even more enthusiastic than before about caching and “content addressable storage”:

https://llvm.org/devmtg/2024-10/slides/techtalk/Rastogi-Fine...

Which is normally a good thing, but may exacerbate the issue described in the post where, by enforcing isolation, you end up cutting off the compiler from its caches and making the build slower.

I think the ideal solution would be for Bazel to somehow know about and integrate with LLVM’s CAS.

edit: although just figuring out how to do “explicit module builds” with Swift and Clang would probably get you most of the way.

If you semi-trust your tool binaries enough not to do something silly like making syscalls directly, what about using the `LD_PRELOAD` equivalent to intercept `open` etc.? (Yes there's a long tail in that "etc.")

Or does using Go ruin everything again?

(Also it seems like it should in principle be possible to keep the symlink forest around and only delete other files)

It's amazing that the conclusion it's that sandboxing would have had to use NFS, which is the approach that the vesta build system took 20 years earlier.

MacOS security has been making the platform unfriendly to developers in a similar way that Windows has since Vista.

Is Bazel using Landlock LSM yet for sandboxing? That's what I use with GNU Make and it's great. Nothing is faster.

The downside is it requires ~3 syscalls per file. If only I could send it all the mappings at once like you did.