These days I've observed a strange behavior in my document-based app on macOS:
Its NSDocument class implementation is overwriting "saveToURL:ofType:forSaveOperation:completionHandler:", performing some additional checks and calling super by passing the original parameters.
As my app is supporting various file formats for writing (and exporting those UTIs) the user can open a file in one format and save it to another. NSDocument is calling the mentioned methods implicitly after completing the "Save as..." dialog. If this happens, the passed-on fileType is still the one of format #1, although the file is saved with the file name extension of format #2. This hick-up is not directly obvious to the user.
But if the file is re-saved (e.g. after modifications), Cocoa is trying to extend the sandbox for the URL of type #1, and fails with the following error message at the Xcode console:
-[STBDocument saveToURL:ofType:forSaveOperation:completionHandler:] [Line 521] typeName: com.janome.jef
-[STBDocument saveToURL:ofType:forSaveOperation:completionHandler:] [Line 523] targetTypeUTI: com.tajima.dst
NSFileSandboxingRequestRelatedItemExtension: Failed to issue extension for /Users/matthias/Desktop/Ohne Titel.jef because: Error Domain=NSPOSIXErrorDomain Code=3 "No such process"
-[NSFileCoordinator itemAtURL:willMoveToURL:] could not get a sandbox extension. oldURL: file:///Users/matthias/Desktop/Ohne%20Titel.dst, newURL: file:///Users/matthias/Desktop/Ohne%20Titel.jef
I'm currently fixing this issue by determining the UTType for the new file name extension and passing it to super.
Unfortunately I have no idea how long this issue was already present, and cannot replicate it with a sample app based on Apple's Xcode 26 template (too many differences to my >15 years old app) - so I won't file a bug report.
Take this post just for information in case someone else is facing a similar situation...