General: Forums subtopic: Privacy & Security > General Forums tag: App Sandbox App Sandbox documentation App Sandbox Design Guide documentation — This is no longer available from Apple. There’s still some info in there that isn’t covered by the current docs but, with the latest updates, it’s pretty minimal (r. 110052019). Still, if you’re curious, you can consult an old copy [1]. App Sandbox Temporary Exception Entitlements archived documentation — To better understand the role of temporary exception entitlements, see this post. Embedding a command-line tool in a sandboxed app documentation Discovering and diagnosing App Sandbox violations (replaces the Viewing Sandbox Violation Reports forums post) Resolving App Sandbox Inheritance Problems forums post The Case for Sandboxing a Directly Distributed App forums post Implementing Script Attachment in a Sandboxed App forums post Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" [1] For example, this one archived by the Wayback Machine.

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.

I’m designing a small, controlled macOS test harness. Two separately signed, sandboxed applications communicate through a UNIX-domain socket in an App Group container. They run as non-root processes in a GUI user session. One application also launches a child that inherits its sandbox and an existing socket descriptor. Is there a documented, supported OS policy that preserves this IPC arrangement while preventing the test processes from retrieving, using or modifying credentials, including items in their own Data Protection Keychain access groups and reachable file-based keychains? The policy must also prevent creating credential stores/items outside the permitted test resources. Using a macOS-style TeamID-prefixed App Group avoids that group providing Keychain sharing, but does not establish denial of the remaining Keychain operations. Empty stores, avoiding API calls and relying on users refusing prompts are insufficient for this requirement. If a different execution context or isolation architecture is required, could you identify the supported mechanism and relevant documentation? I’m seeking platform guidance, without relying on private APIs or unsupported custom sandbox profiles.

On macOS 15.7.9 (24G830), arm64, using Xcode 16.4 (16F6), a locally built QA host fails to launch through LaunchServices using open -W. The recorded signature is ad hoc, with no TeamIdentifier; its only recorded effective entitlement is com.apple.security.app-sandbox=true. The historical launch returned -10810. Correlated logs report posix_spawn: Operation not permitted (errno 1). Host entry was not observed. A packaging revision embedded the same Info.plist in __TEXT,__info_plist. Recorded signature verification succeeded, but the next launch produced the same rejection. The responsible policy remains unidentified; these observations are not an independently validated minimal reproducer. What supported diagnostic procedure can identify the policy responsible for this rejection without disabling security protections or using an alternative launch route?

Apple DTS case 22893354: forum post and reply Apple asked for the question as a Developer Forums post, then a reply to the case email with the post URL. Nothing below has been posted or sent. 1. Forum post Post at https://developer.apple.com/forums/ (signed in, "Ask a question"). Suggested tags: XPC, App Sandbox, Endpoint Security Attach: fixtures/egress_guard/hp04/apple-descendant-sample/main.c, renamed to main.txt if the forum refuses .c. Title Keeping every descendant of a sandboxed XPC service's worker inside its lifetime (fork, double-fork, setsid) Body We are designing a macOS app that runs an unmodified third-party command-line tool for one task at a time. The plan is an app-bundled, sandboxed XPC service that launches the tool as a child process. The tool is not ours, so we have to assume it may fork without exec, double-fork, and call setsid(). For each run we need one guarantee: after the run ends, every process the tool created has stopped. "Ends" includes the XPC service crashing and the host app crashing, not only a clean cancel. If we cannot prove that, we cannot report the run as finished. What we have looked at so far: Killing the process group. A child that calls setsid() is no longer in the group. launchd's process-group cleanup for the job. As we read launchd.plist(5), that also covers the process group only. Tracking pids from fork and exit notifications, including Endpoint Security. Notifications can be dropped, and pids can be reused, so a list rebuilt from events is not proof that nothing is left. The attached sample shows the process shape without any sandbox or XPC. It starts a worker, the worker double-forks, and the grandchild calls setsid() and keeps writing to a log after the original process has exited. On macOS 15.6.1 the descendant shows parent pid 1 and its own session, and it keeps writing until it finishes on its own: // worker: fork twice, let the intermediate processes exit if (fork() > 0) _exit(0); if (fork() > 0) _exit(0); setsid(); // leaves the original process group and session for (int i = 0; i < 8; i++) { // append "tick i pid ppid" to the log, ppid is now 1 usleep(200000); }Build with cc -Wall -Wextra -Werror -o DescendantOutlivesParent main.c and run ./DescendantOutlivesParent /tmp/descendant-log /tmp/descendant-ready. Questions: Is there a supported mechanism that ties every descendant of a process started by an XPC service, including ones that called setsid(), to the lifetime of that service, so that they are terminated when the service exits or crashes? If the service is sandboxed, does sandbox inheritance (children inherit the parent's sandbox) also give us a way to find or terminate those descendants, or does it only restrict what they can do? If neither, what does Apple recommend for running an untrusted command-line tool where leftover descendants must be ruled out? For example, is a separate launchd job per run, a different process-management API, or Endpoint Security authorization the intended route? Can that mechanism be combined with per-run file access (one input folder and one scratch folder per run), without giving the tool a shared container or network access? We would rather learn that a guarantee is not available than build on an assumption, so a "this is not supported" answer is also useful to us. 2. Reply to the DTS email Reply to Apple's case email (keep the subject) after the post is live: Case-ID: 22893354 Hello, Thank you. I posted the question on the Developer Forums here: <FORUM POST URL> The sample project is attached to the post. There is nothing private in it. Best regards, <NAME>

