A couple of months ago I wrote about inaccessible .bnnsir files on macOS Sequoia. This blog post is a follow-up. Yesterday the backup of my macOS Data volume failed with "copy error: Operation not permitted".
hdiutil create -encryption -format UDSB -srcfolder /Volumes/Data -noatomic -noscrub -volname 2025-4-8 -verbose -puppetstrings /Volumes/backup/2025-4-8.sparsebundleThe problem was caused by another .bnnsir file, this time located in the $TMPDIR/SpeechModelCache/ directory. (In Terminal, echo $TMPDIR shows the full file path on your disk.) When I was making the backup, I was booted into the recovery volume, with System Integrity Protection disabled, but the copy nonetheless failed. The $TMPDIR is emptied with every reboot, but my unfortunate timing was that the directory is emptied on the next boot into the volume containing $TMPDIR, so the previous contents were still there when I was making the backup.
In case you're wondering, the -skipunreadable flag to hdiutil does not help! The copy error still occurs.
My backup failure inspired me to look at these .bnnsir files again. Why are the files uncopyable, indeed unreadable? The reason is not the file extension itself. If I create new files with the .bnnsir file extension, I'm able to read and copy them. I've also found some other system-generated .bnnsir files, which I believe are actually new in macOS 15.4. These bnns_program.bnnsir files are located inside the ~/Library/ and ~/Library/ directories. I have no idea what their purpose is, but I can read and copy the files with no problems. By the way, I don't even use iCloud mail!
The reason is not the parent directory of the .bnnsir file either. If I add other files to the ~/Library/ directory, for example, the added files can be read and copied. There just appears to be something special—I know not what exactly—about the .bnnsir files created by Siri that prevent the files from access by anything except Siri. I suppose. that I would need to reverse engineer the macOS kernel to find out why; I don't feel like making that enormous effort, though, because it would still not provide me with a solution to my problem.
I know that the group.com.apple.CoreSpeech .bnnsir files are created by Siri because the file names actually end in -en-IE.bnnsir, indicating Irish English. To avoid software update automatically enabling Apple Intelligence, I switched my Siri language from English (United States) to English (Ireland). According to System Settings, "Apple Intelligence requires that Mac and Siri are set to the same language." Nonetheless, Siri creates the onDeviceCompilationCaches directory regardless of the Siri language setting.
The $TMPDIR/SpeechModelCache/ directory is gone for now. I believe that it was created by the macOS 15.4 update, so I should be safe there at least until the next macOS update. On the other hand, deleting the ~/Library/ directory doesn't last very long, because Siri re-creates it on every login. In fact, Siri will re-create it if you simply quit the corespeechd process, which runs as your user and gets automatically relaunched. (I enabled a Folder Action to notify me whenever a file is added to ~/Library/ folder.) This re-creation occurs even when Siri is disabled! (However, it may depend on Siri having been enabled at least one in the past.) And it occurs even when your internet is disabled, so clearly the files aren't getting redownloaded every time. Ironically, macOS needs a second cache for data that is already cached somewhere on disk. My suspicion is that the data is coming from within the /System/Library/AssetsV2 directory. I'm honestly too afraid to find out, by deleting subdirectories (which is possible with SIP disabled). I don't want to accidentally break my system.
I've now filed two bug reports with Apple Feedback Assistant: (FB17162985) hdiutil create copy error with Siri CoreSpeech .bnnsir files and (FB17163068) ~/Library/Group Containers/group.com.apple.CoreSpeech/Caches/onDeviceCompilationCaches/ recreated on every login with Siri disabled. The worst part about these problems is that disabling SIP doesn't help. I feel like my Mac is no longer my own, when I can't read or copy files on my own disk.