General: DevForums subtopic: App & System Services > Core OS Core OS is a catch-all subtopic for low-level APIs that don’t fall into one of these more specific areas: Processes & Concurrency Resources Files and Storage Resources Networking Resources Network Extension Resources Security Resources Virtualization Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello, I am working on an audit of file operations for a DLP agent. I am trying to implement this mechanism using Endpoint Security. One of the customer's requirements is that write event reports must provide information about the file size both before and after the write operation. The challenge is that the ES_EVENT_TYPE_NOTIFY_WRITE event does not provide information about the changes, and in the stat structure, I see the file's stat prior to the write event. I tried to implement a mechanism based on tracking the sequence of events (open -> write -> close), but it seems macOS does not guarantee such a sequence, as the agent receives ES_EVENT_TYPE_NOTIFY_CLOSE earlier than ES_EVENT_TYPE_NOTIFY_OPEN. Unfortunately, Auth events cannot be used due to no guarantee the DLP agent is the only ES client. Is there any way within the Endpoint Security Framework to guarantee the sequence of NOTIFY events? Are there any other supported (public) APIs or methods besides Endpoint Security to track file system changes? As far as I know, ktrace (which powers fs_usage) is a private framework. Thank you in advance!

I am evaluating a hypothetical file collector that uses fixed approved directory roots. Its requirement includes rename-after-open: if another process moves an opened file or an ancestor outside the approved namespace, the collector must not continue accessing it there. This concerns input reads, directory enumeration, preview reacquisition, and writes to exclusively created output files. Retaining a previously approved descriptor or detecting a move after access does not meet the requirement. I am considering whether Endpoint Security can prevent the relevant namespace mutations before they occur for the complete access interval. No Endpoint Security client has been created or exercised for this candidate. This is a request for a documented, versioned contract, not permission to deploy a client, obtain an entitlement, or change the system. The deadline-mode documentation describes the response to an unanswered authorization within its deadline. The mode values describe deny without killing the client, allow without killing the client, and killing the client as the default. The setter documentation also describes denial of a queue-full AUTH drop under FAIL_CLOSED. I have not found, in the specific pages listed below, an explicit contract for the separate case of client loss. I am not assuming that deadline policy covers disappearance of a client. Could you clarify the following? Pending authorization at client loss For a relevant authorization such as ES_EVENT_TYPE_AUTH_RENAME or ES_EVENT_TYPE_AUTH_UNLINK that is already pending, what exact verdict applies if the matching client crashes, disconnects, is deleted with es_delete_client, or unsubscribes before responding? Please distinguish each case, including when it was the last matching client and when other matching clients remain. Does a configured FAIL_CLOSED deadline policy remain attached to that pending request after client loss? Operations after the last matching client is gone What controls a later rename, reparenting, exchange, unlink, or other relevant namespace mutation after the last matching client has disappeared or unsubscribed? Is there a supported policy that remains effective independently of that client's lifetime? Please distinguish new operations from an authorization that was already pending, including cached decisions and any interval before a replacement client is ready. A supported complete protection interval Is there a supported way, through Endpoint Security or another supported kernel-enforced mechanism, to keep the necessary namespace mutations denied from before the collector's first access until its final read/write ends, despite authorization-client loss, partial setup, or owner death? The mutating actor may be outside the collector's process subtree. A later watchdog termination, restart, or notification of a completed operation would not establish denial during the intervening interval. If protection must end before that interval is complete, please identify the exact limitation. Client types and failure cases Which guarantees differ between es_new_client and es_new_descendants_client? Beyond the unanswered-deadline and full-queue cases, does any deadline mode affect the cases in questions 1 and 2? Please identify any self-process, muting, caching, scope, or actor limitations that prevent the proposed all-relevant-mutator coverage. I am not assuming a descendant-scoped client can authorize operations by unrelated processes. Versioned support and prerequisites For any supported contract, please cite the public documentation or other authoritative reference, applicable released macOS versions, exact API and deployment configuration, and required entitlements, privilege, consent, or system-extension conditions. API introduction metadata alone is not being treated as evidence about an installed target, and an upgrade or privilege change is not assumed. If no public supported mechanism provides the requested interval, an explicit statement of the missing guarantee or required independent enforcement boundary would be useful. Public references reviewed https://developer.apple.com/documentation/endpointsecurity/es_set_deadline_miss_mode(::) https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_t https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_closed https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_fail_open https://developer.apple.com/documentation/endpointsecurity/es_deadline_miss_mode_kill https://developer.apple.com/documentation/endpointsecurity/client https://developer.apple.com/documentation/endpointsecurity/es_client_t https://developer.apple.com/documentation/endpointsecurity/es_new_client(::) https://developer.apple.com/documentation/endpointsecurity/es_new_descendants_client(::) https://developer.apple.com/documentation/endpointsecurity/es_delete_client(:) https://developer.apple.com/documentation/endpointsecurity/es_unsubscribe_all(:) The scoped document reviews did not establish the two client-loss cases above; this is not a claim that every relevant Apple document or mechanism has been exhausted. No real data, credentials, private artifacts, logs, or host identifiers are needed for this clarification.