Hello, I’m developing a native macOS application intended for Mac App Store distribution, with App Sandbox enabled. The intended feature is to let users connect their personal iPhone or iPad via USB, read the existing Home Screen layout, rearrange app icons and folders on the Mac, and apply the user-approved layout back to the device. The target devices are ordinary, non-supervised consumer devices, without MDM enrollment. Our current prototype detects the connected iPhone through public IOKit registry APIs. It does not access the Home Screen layout or modify the device. I have reviewed USB access entitlements and the device-management HomeScreenLayout payload, but have not identified a public API for this consumer-device workflow. Is there a public, supported API or documented integration mechanism for reading and updating these Home Screen layouts from a sandboxed macOS app? If supported, which framework and entitlements should we use? We would also need to understand any limitations around preserving folders, Dock contents, widgets, and empty icon positions. If this capability is not available through public APIs, could you clarify that limitation and the appropriate channel for submitting an enhancement request? This is a question about technical API availability, rather than a request for advance App Review approval. Thank you.

I am developing AirZcreen Desktop, a free macOS app that creates an independent extended display in the current user's Mac desktop session and streams only that display to one paired browser on the local network. The required behavior is a real extra macOS display onto which the user can move windows from other apps. The app must not capture, mirror, reconfigure, or make changes to existing physical displays. ScreenCaptureKit handles capture after the owned display exists. There are no user accounts, audio capture, or remote keyboard/mouse controls. Our prototype uses CGVirtualDisplay, CGVirtualDisplayDescriptor, CGVirtualDisplayMode, and CGVirtualDisplaySettings through Objective-C runtime lookup. These interfaces are absent from the public CoreGraphics headers in our installed macOS 26.2 SDK. We understand that App Review guideline 2.5.1 requires public APIs. We are seeking a supported replacement, not assistance using undocumented interfaces. A bundled helper owns the display and its cleanup, including parent-pipe closure and heartbeat timeout. An isolated App Sandbox build can create the display, capture it, stream it to Chrome, and remove it on normal Stop. This runtime result does not establish App Store eligibility. No build has been submitted for review. Is there a documented public API for a third-party sandboxed macOS app to create this kind of independent host display? If so, which framework, minimum macOS version, entitlements, and helper-process model should we use? If this capability is not currently available through public APIs, what is the appropriate way to file a request for it? The PGDisplay documentation describes a display for a guest operating system in a virtual machine, which does not provide the host-desktop behavior we need. I have not found a host-display creation API in the ScreenCaptureKit documentation. References: https://developer.apple.com/app-store/review/guidelines/#software-requirements https://developer.apple.com/documentation/paravirtualizedgraphics/pgdisplay https://developer.apple.com/documentation/screencapturekit

