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 preparing an update to a native macOS serial logger already distributed through the Mac App Store. The app uses IOSerialBSDClient to enumerate serial ports, opens the selected /dev/cu.* device with open(O_RDWR | O_NOCTTY | O_NONBLOCK), and configures it with termios. On macOS 27.2, open() returns EPERM with App Sandbox enabled and the USB and Bluetooth entitlements present. The same port opens successfully from a process without App Sandbox. I reproduced this with several adapters. Apple’s archived Entitlement Key Reference lists com.apple.security.device.serial and describes adding it manually: https://developer.apple.com/library/archive/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html The macOS 27.2 App Sandbox profile still contains a rule for this entitlement, but I couldn’t find it in the current entitlement documentation or in Xcode 27.2’s Signing & Capabilities editor. Is adding com.apple.security.device.serial manually to the app’s signed entitlements still the supported approach for new Mac App Store updates? Does it require separate approval or provisioning authorization? If this entitlement is no longer supported for Mac App Store submissions, what does Apple recommend for accessing system-provided BSD serial ports with App Sandbox enabled? The app needs to work with ports exposed by both system and third-party drivers and configure them through termios. Would a temporary file access exception for /dev/ be appropriate for this use case?

My Mac App Store utility removes Mac metadata files (._* AppleDouble files and .DS_Store) from external drives formatted exFAT or FAT32. The app is sandboxed with com.apple.security.files.user-selected.read-write and com.apple.security.files.bookmarks.app-scope. The user grants access to the volume through NSOpenPanel. Deleting a ._ file works, except when its companion file carries com.apple.quarantine (for example, a file downloaded with Safari and copied to the drive with Finder). Then: let partner = volume + "/Nirvana.zip" // has com.apple.quarantine let appleDouble = volume + "/._Nirvana.zip" removexattr(partner, "com.apple.quarantine", XATTR_NOFOLLOW) // -1, errno 1 (EPERM) unlink(appleDouble) // -1, errno 1 (EPERM)The same unlink succeeds from Terminal (not sandboxed, without Full Disk Access). On exFAT the extended attributes live in the ._ file, so I assume the sandbox refuses because deleting it would remove the quarantine attribute. Tried, with no change: Full Disk Access granted to the app. Adding com.apple.security.files.user-selected.executable (verified in the built app with codesign -d --entitlements -). On a real drive (a music library), about 71% of the ._ files belong to quarantined files, so this is most of what users want removed. Is there a supported way for a sandboxed app to remove these files: an entitlement, an API, or an explicit user action? If not, can you confirm it's intended behavior, so I can explain it accurately to users? macOS 27.2, Xcode 27.2, Apple silicon. Focused sample project available (one source file). DTS case 23240704.

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.

I am developing a macOS window-management utility for a new Mac App Store submission, targeting macOS 13+ on Apple silicon and supported Intel Macs. Its core function is to move and resize windows belonging to other, unmodified applications, in response to explicit menu commands, registered keyboard shortcuts, or optional edge-drag snapping. The current unsandboxed engineering implementation uses public Accessibility APIs: AXUIElementCreateApplication, AXUIElementCopyAttributeValue / AXUIElementCopyMultipleAttributeValues for window geometry, AXUIElementCopyElementAtPosition for drag targeting, and AXUIElementSetAttributeValue for AXPosition and AXSize. It requires explicit Accessibility consent. Window information is processed locally; the app does not transmit it. I understand that App Review Guideline 2.4.5(i) requires App Sandbox and that “Protecting user data with App Sandbox” lists assistive Accessibility API use as incompatible. The DTS answer in thread 789663 also explains that sandboxed apps cannot use Accessibility APIs, while noting that some use cases have alternatives. For this specific cross-application positioning/resizing use case: Is there a currently supported public API or documented, requestable entitlement that permits it in a newly submitted sandboxed Mac App Store app? If a supported alternative exists, what API/architecture and minimum OS requirements apply, including any approval process? If there is no supported route, can you confirm that this functionality cannot currently be delivered within the described sandboxed Mac App Store constraints? I am seeking a supported architecture for controlling other apps’ windows. The unsandboxed tests establish functionality only; they do not establish sandbox compatibility or App Review eligibility. References: https://developer.apple.com/app-store/review/guidelines/#hardware-compatibility https://developer.apple.com/documentation/security/protecting-user-data-with-app-sandbox https://developer.apple.com/forums/thread/789663