I'm developing an app that uses SMAppService to register a launch daemon. I'm running into big troubles with having the daemon start up reliably because, over the course of testing, the location of my app bundle has changed. Various workflows for this app require testing it running from with /Applications, /Applications/Utilities, or in the project's build directories, which includes both debug and release builds. And I need to account for users moving the app bundle around. The trouble is that the launch daemon seems to want to launch from the first path it was registered, not at the path it was last registered. For example, if my app originally registered it while located in /Applications/MyApp.app, then the launch daemon will only run from within an app bundle at that specific location, even if there is no app bundle at that path. As per advice on these forums, I've tried accounting for this by unregistering the daemon, waiting two seconds, and then re-registering it. But in practice this isn't working. I can use sfltool dumbtm and see that the app is still registered in /Applications/MyApp.app and not its new location, and the launch daemon simply silently fails to launch -- SMAppService returns no error. sudo launchctl list displays the job as having status 78. If I set up a stdout/stderr redireciton in its job file, the files are empty. (I'm aware that I can use sfltool resetbtm to completely reset all login items and background tasks and temporarily fix this issue at least on my own system, but I can hardly have my app use that as part of its standard installation procedure. I need some way of dealing with this that doesn't requiring reseting the state of every app that has a background item.) I'm starting to pull my hair out dealing with this! (Figuratively, mind you. Not literally, at least not yet.) How can I get this to work? This API is starting to seem like a downgrade from placing a plist file in /Library/LaunchDaemons because at least that was able to work very reliably.

I'm building a sandboxed macOS app (Developer ID, App Sandbox enabled) with a File Provider extension that exposes on-demand placeholder files under  ~/Library/CloudStorage/<domain>/ . Expected: The app writes the placeholder file URLs to  NSPasteboard.general . The user presses ⌘V in Finder, and Finder fetches the contents on demand via  fetchContents . Observed: • Finder's own copy and paste of the same placeholders works, and  fetchContents  is called at paste time as expected. • When the sandboxed app writes the URLs to the pasteboard,  CFPasteboard  logs:  Sandbox extension creation failed ... (error -20) . The paste does not happen. • Writing  NSPasteboardItem  with  .fileURL  strings instead of  NSURL  objects produces the same error. • Adding  com.apple.security.temporary-exception.files.absolute-path.read-only  for the CloudStorage domain path fixes it. Questions: Is there a supported way for a sandboxed app to put File Provider placeholder URLs on the pasteboard without the temporary-exception entitlement? Is the temporary-exception entitlement acceptable for Mac App Store distribution, or is it only viable for Developer ID builds? Should the app grant itself access another way, for example through a security-scoped bookmark or by using  NSFileProviderManager  APIs?

Hello, I am preparing an existing macOS screenshot utility for distribution through the Mac App Store. The app stores captured PNG files under its temporary directory: FileManager.default.temporaryDirectory .appendingPathComponent("ShelfDragPoC/Captures", isDirectory: true) A context-menu "Edit" action passes the original PNG URL to Preview using NSWorkspace. The app does not create an editing copy. Relevant code: import AppKit @MainActor func openInPreview(_ url: URL) { guard let previewURL = NSWorkspace.shared.urlForApplication( withBundleIdentifier: "com.apple.Preview" ) else { return } let configuration = NSWorkspace.OpenConfiguration() configuration.activates = true NSWorkspace.shared.open( [url], withApplicationAt: previewURL, configuration: configuration ) { _, _ in } } The app monitors the original PNG URL for file changes and refreshes its thumbnail when changes are detected. Observed behavior: In the existing non-sandboxed app, rotating an image in Preview updates the original PNG and the thumbnail without requiring Command-S. In the sandboxed validation app, Preview opens the image, but editing results in a separate copy. When closing the edited document, Preview displays a message indicating that the original document will not be changed. The original PNG and the app's thumbnail are not updated. The Preview launch code and file watcher are unchanged between the non-sandboxed and sandboxed versions. The sandboxed app has these entitlements: com.apple.security.app-sandbox com.apple.security.files.user-selected.read-write com.apple.security.files.bookmarks.app-scope The app-scoped bookmark is used for a separate Desktop export feature. The PNG opened in Preview remains in the app's sandbox container. My question: Is there a supported public API that allows a sandboxed Mac App Store app to open its own container-resident PNG in Preview with the permissions required for in-place editing and normal automatic saving? Ideally, the user would only need to select "Edit" once, without an additional file-selection dialog or an explicit Save command. We want to preserve the original PNG URL, keep App Sandbox enabled, and avoid automatically exporting temporary images to the Desktop. If this workflow is not supported, what is Apple's recommended approach? Thank you.