We are evaluating a separately App-Sandboxed GUI helper for one explicitly reviewed AIFF NAME edit on internal-disk APFS. The main app retains user-selected read-only access. The helper has only App Sandbox and user-selected read/write entitlements. We would like the supported API and failure/reconciliation contract before implementing physical-file edits. Bounded observation A local synthetic-fixture probe used macOS 27.2 (26B118), SDK 27.0, arm64, ad-hoc signing with Hardened Runtime, LaunchServices and the helper's own NSOpenPanel. Captured stat fields, raw xattrs and bytes were unchanged after selection and an O_RDONLY read. Across a later O_RDWR open/fstat/close gate, com.apple.quarantine was added and ctime changed; bytes stayed identical and close returned 0. There was no content-write call. This describes one observed build/run, not a general OS mechanism. We have not tested copyfile, clonefile or replacement paths. Questions Existing-file conflicts. We read the later DTS explanation in thread 850377 about path-based link/rename substitution limits. Our use case is an ordinary editor replacing an existing user-selected file while another uncoordinated app might edit or replace it. What supported pattern and limits should we use to avoid silently overwriting unrelated updates, detect conflicts and retain truthful indeterminate outcomes? Is any supported replacement operation conditional on the previously reviewed destination object/content version, or should that guarantee be treated as unavailable under this concurrency model? We do not assume a post-operation identity check prevents an earlier effect. Protected metadata. What preservation contract should this sandboxed helper rely on for quarantine/provenance, ACLs and unrelated xattrs through copy/clone, a native-field edit and replacement? The current copyfile/clonefile manuals describe metadata copying and exceptions, while FileManager replacement documents selected original metadata. If exact raw quarantine equality is not the supported invariant, which public properties or behaviors should verification check, including originally absent quarantine? We want to retain Apple's security semantics without stripping quarantine, normalizing undocumented flags or disabling App Sandbox. Replacement access. After selecting an existing file in NSOpenPanel, is FileManager's itemReplacementDirectory plus replaceItemAt a supported safe-save route under that file selection? What additional consent, if any, is required for temporary-file creation and namespace publication? We do not assume parent-directory access or propose adding selected-source write rights to the main app. Relevant references: FileManager replacement File coordination No user media, paths, saved grants, private logs or binaries are attached. We are seeking supported semantics and refusal boundaries before further implementation or experiments.

I’m reviewing a macOS metadata collector using synthetic fixtures only. Before implementing a replacement, I need clarification on supported startup behaviour. The intended boundary permits bounded metadata queries on explicitly approved objects while independently denying directory enumeration, file-content reads, writes and network access. These restrictions must apply during native runtime startup as well as collection. In existing synthetic testing, a native metadata helper and a minimal control both failed before reaching their entry markers under restrictive sandbox profiles. The recorded termination description was: failed to open root directory: /: 1 The exact open flags and calling frame were not established. Is there a supported public launch or runtime mechanism that permits the necessary startup operation while independently denying root-directory enumeration and prohibited file access? Specifically: Can this be achieved without initializing the helper outside the required boundary or granting broader root-directory read access? Which public APIs, runtime contracts and released macOS versions support it? What entitlements or permission changes, if any, would be prerequisites? How could the guarantee be verified using synthetic fixtures without enumerating the real root or reading protected contents? I’m seeking a documented mechanism or clarification of the specific unsupported requirement. Successful startup alone, source-level avoidance of directory listing, and private loader interfaces would not establish the required boundary. This is a documentation and architecture question. No real credentials, backups or customer data are involved. Any capability changes would require separate review.

