Hello Kevin, and thank you for your answer! Just to clarify, by "file manager" do you mean that your app is doing its own navigation of the broader file system or that your app is a file provider extension? If you're a file provider extension, why do you need/want access to so much of the system? It is a general-purpose file manager (a "Finder replacement" for former Windows users), which is why it's essential for the app to have a user-defined, permanently-living bookmark. '/' is just an example - in practice users can (and often do) grant access to one or several specific subtrees. When you relaunch are you presenting the open panel again or are you renewing an existing bookmark? I think you're presenting the open panel again on launch but if you're renewing a bookmark then I'll need to take a closer look at this. I restore an existing bookmark from @AppStorage (UserDefaults-backed), and it always restores all access - including ~/Library/Mobile Documents - without presenting the panel again. The same bookmark re-resolution that works at launch fails for ~/Library/Mobile Documents mid-session, suggesting the issue is a change in process state rather than an inherent limitation of bookmark-resolved extensions on user directories. What other directories have you tried? Particularly directories "user" directories like ~/Documents/ or ~/Downloads/? Looking at the bug, the current theory is that this is actually tied to a difference between the sandbox extension originally issued by the open panel and the new extension issued when the bookmark is resolved and accessed. Assuming that's correct then the issue here isn't FP itself, it's that FP paths are "user" directories while the other directories you check are not. This is consistent with the user-directory-class difference you described - standard user directories like ~/Documents recover via bookmark re-resolution mid-session, while ~/Library/Mobile Documents does not. Combined with the relaunch observation above, the pattern seems to be: at process start, bookmark resolution succeeds for all paths; mid-session, after some daemon event, it stops working specifically for the harder user directories. When the error occurs, "reset" by presenting an open panel. That's obviously somewhat invasive and not something you'd necessarily want to ship; however, I would probably take the time to test it. If it works, then that confirms the issue is what I've described above, and it can be useful as an "escape hatch" option if none of the other options below work. When you're initially granted access, create bookmarks to the specific directories you're interested/concerned with, not just the original container. You're losing access when the original, broader, "grant" ends, but more specific bookmarks might work as long as they were created when your app had that broader access. I'll test both suggestions at once by presenting an open panel targeted specifically at ~/Library/Mobile Documents when the failure is detected - if the approach below doesn't work out. It may be more access than you want your app to have, but I believe granting in FDA (Full Disk Access) would sidestep the issue. Similar to FDA, you can also use the "File Access Temporary Exceptions" to hardcode access to specific directories. While this would probably be the easiest option, I'm afraid that App Review will likely push back on Temporary Exceptions for a general-purpose file manager. Permanently store the URL "somewhere" and leave it alone. This is the most interesting suggestion - I hadn't considered it. Currently the original URL from the panel is simply autoreleased by ARC once the initial setup is done. I'll keep the original URL with the intentional multiple startAccessingSecurityScopedResource() calls and test whether that keeps ~/Library/Mobile Documents alive across daemon restarts. I'll report back. Thank you for the detailed analysis - the user-directory-class framing is a much cleaner explanation than what I had! P.S. One more thought: is it possible the re-resolution simply happens too fast? If the failure is caused by a daemon restart, the daemon may not yet be ready to reissue sandbox extensions at the moment I retry. Relaunch always takes time, by which point the daemon has had time to recover. I'm going to also test a delayed retry (say, 10s) before concluding the state is unrecoverable.

Issue fixed in 26.4.0

It's now macOS 26.3.1, and the issue is still there