Subject: Supported macOS containment for a sandboxed worker after controller failure I'm investigating an Apple Silicon/macOS architecture in which an untrusted, signed, sandboxed worker must be independently containable by a separate trusted supervisor. The worker needs only a narrow authenticated communication channel. It requires no direct network access, external operational credentials, privileged file access or authority to launch helpers. I understand that App Sandbox does not inherently prevent child-process creation, and that RLIMIT_NPROC alone does not prevent every form of execution delegation. Could you clarify: Is there a public, supported macOS mechanism to deny all worker-originated subprocess creation and execution delegation at launch, while retaining one restricted communication channel? Alternatively, is there a supported mechanism for a surviving supervisor to identify, terminate and positively verify the complete execution domain of a worker, including any descendants, after its controller crashes or is suspended? What guarantees and limitations apply to stable identity, process exit, automatic relaunch and loss of the supervisor? I'm specifically seeking supported operating-system guarantees, not private sandbox profiles, polling, heartbeat inference or best-effort process-tree enumeration. The goal is to determine whether a bounded synthetic containment experiment is technically justified. No production implementation has been attempted.

Hello, We develop a sandboxed Mac App Store app that runs virtual machines with Virtualization.framework on Apple silicon (macOS 27). Users want to install a macOS guest onto an external USB disk and start the VM from it, so they can keep a VM on portable storage or on a disk larger than the Mac's internal drive. What we tried USB passthrough: we attach the disk before the VM starts, with VZUSBPassthroughDeviceConfiguration (from an AAUSBAccessory) on a VZXHCIControllerConfiguration. Linux guests install onto the disk and boot from it without problems. For a macOS guest, VZMacOSInstaller fails to start when the USB disk is the only storage: As we understand it, a macOS VM can only start from its own storage devices, never from a USB device, so even a successful install would not boot. VZDiskBlockDeviceStorageDeviceAttachment: this needs an open file handle to /dev/diskN. That requires admin rights, which a sandboxed app can't obtain, so we can't use it in our App Store app. Questions Is there a supported way to install a macOS guest onto an external USB disk and start the VM from it? Is there a sandbox-compatible way to get a VZDiskBlockDeviceStorageDeviceAttachment for an external disk, for example after user consent, similar to how AccessoryAccess grants USB devices? If neither is possible today, is support for this planned, or is there a recommended alternative? Thank you for any guidance.

Environment: macOS 26.6.2 (25G83) Xcode 26.6 (17F113) macOS command-line process Security.framework SessionGetInfo ASID obtained from the kernel-provided audit token in a received Mach message I’m implementing a security-sensitive Mach IPC receiver. The receiver obtains the sender’s audit token from the Mach message trailer and derives the sender PID, effective UID, and audit session ID (ASID). The sender executable identity is validated separately. Given the ASID, SessionGetInfo can successfully return the corresponding SecuritySessionId and session attributes. The question is about the freshness and synchronization semantics of that lookup. At the point where the receiver authorizes a request, can a successful SessionGetInfo(asid, ...) result be treated as authoritative evidence that the corresponding login/audit session is still currently valid? In particular: What happens if the session logs out, terminates, or is revoked concurrently with the lookup? Can SessionGetInfo successfully return information for a session that is no longer current due to caching or propagation delay? Are there documented ordering or synchronization guarantees between session termination and subsequent SessionGetInfo calls from another process? Can the lookup block for an unbounded period if the underlying security service is unavailable? Is there a supported timeout or cancellation mechanism? Is there another supported public macOS API better suited to establishing authoritative current-session liveness for an ASID obtained from an audit token? The security requirement is fail-closed. I’m specifically trying to avoid private APIs, process-table heuristics, diagnostic launchctl output, or assumptions that the ASID encoded in a previously received audit token necessarily represents current session state. If the public API does not provide an authoritative liveness/freshness guarantee, confirmation of that limitation would also answer the design question. I also have a minimal 122-line Xcode sample that: creates and receives a Mach message, reads the kernel-provided audit trailer, extracts the ASID, calls SessionGetInfo, and prints the returned session ID and attributes. I can provide the sample project if useful.