Hello everyone, I have no background in IT or programming, and I do not have technical knowledge about computers. Because of my health problems, I have been trying to build a personal assistant, with the help of AI tools, to support me in my everyday work and activities. I would like to make clear from the outset that my goal is a local AI assistant running on my own Mac, including voice conversations, with my data and conversations staying on the computer. I am looking for help building this local solution, not recommendations for cloud chatbots or cloud voice services. Using online AI tools to help with development does not change that goal. That is the purpose of this project: to have assistance I can rely on, especially with things I do not know how to do on my own. The first step is to be able to have stable conversations with it in Romanian and German. However, I have become stuck while preparing to verify the app before installation, and I do not know how to continue safely without losing existing conversations or data. If someone with macOS experience could guide me or provide practical help to get past this step, it would mean a great deal to me. The technical appendix below was prepared with the help of AI tools, based on recorded technical evidence. Technical appendix Verification goal Before replacing the existing app, a separate copy needs to be verified in an isolated environment: without access to personal files unrelated to the test, without network access, and without affecting the existing app or its data. Complete saving and restoration of the actual conversations remain requirements that must be demonstrated before replacement; we do not consider them already verified. Environment and recorded error When this question was being prepared, system information reported macOS 27.0.1, build 26A434. However, the error below comes from a saved earlier attempt, not a new reproduction. The record of that attempt does not include the macOS or Ruby versions. The preparation used a custom sandbox-exec/SBPL profile and a /usr/bin/ruby supervisor, which was intended to launch /usr/bin/codesign to ad-hoc sign a verification copy. After removing the personal path prefix, the error was: bounded_child.rb: Operation not permitted @ realpath_rec - /Users (Errno::EPERM) The Ruby supervisor exited with code 1. No PID or outcome for the codesign process was recorded, and the copy remained unchanged and unsigned. We therefore do not present this result as a demonstrated failure of the signing tool or an Apple restriction on voice apps. Findings and corrections Source inspection showed that the preparation mechanism enumerated the ancestor directories beneath /Users but omitted /Users itself. The profile restricted reads in this area and did not have an explicit exception for metadata access to that directory. This finding is consistent with the observed denial, but it is not a diagnosis confirmed by a new access test. In a separate, inert copy, the directory enumeration and preflight check were corrected: if the necessary permissions are missing, launch is stopped. Tests of this correction verify only the preparation logic, not actual access within the sandbox. The denied attempt has not been repeated, the profile has not been broadened, and the candidate has not subsequently been signed, installed, or launched. Specific question While researching the project, we found this Apple DTS explanation of the difference between custom SBPL profiles and App Sandbox configured through entitlements. I am not looking for undocumented rules or a way to bypass the access denial. What is the documented, Apple-supported approach for isolating this verification workflow? Is an App Sandbox/XPC architecture appropriate when the workflow needs to invoke an Apple signing tool, or should app preparation, signing, and verification be separated into other isolation environments, such as a dedicated macOS virtual machine? Guidance on the appropriate mechanisms and their limitations would help us define the next safe step for the local app. Help in Romanian, German, or English is welcome. My heartfelt thanks to everyone who takes the time to read this and help.

Hello, I'm investigating the supported macOS mechanisms for supervising a single unprivileged, sandboxed worker process. The target environment is macOS 15.6 (24G84), Apple Silicon (arm64). The worker is intended to operate under a separate Standard user identity, with tightly restricted capabilities and no requirement to create child processes. The main challenge is the startup failure window: A controller initiates worker creation, but exits unexpectedly before spawn returns or before the worker's identity and authenticated handshake can be independently recorded. In this situation, we need a supported approach to prevent the worker from becoming an unaccounted-for process, or to recover sufficiently trustworthy custody to determine its lifecycle and cleanup state. I have reviewed direct child-process supervision, POSIX process groups, launchd job behaviour, sandbox inheritance, resource limits and process identification mechanisms. I would appreciate guidance on the following: Is there a public, supported macOS API or system service that provides recoverable process custody from initial worker creation, including controller failure during startup? Could an application-associated XPC service or launchd mechanism provide the required lifecycle relationship without granting the worker independent ongoing execution authority? Is generation-safe, audit-token-based process signaling available through a supported public interface, and what are its privilege and acquisition requirements? Is setting a hard RLIMIT_NPROC limit before worker operations a supported way to prevent further fork/spawn activity by an unprivileged worker? What limitations or exceptions should be considered? What can macOS guarantee about process termination and cleanup after controller failure, and what must remain application-level verification? I'm particularly interested in documented guarantees and supported APIs rather than behaviour observed only in tests or private interfaces. Any recommendations or references to Apple documentation would be greatly appreciated. Thank you.

Hi, I want something like sandbox-exec, so I can run things that I don't trust, and restrict their ability to read or write files to only certain locations. Like most software devs I have to download and run lots of code from the internet and the danger of this really annoys me. Unfortunately sandbox-exec is marked as deprecated and the APIs in sandbox.h say "No longer supported". I notice there is some new stuff in the Apple docs about "hypervisors" and "virtualization". https://developer.apple.com/documentation/hypervisor https://developer.apple.com/documentation/virtualization Would these APIs allow me to start and control a virtual copy of my macOS, to serve like a sandbox? Are there other solutions that people use? As an example, say that I need to download and run a copy of memcached. It's a typical open source project – you unpack a source tgz, then run configure; make and get a binary. Now I want to run that without worrying that some hacker injected a piece of evil code to copy my files and send them somewhere. So I want to say "run this binary, while disallowing file reads and writes, except for directories X,Y,Z, and disallowing network connections, except for listening on port 1234."