Traverse is a sandboxed macOS file manager with user-selected read/write access. For an input already carrying the complete raw com.apple.quarantine value 0086;timestamp;agent;event, a fresh private copy may receive 0082 with the remaining fields equal. This asks about the input state, without claiming a verified creation recipe for the retained test file. Our security requirement is equality of the entire original raw value before and throughout the interval when the destination name is reachable, including interruption immediately after publication. Is there a documented, supported App Sandbox API or operation that guarantees this for (a) a same-volume, same-inode move from private staging to an absent user-selected name, (b) a new file or extracted ZIP member, and (c) native Trash followed by restoration? If so, what OS/volume/entitlement scope and exact guarantee apply, and can the raw flags and event field be preserved without removing or replacing an OS-assigned quarantine mark? If no such public contract exists, please confirm that raw byte equality cannot be claimed from quarantineProperties, FileManager.trashItem, NSWorkspace.recycle, NSFileCoordinator, rename, clone/copy, or post-operation readback alone. We are not requesting a bypass of quarantine or a weaker substitute for 0086.

Is there an Apple-supported way on macOS 15.6 to run a sandboxed local storage service under a dedicated non-root user account, with a sandboxed SwiftUI client and administrator-authorized installation?

Our (sandboxed, distributed through the Mac App Store) app can optionally run as a CLI tool, to allow users to use it in scripts and other automation contexts. One of the usecases involves being a wrapper for the ssh command, but the ssh binary is not able to enable raw mode for stdin due to a sandbox violation (bug report). As a reduced example, I've created https://github.com/mihaip/sandboxed-cli-test, which has a minimal C program that uses tcsetattr to set attributes on stdin. That fails, and sandboxd logs to the console Sandbox: SandboxedCLI(30110) deny(1) file-ioctl /dev/ttys012. If I disable sandboxing on the binary then it works as expected. Looking through the sandbox profiles on /System/Library/Sandbox/Profiles, I'm not seeing cases where file-ioctl is enabled on /dev/tty. Are we out of luck, or is there a workaround?

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?

I'm planning to develop a macOS tiling window manager for potential distribution through the Mac App Store. Planned Features Detect application windows and observe focus changes. Move, resize, and focus windows belonging to other applications. Organize windows into app-defined virtual workspaces rather than native macOS Spaces. Display a separate workspace navigation bar without replacing or disabling the native macOS menu bar. Security and Permissions The application would: Use only public macOS APIs. Not load user-provided plugins. Not require root privileges. Request explicit Accessibility permission from users. Not replace or disable native macOS functionality. App Sandbox Considerations Apple's Protecting User Data with App Sandbox documentation lists "Use of accessibility APIs in assistive apps" as a restricted activity. Questions Sandbox restrictions: Does this restriction prevent a sandboxed application from managing windows belonging to other applications, even when the user explicitly grants Accessibility permission? Supported APIs and entitlements: Are there public macOS APIs or entitlements that allow these window management operations while remaining compliant with App Sandbox requirements? Mac App Store distribution: Is there an Apple-supported architecture or approach that would allow this functionality to be distributed through the Mac App Store? Goal I'd like to confirm the technical feasibility of implementing these features within Apple's App Sandbox and Mac App Store requirements before beginning development.