I'm developing an Accessibility-enabled app that includes a helper app registered as a launch daemon using SMAppService. This daemon will connect to HID which requires both being root as well as having Accessibility (or Input Monitoring) permissions. I want this app to have as little friction for the user as I can manage. One friction I'd like to avoid is requiring the user to grant more than one application permission to use Accessibility features. So I'm wondering if I can set up the launch daemon so that it inherits the TCC permissions of its parent bundle. I'll note that the one way I've found that works is to not have the helper app have its own app bundle, but rather just have it be an executable placed alongside the main executable in enclosing bundle's Contents/MacOS directory. This has the disadvantage though of having the helper process and main process have the same name in Activity Monitor, which I think will be confusing to users. So in short, is there a supported way for a bundled application with its own CFBundleName / CFBundleDisplayName key to run as a launch daemon and also inherit Accessibility permissions from its parent app bundle?

Reference environment: macOS 26.7.1, build 25G241, arm64, local APFS. Consistent capture of a source file We are evaluating NSFileCoordinator with the forUploading and withoutChanges options for a single regular file. Does the resulting snapshot guarantee byte contents corresponding to a single point in time, even if another process writes during capture without file coordination, using write/pwrite or a shared writable memory mapping? We need to establish the scope, conditions, and limitations of this guarantee. We do not require capturing an editor’s unsaved changes or application-level database consistency. If any of these concurrent writing methods are not covered, please identify them explicitly. Durability of the final filename after a rename We are evaluating the following sequence: a verified temporary file has successfully completed strong synchronization, and is then renamed using renameatx_np with RENAME_EXCL. The temporary and final names are in the same directory on the same volume. Next, fsync_volume_np is called with SYNC_VOLUME_FULLSYNC and SYNC_VOLUME_WAIT. Under what conditions does a successful return confirm that the final filename and its association with the prepared file contents will survive a system crash or power loss? We also need clarification on whether all relevant data and metadata write errors are propagated to the caller, or whether an earlier error might remain unreported by this operation. Please provide the documented scope and limitations for this environment.

We maintain a macOS product whose installer uses custom InstallerSection plugin bundles to show configuration panes during install. Starting with macOS 27 beta 6, all of our plugins stopped loading in Installer.app — the panes never appear and the install fails because our preinstall step depends on data the panes collect. The exact same .pkg works on macOS 26.6, and per thread 842811 the same bundles were fine on 27 betas 1–4(I have tested it from beta 6 onwards). While investigating we found what looks like the underlying cause, and it's reproducible by hand. THE FINDING During a failing install, look inside the extracted plugin bundle while the Installer window is still open: ls -la /private/tmp/com.apple.installer*/.bundle/Contents/ That layout fails code-signature validation. You can reproduce the failure manually, no Installer involved: codesign -vvv "/private/tmp/com.apple.installer"*/.bundle → .bundle: Too many levels of symbolic links WHAT THE SYSTEM LOGS SHOW amfid rejects the plugin executable: /private/tmp/com.apple.installerXXXXXX/.bundle/Contents/MacOS/ not valid: Error Domain=AppleMobileFileIntegrityError Code=-420 "The signature on the file is invalid" with repeated "UNIX error exception: 62" (errno 62 = ELOOP, too many levels of symbolic links) in backtraces through BundleDiskRep::component → SecStaticCode::component → validateNonResourceComponents → staticValidateCore, and "Code failed basic validity check (error: 100062)". For a Developer ID–signed plugin the kernel then treats it as fatal: AMFI: When validating /private/tmp/com.apple.installerXXXXXX/.bundle/Contents/MacOS/: The code contains a Team ID, but validating its signature failed. mac_vnode_check_signature: ... code signature validation failed fatally check_signature[pid: N]: error = 1 The plugin is never dlopen'd and the pane never appears. QUESTIONS Is there a way to get Installer to deploy the bundle with real files — or any other workaround? Note : I have Filed via Feedback Assistant as FB24601496; this overlaps FB24415432 / thread https://developer.apple.com/forums/thread/842811, which we've cross-referenced I have experienced this issue on latest Beta 8 build also -27.0 Beta (26A5425a)