Hello, I am developing a native macOS utility using SwiftUI and AppKit, and I am investigating whether its power scheduling features can be implemented in a sandboxed app distributed through the Mac App Store. The intended functionality is: Schedule power-on from a fully shut-down state, not just wake from sleep. Schedule wake from sleep and shutdown. Let the user select weekdays and times, and modify or cancel the schedule. Keep the schedule effective after the user quits the app. For example, the user could explicitly configure power-on at 08:00 and shutdown at 22:00, Monday through Friday. My local prototype uses pmset with administrator authorization. For a possible Mac App Store version, I am looking for a supported implementation that does not execute privileged shell commands or run an application helper as root. What I have checked The documentation for IOPMSchedulePowerEvent states that it must be called as root. Calling that API directly therefore does not appear to remove the privilege requirement. App Review Guideline 2.4.5 requires sandboxing and prohibits requesting escalation to root privileges. I also reviewed launchd scheduling and user-supplied scripts through NSUserAppleScriptTask, but neither appears to provide a self-contained solution for scheduling power-on from shutdown without privileged operations. Questions Is there a public API or system-mediated authorization mechanism that supports this functionality from a sandboxed third-party app? Is there a requestable entitlement specifically applicable to power-event scheduling? If the complete feature set is unsupported, which operations are available within App Sandbox: power-on from shutdown, wake from sleep, and scheduled shutdown? The current deployment target is macOS 13 or later, on Apple silicon and Intel. If a supported solution requires a newer macOS version or specific hardware, that information would also be helpful. I am asking about supported API capabilities and architecture, rather than advance App Review approval. A documentation reference—or confirmation that scheduled power-on from shutdown is unavailable under these constraints—would help me choose the appropriate distribution model. Thank you.

For macOS 26.7.1 (25G241), Xcode 27.0 (27A266a), and macOS SDK 27.0, we request the supported, exact Info.plist schema for NSDataAccessSecurityPolicy: its value type, literal key names and nesting, item types, and identity-selector grammar. Can the policy allow only the owning process signed with a specific Team ID and signing identifier, without allowing all applications signed by that Team? Are cdhash or designated-requirement selectors supported, and how do process and installer/package identities differ? Please clarify the relationship to user consent and Full Disk Access exceptions, and confirm whether this configuration is supported for the macOS build listed above. Please provide primary documentation or an authoritative schema, rather than a schema inferred from NSUpdateSecurityPolicy.

Why are we doing this nonsense? We want to be able to run builds in a sandbox such that they can only see the paths they are intended to depend on, to improve reproducibility. With builds with a very large number of dependencies, there's a very large number of paths added to the sandbox, and it breaks things inside libsandbox. Either it hits some sandbox length limit (sandbox-exec: pattern serialization length 66460 exceeds maximum (65535), Nix issue #4119, worked around: Nix PR 12570), or it hits an assert (this report; also Nix issue #2311). The other options for sandboxing on macOS are not viable; we acknowledge sandbox-exec and sandbox_init_with_parameters are deprecated; App Sandbox is inapplicable because we aren't an app. Our use case is closer to a browser, and all the browsers use libsandbox internally. We could possibly use SystemExtension or a particularly diabolical use of Virtualization.framework, but the former API requires notarization which is close to a no-go for our use case as open source software: it is nearly impossible to develop the software on one's own computer, and it would require us to ship a binary blob (and have the build processes to produce one in infrastructure completely dissimilar to what we use today); it also requires a bunch of engineering time. Today, we can pretend that code signing/notarization doesn't exist and that we are writing an old-school Unix daemon, because we are one. The latter is absolutely diabolical and hard to implement. See this saga about the bug we are facing: Nix issue #4119, Nix issue #2311, etc. What is going wrong I can't attach the file fail.sb as it is too large (you can view the failing test case at Lix's gerrit, CL 2870) and run this: $ sandbox-exec -D _GLOBAL_TMP_DIR=/tmp -f fail.sb /bin/sh Assertion failed: (diff &lt;= INSTR_JUMP_NE_MAX_LENGTH), function push_jne_instr, file serialize.c, line 240. zsh: abort sandbox-exec -D _GLOBAL_TMP_DIR=/tmp -f fail.sb /bin/sh Or a stacktrace: stacktrace.txt Credits Full credits to Jade Lovelace (Lix) for writing the above text and filing a bug. This is submitted under FB16964888