I am investigating a startup failure when running Node.js under a restrictive sandbox-exec profile. I would appreciate guidance on diagnosing the failure and on a supported way to run a command-line process with restricted filesystem access and no network access. I have not established whether this is caused by my profile, the operating system, or another interaction. Environment macOS 26.6.2, build 25G83 Apple silicon, ARM64, without Rosetta Official Node.js 22.23.4 darwin-arm64 distribution; its archive SHA-256 matches the published checksum Python 3.14 launching the process from Terminal No sudo, application code, third-party JavaScript modules, credentials, or real user data The Node version above identifies the downloaded distribution. I have not confirmed a successful node --version execution in this restricted environment. Launch configuration The invocation has this form: /usr/bin/sandbox-exec -f <PROFILE> <NODE> -e <JS> <INPUT> <WORK>Python uses subprocess.Popen, with: Working directory set to <WORK> start_new_session=True Standard output and error captured through pipes A 10-second execution deadline and a 6-second termination/cleanup allowance Only these environment variables are supplied; the parent environment is not inherited: PATH=<NODE_DIR>:/usr/bin:/bin HOME=<WORK> TMPDIR=<WORK>NODE_OPTIONS and DYLD_* are not set. The JavaScript starts with: console.log("NODE_JS_ENTRY");It then uses node:fs to read a synthetic input and write markers in the permitted work directory. The initial console marker is never observed. Filesystem and network restrictions The profile uses (deny default) and (deny network*). It permits process creation, execution of the specified Node binary, and sysctl-read. File reads are allowed for the Node binary, synthetic input/work directories, /System/Library, /usr/lib, and the specific devices /dev/null, /dev/random, and /dev/urandom. Ancestor-directory metadata access is listed using individual literal paths. Writes are allowed only inside the work directory. The Node binary and synthetic fixtures are in separate dedicated directories under the user's Documents directory. This is a description of the profile, not a complete runnable reproduction. Paths are anonymized here. I tested two additional permission variants: A — ancestor metadata and existence checks: (allow file-read-metadata file-test-existence (literal "/System/Volumes") (literal "/System/Volumes/Preboot"))A+B — the above plus Cryptexes reads and executable mapping: (allow file-read* file-map-executable file-test-existence (subpath "/System/Volumes/Preboot/Cryptexes"))Neither variant resolved the startup failure. No general Mach/IPC permissions, broad /etc read access, localhost access, or system.sb import were added. Observed results The original profile and both variants terminated with SIGABRT, without the initial JavaScript marker. For A and A+B: Python reported child return code -6. Standard output and error were both empty. The parent sent no termination signal; these were not timeout terminations. The direct child was reaped, and its process group was no longer present. For two earlier executions using the original profile, I matched saved crash reports to the process and Node binary image. They showed: Exception: EXC_CRASH / SIGABRT Termination namespace: 0x23 Termination code: 2 Termination flags: 582The stack included: __abort_with_payload abort_with_payload_wrapper_internal abort_with_reason ignition_halt boot_boot ignite dyld4::CacheFinder::CacheFinder dyld4::ProcessConfig::DyldCache::DyldCache dyld4::ProcessConfig::ProcessConfig dyld4::start startApple's public XNU definitions identify namespace 35 as OS_REASON_LIBIGNITION. I have not established the meaning of code 2 for this OS build. I have not inspected matching crash stacks for A or A+B, so I cannot claim they stopped at the same internal location. Questions Is sandbox-exec a supported mechanism for this use case on this macOS version? If not, what supported approach can enforce both restricted filesystem access and no network access for a command-line process and its children? What diagnostic information would distinguish a missing sandbox permission from a loader/cache initialization problem? Does this termination signature suggest a documented diagnostic procedure or known issue? My goal is to reach JavaScript execution while preserving the restrictions, rather than broadly allowing filesystem access or network communication. I can provide a sanitized profile and relevant diagnostic excerpts if needed. Thank you. Correction and update after checking the saved crash reports: The original-profile runs were on macOS 26.6.2 (25G83), while the A and A+B runs were on macOS 26.7.2 (25G332). My initial post did not distinguish these environments correctly. The saved reports for A and A+B have now been matched to the recorded execution times, process IDs, and Node image information. Both show SIGABRT, termination namespace 0x23, code 2, and the same 11-frame sequence of function names and offsets as the original-profile reports, including ignite, boot_boot, and ignition_halt. The Node image UUID is unchanged, but the OS version and dyld image identifiers differ. These results therefore must not be treated as a controlled comparison in which only the sandbox profile changed. The matching termination signatures do not establish an identical root cause. The specific reason for LIBIGNITION code 2 remains unknown. No additional executions or permission changes have been performed.

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.