For an application supporting iOS 16 and later, including iOS 18 and newer releases, I would like to clarify the supported guarantees for deciding whether persisted monotonic time evidence belongs to the current boot. I have read the DTS reply in “Time verification in iOS 18+” and the linked recommendation to use CLOCK_MONOTONIC with an exclusively created POSIX named semaphore: https://developer.apple.com/forums/thread/774658?answerId=825483022#825483022 https://developer.apple.com/forums/thread/110044?answerId=754364022#754364022 That recommendation describes semaphore cleanup on restart as a reasonable assumption. My question is specifically about the documented guarantees and safe failure conditions of that approach, rather than another request for a replacement for kern.bootsessionuuid. The required distinction is between process or application-engine restarts during the same boot and an actual device reboot. A continuity mechanism should remain valid across the former and distinguish, or safely invalidate, observations retained across the latter. It must not depend on an assumed-stable wall clock or on comparing uptime magnitudes that could overlap after a reboot. For an App Group-namespaced semaphore on supported iOS versions: Is cleanup at every device reboot, and persistence across ordinary process termination or suspension within a boot, a documented guarantee that an application may rely on? What sandbox, resource-limit, lifecycle or name-reuse conditions can invalidate that inference? Is there a supported way to avoid treating a recreated or unrelated same-name semaphore as proof that older persisted observations belong to this boot? If those guarantees cannot be established, is there another supported boot-continuity mechanism? Please identify its OS availability and applicable privacy or required-reason API constraints. No raw boot identifier or raw uptime needs to be sent off-device. If supported cross-process continuity cannot be established, is a continuously alive native process's sleep-inclusive monotonic clock a documented comparison domain until that process ends? In that narrower design, all previous-process observations would be invalidated, accepting the loss of same-boot recovery. A process UUID or application-engine identity would not be treated as an operating-system boot identity. I am seeking documented guarantees, limitations or supported alternatives, not an undocumented sysctl or an inference from macOS behavior. This question concerns clock-domain continuity; it does not assume that continuity alone proves when a location observation was originally acquired.

We’re using an Enhanced Security helper extension with AppExtensionProcess and XPCSession to isolate native zero-knowledge proof generation from wallet and signing code. On an iPhone 15 Pro running iOS 26.6.2 (23G90), the helper terminates with: EXC_RESOURCE RESOURCE_TYPE_MEMORY: high watermark memory limit exceeded (limit=35 MB) Terminated due to memory issue Our current prover requires substantially more memory: its public proving key is approximately 402 MiB, and its witness workspace alone is approximately 69 MiB. The same proof engine has completed successfully in a standalone iOS app process. The helper currently processes only synthetic test inputs. We want to preserve the helper’s sandbox and Enhanced Security protections and use a configuration supported for App Store distribution. Is there a supported way to increase the memory limit for this specific helper extension type? Does com.apple.developer.kernel.increased-memory-limit apply to Enhanced Security helper extensions? If so, what provisioning, target configuration, and device/OS requirements apply?

On macOS 26.7.1 with Xcode 26.6 on Apple silicon, several directories in a development tree carry the private extended-attribute names com.apple.fileprovider.dir#N and com.apple.fileprovider.fpfs#P. On this host, the supported xattr_flags_from_name decoder returns XATTR_FLAG_NEVER_PRESERVE for the first exact name and XATTR_FLAG_NO_EXPORT for the second exact name. Apple's public API defines those flag meanings; the literal name encoding and the attributes' private values are not treated as a public semantic contract. We want a self-contained APFS compilation-input tree using descriptor-based COPYFILE_DATA for regular files, with independent inventory and hash verification and no private-xattr copying. For this compilation-only export, does Apple support deliberate non-preservation when xattr_flags_from_name returns XATTR_FLAG_NEVER_PRESERVE, and when it returns XATTR_FLAG_NO_EXPORT for a governed SHARE operation? Separately, what public, non-hydrating API can establish that every required file is already fully materialized and that export will not trigger provider downloads? Does enumeratorForMaterializedItems establish that state for a closed descendant tree, or must each item be checked by another supported API? Can reading or hashing an item itself cause materialization? We are asking about documented APIs, supported export behavior, and security postconditions. We are not asking to decode or preserve private attribute values. No production paths, source code, credentials, datasets, or personal information are included.

On macOS 26.7.1 with Xcode 26.6 on Apple silicon, a small set of ordinary development source/resource files and one project directory carry the private extended attribute com.apple.macl. We need to create a new APFS compilation-input tree, not a filesystem backup. The proposed implementation opens source and destination objects using descriptor-relative no-follow traversal and calls fcopyfile(sourceFD, destinationFD, NULL, COPYFILE_DATA), then independently verifies exact content hashes and applies an explicit destination mode and ACL policy. It does not request COPYFILE_XATTR, COPYFILE_ACL, or COPYFILE_STAT. Is omitting com.apple.macl supported for this data-only compilation export? Could preserving it transfer stale or inappropriate access authority to the destination? Which supported API or documented postconditions should establish the destination's correct security state? Is there an Apple-recommended procedure for exporting ordinary development source content without transferring private mandatory-access metadata? We are seeking an API and security contract, not an interpretation of the attribute's private bytes. No production paths, source code, private attribute values, credentials, datasets, or personal information are included.

