[quote='885567022, DTS Engineer, /thread/812992?answerId=885567022#885567022'] What was the bug number? [/quote] I had posted with the bug number originally, but then it seemed like anyone with the feedback app could access all the files attached and I wasn’t 100% sure there was no personal data in there. I’m probably being overly paranoid, but is there a way to get it to you directly? Edit to add: I see your email now. Sending. Sorry, I'm new at this.

[quote='885427022, DTS Engineer, /thread/812992?answerId=885427022#885427022'] Did anyone file a bug about this? [/quote] Filed the bug report Reproduces the 'lying delete' + stuck Deleting state on Xcode 26.4.1 / macOS 26.4.1, plus a second orphan revealed by scan-and-mount.

Is the only way to fix this literally to wipe your Mac and do a clean install?

After additional testing, this appears to be an orphaned MobileAsset cleanup issue rather than a normal simulator uninstall problem. The runtime payload remains on disk under /System/Library/AssetsV2, but in some cases Xcode no longer exposes it in Components/Platforms and simctl does not have a usable reference to remove it cleanly. In other words, the asset still occupies space, but the supported management tools have effectively lost authoritative control over it. At that point the problem becomes structural: the remaining files are in a SIP-protected system location. So even if the exact asset folder can be identified, it cannot be manually removed through normal user-space means while SIP is enabled. That leaves no supported path to reclaim the space once the asset has fallen out of Xcode/simctl management. Technically, the remaining workaround is to disable SIP and remove the orphaned asset manually, but that is not a reasonable solution for routine simulator runtime cleanup. SIP exists specifically to prevent modification of protected system locations, and turning it off to recover disk space from a leaked MobileAsset is a security regression and a poor operational workaround. So the practical conclusion seems to be: If Xcode or simctl can still see the runtime, removal may work. If the runtime is no longer visible there but the asset remains under AssetsV2, there is no supported deletion path with SIP enabled. This looks like an Apple-side bug in runtime asset lifecycle management and cleanup, because the system can retain large orphaned assets in a protected location without providing a supported way to remove them.

I've seen this issue as well, with .wiki files (that are really just text files) trying to open them in BBEdit. And reported here: https://discussions.apple.com/thread/256029589 regarding .webp files and .avif files Noticed it a bit with 15.4, but now much more aggressive with 15.4.1 with the OS refusing to let me open any of the hundreds of files I work with every day, unless I go to system settings and manually approve each one of them, only after trying and failing to open it. Also, a horrifically bad user interface design where the default option for the file I'm trying to work with is "Move to Trash" and even after approving in system settings another box pops up with again default option "Move to Trash" and the button I'm looking for, every time, squeezed between two other buttons that I very much don't want to click. Apple making it very easy for me to accidentally move my work file to the trash I understand the reason for it, but there has to be a way to modify this behaviour or stop triggering certain kinds of files.