I’m developing a sandboxed macOS app that needs persistent, read-only access to a user-selected folder. We are observing different behaviour between APFS and FAT32/exFAT after renaming the folder or moving it to Trash. The main problem is that the app can still track the folder while running, but cannot reliably restore the connection or identify its location after relaunch. Environment macOS 27.0.1 (26A434) Xcode 27.1 (27A9269) App Sandbox and user-selected file access enabled Folder selection through SwiftUI fileImporter Bookmark creation: .withSecurityScope and .securityScopeAllowOnlyReadAccess Bookmark resolution: .withSecurityScope The selected items are ordinary folders, not volume roots. Filesystem comparison APFS: the tested workflows appear to work as expected, including restoration after relaunch. exFAT: we have reproduced both bookmark renewal failure after a rename and loss of the “in Trash” classification after relaunch. FAT32: we have observed automatic bookmark renewal failures after a rename. The detailed debugger trace and Trash reproduction below were collected specifically on exFAT. Rename reproduction Select a folder through the system picker. Create and persist a read-only security-scoped bookmark. Resolve the bookmark and start accessing the resolved URL. Retain that URL and keep its security scope active throughout monitoring. Rename the folder in Finder while the app remains running. Attempt to create an updated bookmark for the same folder. The monitor retains an O_EVTONLY directory descriptor. After the rename, F_GETPATH returns the correct new pathname, and runtime identity checks still match the monitored folder. However, creating a bookmark using a URL reconstructed from that new pathname fails. Calling startAccessingSecurityScopedResource() on the reconstructed URL returns false, while the original resolved URL’s scope remains active. The bookmark creation call uses: url.bookmarkData(options: [.withSecurityScope, .securityScopeAllowOnlyReadAccess], includingResourceValuesForKeys: nil, relativeTo: nil) Exact failure measured on exFAT LLDB shows that Foundation’s internal open(): Receives the correct new pathname. Uses flags 0, meaning O_RDONLY. Immediately returns -1. Sets errno to 1, EPERM, read immediately on the same thread. The correlated Foundation error reports: NSCocoaErrorDomain Code 256 Could not open() the item: [1: Operation not permitted] This is a failed read-only open during bookmark creation. We have not established which policy causes the EPERM. A log stream filtered for com.apple.sandbox.reporting / violation produced no report during reproduction. We understand that this does not exclude sandbox involvement. We also tested a native CFURL file reference retained from before the rename. It continued to follow the folder and match its identity, but security-scoped bookmark creation from that reference also failed. Reselection works, but requires user intervention Selecting the same renamed folder again through fileImporter allows creation of a new bookmark. That bookmark resolves, is not stale, and restores access after relaunch. Without reselection before quitting, the previously saved bookmark does not restore access to the renamed folder on the next launch. The app reports it as unavailable. Separate Trash reproduction on exFAT Move the monitored folder to Trash using Finder while the app is running. The app correctly identifies the folder as being in Trash. Quit the app, leaving the folder in Trash. Relaunch: the app reports the folder as unavailable. The folder remains in Trash on the same exFAT volume. It has not been restored or permanently deleted. We also encountered failures when inspecting the Trash relationship using FileManager.getRelationship(_:of:in:toItemAt:) with .trashDirectory. We have not established whether these observations share the cause of the rename failure. Questions What is the supported public-API approach to preserve security-scoped folder access across an external rename on exFAT/FAT32, including after relaunch? What should bookmark resolution return for a folder moved to Trash, and how should a sandboxed app distinguish that condition from an unavailable resource after relaunch? Are these expected filesystem limitations, problems in our API usage, or behaviours that should be reported as macOS bugs? What additional diagnostics would help distinguish them? Ideally, the solution would preserve the original folder authorization without requiring repeated reselection or access to the parent directory or entire volume. I have read Accessing files from the macOS App Sandbox. I also found this discussion of bookmark failures involving exFAT, but it concerns volume roots and an earlier macOS release, so I’m not assuming it explains our case.