Apple feedback FB25355124 The SMB client no longer accepts reads to symlinks that are an absolute path to a network volume or a symlink that contains a (..) in the relative path. Reproduction steps on an SMB mount with this file structure: dir a.txt Run this command from inside of "dir": ln -s my-link ../dir/a.txt Attempt to read that symlink: cat ./my-link Which results in this error: cat: link: Invalid argument which is translating to an EINVAL getting returned from the SMB client. Same behavior was observed when making a symlink with an absolute path: ln -s my-link /Volumes/Example/dir/a.txt The server is responding successfully to the IOCTL command but the client is still rejecting the request with that error. This behavior was not observed in macOS 26.6.2 (smbfs 6.0.1) as well as previous versions of macOS.

macOS guest (Virtualization.framework) freezes with all vCPUs halted right after a macOS update reboot - 3/3 on a macOS 26.7.1 (25G309) M4 host, seen with both UTM and Parallels Summary On a macOS 26.7.1 (25G309, beta/seed build) host with an Apple M4, every macOS guest that runs an in-place macOS update freezes at the same point: the in-OS phase of the update completes and reports success, the guest requests a reboot, records a shutdown stall 9 seconds later, reboots twice, shows the update progress screen for about a minute, and then stops. All four vCPUs enter WFI and never wake, paravirtualized graphics stops submitting, no I/O is pending on the host side, and no host service logs an error. The VM never recovers and has to be killed. Reproduced 3 out of 3 times, under two different front-ends (UTM and Parallels Desktop) and two guest versions (15.7.x and 26.6.2). Environment Host: iMac (Mac16,3), Apple M4, 16 GB RAM, macOS 26.7.1 build 25G309 (seed channel), installed the evening before the first failure. Primary guest: macOS 15.7.9 (24G830), hardware model VirtualMac2,1, 4 vCPUs, 6 GB RAM, 90 GB raw disk image (virtio-blk) stored on an external USB SSD. Networking bridged to the built-in Ethernet port. Devices enabled: memory balloon, audio, entropy, clipboard sharing; display 1920x1200 with dynamic resolution. Front-end for the primary case: UTM [version], Apple Virtualization backend. Guest was the only VM running, cold-booted, window open. Update being applied: MSU_UPDATE_24H23_patch_15.8_minor (15.7.9 -> 15.8). Other cases: a macOS 26.6.2 guest under UTM; a macOS 15.7.7 -> 15.8 guest under Parallels Desktop 26.4.2 (57518). Steps to reproduce Cold-boot a macOS 15.7.9 guest under Virtualization.framework, as the only VM on the host. In the guest: System Settings > Software Update > install macOS 15.8. Let it reboot. Expected The guest installs the update and boots into 15.8. Actual — timeline of the primary case (R = the moment Software Update requested the reboot; absolute timestamps are in the attached logs) R-23 min to R-5 min: UpdateBrainService prepares the update inside the guest, writing about 25 GB (two "disk writes" resource reports: 16.5 GB then 8.5 GB). No errors. R-1:56: post-logout install configured; disk space check passes (5.7 GB required, 40.7 GB free). R-1:44: "SUOSUPostLogoutInstallOperation: Applying MSU update". R: "Applied MSU update"; FileVault stash committed ("kAppleFDEKeyStore_commitStash success"); "Rebooting (success = 1, displayAsleep = 0, shutdown = 0)". This is the last line the guest ever writes to install.log. R+9 s: the guest writes a shutdown_stall diagnostic report. R+10 s: host sees ParavirtualizedGraphics "Device reset" / "PGDisplayNub[0]: Destroyed" (reboot #1). R+1:20: second device reset (reboot #2), 70 s after the first. On the host, the vmnet interface is torn down and recreated with no error, the AppleVirtualPlatformIdentity service completes boot attestation with no error, and the guest's graphics driver renegotiates ("Guest requested binary version: 209"). R+1:38: host logs "PGDisplay[0]: Change display mode to 3606x2254" — the guest is on the update progress screen. R+1:41 to R+2:25: the guest's six PGFifoThreads go idle one at a time. The progress bar stops partway. No further activity of any kind. R+11:35: spindump of the VM host process (com.apple.Virtualization.VirtualMachine): 0.042 s of CPU over a 5 s sample all four com.apple.virtualization.thread.cpu-N threads in Hv::Vcpu::run() -> HvCore::Hypervisor::VcpuStateManager::wait_for_interrupt() -> __psynch_cvwait cpu-0/cpu-1 wake on a ~20 ms timer tick and return to WFI; cpu-2/cpu-3 had not run for seconds no thread in any file read, write or fsync (no host I/O outstanding) PGFifoThreads last ran 550–614 s earlier process state Ss (sleeping), not U Host kernel log for the window: no USB, APFS, I/O error, timeout or reset entries. No hardware video decoder (AppleAVD) errors. The VM was left for over an hour with no change, then killed. Second case (same host, same day, UTM, guest macOS 26.6.2) Identical signature: two graphics device resets 69 s apart, display mode set 3 s after the second one, last graphics activity about a second later, then all vCPUs idle in WFI for ~6.5 hours until the VM was killed. Third case (same host, same day, Parallels Desktop 26.4.2, guest 15.7.7 -> 15.8) The guest was suspended in the middle of its update and resumed later. On resume ("-[_PGDevice willResumeWithSuspendState:error:]: Begin resume", preceded by "[VirtualMachineParameterBuilder] Failed to get auxiliary file identifier"), paravirtualized graphics never came back — its FIFO threads ran once and never again — and the guest's vCPUs sat in WFI. This may be a separate save/restore defect, but the end state is the same. What I believe is ruled out The in-OS phase of the update: it completed and reported success. Guest kernel panic: vCPUs are halted, not spinning, and there is no panic report on the guest's data volume. Disk space: 40.7 GB free in the guest at install time. Host storage stall: no uninterruptible wait, no I/O frames in the spindump, no kernel storage errors. Host hardware video decoder: no AppleAVD errors in the primary case. Host services: vmnet and AppleVirtualPlatformIdentity completed normally seconds before the hang. Guest memory: 6 GB allocated. Not yet isolated The VM images live on an external USB SSD; not yet reproduced from internal storage. The memory balloon, audio and clipboard-sharing devices were enabled; not yet reproduced with them disabled. A third-party VPN client was running on the host (guest networking is bridged, so guest traffic bypasses the host tunnel, but host firewall rules could still affect bridged frames). I don't have a confirmed-good in-place guest update on this machine from before 26.7.1, so I can't state with certainty that this is a regression. Frequency 3 of 3 attempts on this host. Attachments / available on request spindumps of the hung VM host process (primary case and second case) host unified-log excerpts for both hang windows the guest's full install.log the guest's shutdown_stall report and the two UpdateBrainService disk-writes reports sysdiagnose captured while hung, if obtained Has anyone seen macOS guests stop at this point on the 26.7.x seeds? If you can reproduce, your host build, hypervisor, and whether the VM image is on internal or external storage would be useful to compare.

Summary We use Virtualization.framework to run macOS guests on Apple silicon. When the guest is updated from macOS 15.6.1 to 15.8.1 inside the VM, the update writes a new boot loader, mBoot-20457.1.29, into the VM's auxiliary storage. After the update, the guest kernel can use only about 1.75 GB of the configured memory. The kernel wires the rest as VM_KERN_COUNT_BOOT_STOLEN. The guest swaps all the time, and builds become 7 to 18 times slower. The fault stays after a cold boot. The guest boot-args value is empty. Environment Host: macOS 26.7.2 (25G320), Apple M3 Pro, 36 GB Guest before the update: macOS 15.6.1 (24G90), installed from the IPSW Guest after the update: macOS 15.8.1 (24H32), installed with softwareupdate inside the guest VM configuration: VZMacOSBootLoader with the default ROM, VZMacPlatformConfiguration, VZMacAuxiliaryStorage, memorySize = 15032385536 (14 GiB), CPUCount = 6 A customer sees the same fault on macOS 26.6.2 with an M2 Pro host. Steps to reproduce Create a macOS 15.6.1 VM from the IPSW. Set memory to 14 GiB. Boot the guest and confirm the RAM. vm_stat accounts for about 14 GiB. In the guest, run: sudo softwareupdate --install "macOS Sequoia 15.8.1-24H32" --restart --agree-to-license --user <owner> --stdinpass After the guest restarts, run sudo zprint | grep BOOT_STOLEN and vm_stat. Shut down the VM, start it again, and do step 4 again. Expected result The guest can use about 14 GiB of RAM, as it could before the update. Actual result 15.6.1, before the update 15.8.1, after the update and after a cold boot hw.memsize 15032385536 15032385536 RAM accounted for by vm_stat (free + active + inactive + speculative + wired + compressor) about 13.99 GiB about 1.75 GiB VM_KERN_COUNT_BOOT_STOLEN not measured 12,845,072 KB (about 12.25 GiB) Swap activity Swapins 0, Swapouts 0 Swapins 225,835, Swapouts 267,316 nvram boot-args empty empty Auxiliary storage contents after the update The auxiliary storage has two boot loader slots. Each slot has a 16-byte HUFA header: magic, version, upgrade count, and slot offset from 0x4000. Header offset Upgrade count Slot offset Boot loader 0x4000 1 0x24000 iBoot-11881.140.96 (the original 15.6.1 boot loader) 0x5000 2 0x224000 mBoot-20457.1.29 (written by the 15.8.1 update) The VM boots the slot with the higher count, which is mBoot-20457.1.29. Workaround test (customer) The customer worked on a copy of an affected VM. They copied the iBoot-11881.140.96 slot over the active mBoot-20457.1.29 slot in the auxiliary storage. macOS 15.8.1 then booted with about 14 GB of usable RAM, and the RAM stayed correct after cold boots. Their results: Extraction and validation of nine Xcode versions: 9 to 10 minutes (it was 68 to 102 minutes). Xcode 26.1.1 simulator installation and cache preparation: under 7 minutes (it was more than 2 hours). This workaround changes Apple's signed firmware by hand... Not really a good idea. Related report A public report describes the same fault with UTM and the same boot loader version. It also says that the kernel computes the stolen value from the memSizeActual and memSize boot parameters that the boot loader supplies. The author filed FB24992831 (https://wadetregaskis.com/the-macos-sequoia-15-8-updater-stole-my-ram/) Questions Is this a known fault in mBoot-20457.1.29? Will a later update fix it? Is there a supported way to make a VM boot a specific boot loader slot? Or a supported way to roll back the boot loader in VZMacAuxiliaryStorage? Is there a configuration on the host or in the guest that makes mBoot pass the full memory size? We'd prefer to not make nvram read only if the new mBoot is absolutely needed for some reason.

Feedback ID: FB25090184 I've been tracking recurring fseventsd memory growth and slow file-change notifications on macOS 26.7.1 (25G241), with massive Bazel build trees. There seems to be a repeatable boundary inside event-table cleanup. I may be missing another reset path, but the live observations match the disassembly closely. In fseventsd 1413.160.2, ARM64E UUID CDD7E21B-7F60-3DD4-AA03-8B36745DC0F4, cleanup at RVA 0x4604 uses a 32-bit scan cursor at table+0x14. The guard at 0x464c/0x4650 skips scanning above 0xfffffdff. Each complete pass advances by 512. Bucket indexing masks the cursor, but the stored cursor keeps increasing. Starting at zero, it stops at 0xfffffe00 after 8388607 complete passes. Table resize resets the cursor. Two observed October 3 episodes reached exactly that value, accumulated zero-reference records, and recovered without a restart when the table doubled. The resize loop rehashes records rather than freeing them, so resumed cleanup after the reset seems to explain the recovery. The reviewed resize limit is 262144 buckets. On October 6, after the table reached that size, the next cursor exhaustion persisted. Physical footprint grew from 26.6 MB to 2.31 GB in about six minutes, and fresh FSEvents probes reached an 8-second timeout. A bounded walk found 199944 zero-reference records among 200000 visited. The walk was partial and unsuspended, with linkage errors; that is not a whole-heap count. Restarting only fseventsd restored advancing cleanup, approximately 5 MB footprint and millisecond probes. The client mix changed after restart, so this is not a controlled fixed-client comparison. Finder stayed running, and Desktop add/delete checks worked on both sides. An earlier stale-Desktop symptom may be a separate issue. The boundary and table-size prediction were recorded before the live observations. The Feedback report has the timeline, graphs, counter snapshots, record walks, stack excerpts, disassembly and read-only sampler source. No daemon binary or target memory was changed. Live counter access used a temporary SIP debugging exception; a severe memory/notification failure was also captured before that exception. There is not yet a small standalone workload reproducer or a patched-build comparison. Is the scan cursor supposed to wrap or reset independently of table growth? If this is the expected mechanism, is there another cleanup path that should keep reclaiming zero-reference records once the table can no longer resize?

We need a supported checkpoint after macOS installation before an independent process verifies and later boots the VM. We distinguish installer success, actual VM stopped state, application queue drain, reference release, and file synchronization. After installation completes without error and the same VM is stopped, can Virtualization still submit writes to the disk image or auxiliary storage? What documented barrier ends them? Does releasing all application references and autorelease scopes and draining the VM queue end storage writes by all SDK objects, internal tasks, and services? After the producer process exits and is waited for, can services, transferred handles, or pending framework buffers still modify either file? Is there a supported joint durability/consistency boundary for disk and auxiliary storage beyond the disk image Full guest-flush guarantee? What handoff sequence and platform versions does Apple support for sequential installation, offline verification, and boot processes? We are asking for the contract, not proposing forced stop, delayed hashing, or an undocumented recovery procedure.