Short version: we run a sandboxed helper as a hidden service account, started at boot by an SMAppService daemon. It works, even before login. But when the user turns our app off in Background App Activity, only the daemon stops. The helper keeps running. Is this setup supported, and what's the right way to manage the helper? What we want A Developer ID signed, notarized app (not Mac App Store) with a helper that parses untrusted input. The helper should: run as a dedicated, hidden, non-login local account; use App Sandbox, with its own container; be available before anyone logs in (after FileVault unlock). What we built An unsandboxed root LaunchDaemon, registered with SMAppService.daemon, runs this at boot: launchctl bootstrap user/<serviceUID> <fixed-agent-plist> The agent plist uses LimitLoadToSessionType=Background. The helper is a nested app in the same bundle, with com.apple.security.app-sandbox=true. We don't create a GUI session, change UID after the sandbox starts, or use private APIs. What we measured macOS 27.0 (26A428), arm64, dummy data only: Register and approve: the daemon starts. The helper starts as UID 60000, its container works, and reads outside it are denied. Turn the app off in Background App Activity: the daemon gets SIGTERM and stops. The helper keeps running (same PID). Turn it back on: the daemon starts again. Its bootstrap returns exit 5, because the old helper is still loaded. Call unregister(): the daemon stops. The helper keeps running. Cold boot (tested with a plain /Library/LaunchDaemons job, not yet SMAppService): the helper started and worked before login finished. For comparison, running the same sandboxed helper as a system daemon with UserName set to this account fails before main: Incoming message euid:60000 does not match secinitd uid:0. Questions Is this setup supported for shipping, including the sandbox starting before anyone logs in? Does the approval for daemon-bundled helpers cover a helper bootstrapped into another account's domain? Our plan: when the daemon gets SIGTERM, it runs bootout on the helper and its domain, and it treats bootstrap exit 5 as "already loaded". Is that the intended pattern, or is there a supported way for the helper to follow the app's Background App Activity setting? If this setup isn't supported, what public mechanism gives a sandboxed helper its own non-root identity before login? I can share the plists, entitlements and logs from a minimal reproducer.

Update: I clarified the intended behavior after posting. The destination is the text input that has keyboard focus when the finished dictation is delivered, even if the user changed fields or apps while speaking. We do not need to return to the field where dictation started. I’m building a macOS dictation app for the Mac App Store, so it must run with App Sandbox enabled. For example, a user might start dictating with an input in Chrome focused, then click into a ChatGPT input while speaking. When the result is ready, it should insert at the ChatGPT caret. Moving the caret within one app should likewise change the destination. In an isolated signed sandboxed prototype, I write a marker to the general pasteboard and post Command–V with CGEvent.post after the user grants event-posting access. This inserts successfully in TextEdit at the current caret, including after a same-document caret move. That result is now consistent with the intended behavior. The prototype also has a frontmost-process guard that withholds insertion after an app switch; that is our own guard and could be removed. We have not yet verified cross-app delivery without it. The existing nonsandboxed app uses AXUIElement to inspect the focused field. Apple’s App Sandbox documentation lists assistive Accessibility APIs as incompatible with sandboxed apps. For a current-focus insertion design, is there any supported sandbox-compatible way to know whether the destination has a focused editable field or is a secure input, or to learn whether a posted paste was actually accepted? If not, is relying on the destination app’s paste handling and retaining the transcript for manual recovery the expected approach? I also tested an AppKit Service. TextEdit inserts its returned text when the caret stays put; after a physical click to another caret during a pending request, the provider returns but TextEdit inserts nothing. This does not appear to fit our hold-to-dictate, switch-apps-while-speaking interaction. I’d welcome experience with another system-mediated approach that does. Environment: macOS 27.0, Xcode 27.0, Apple Silicon. I’m asking about technical API behavior and implementation patterns, not a guarantee of App Review approval.

I have reproduced an issue with AVSpeechSynthesizer on macOS 26.6.2 (25G83) using a minimal Mac Catalyst application. Environment macOS 26.6.2 (25G83) Apple Silicon Xcode 26.x Mac Catalyst AVSpeechSynthesizer Enhanced voice: com.apple.voice.enhanced.en-GB.Daniel The problem is specifically related to App Sandbox. Reproduction I created a completely new minimal Mac Catalyst application. With App Sandbox disabled: let synthesizer = AVSpeechSynthesizer() let utterance = AVSpeechUtterance(string: "Hello, this is a test.") utterance.voice = AVSpeechSynthesisVoice(identifier: "com.apple.voice.enhanced.en-GB.Daniel") synthesizer.speak(utterance) The Enhanced voice works normally. With App Sandbox enabled, with no other sandbox capabilities enabled, the same code no longer produces audible speech.