I’m designing a least-privilege system LaunchDaemon registered with SMAppService, and I’d like to clarify whether the following architecture is supported by public macOS contracts. The LaunchDaemon declares a MachServices entry. Its steady-state service must run as a dedicated non-root account and later creates an NSXPCListener for that Mach service. We currently launch the daemon directly using UserName, GroupName, and InitGroups=false. However, InitGroups=false does not appear to guarantee that the resulting process supplementary-group list is limited to the service’s intended group. In testing, the daemon received a supplementary group outside our accepted set. We therefore do not want to depend on incidental inherited launch-time group state. We are considering this alternative: launchd starts a small, fixed, code-signed bootstrap executable as root. The bootstrap reads the target UID/GID from an existing protected root-owned binding record. It establishes an exact credential state using public BSD APIs, conceptually: setgroups(...) setgid(...) setuid(...) It verifies the resulting non-root credentials. It creates no XPC listener or storage connection while privileged. Without forking, it permanently replaces itself using execve() (or possibly POSIX_SPAWN_SETEXEC) with another fixed, separately signed executable in the same bundle. That non-root executable independently validates its security state and then creates NSXPCListener(machServiceName:) for the Mach service declared by the original LaunchDaemon job. The bootstrap would not remain as a privileged parent or supervisor. My main questions are: Is a same-PID exec after permanent UID/GID/supplementary-group reduction supported for an SMAppService system LaunchDaemon before it checks in to its declared Mach service? Does the exec-replaced process retain the launchd/bootstrap context required for NSXPCListener(machServiceName:) to check in to that Mach service? If so, what execution context must be preserved across exec (for example bootstrap context, environment, file descriptors, or Mach rights)? Is there a documented way to preserve only the context required for the LaunchDaemon/Mach-service relationship without carrying unintended root-derived capabilities into the non-root executable? Would SMAppService.unregister() / normal launchd termination continue to treat the exec-replaced process as the same LaunchDaemon job? If this topology is not supported, is there an Apple-supported way to establish an exact supplementary-group set before a non-root SMAppService LaunchDaemon begins handling its Mach service? The goal is to avoid relying on undocumented launchd behavior, incidental supplementary groups, private APIs, or a long-lived privileged helper. I’m specifically looking for the supported contract here rather than whether this happens to work on a particular macOS release.

Circling back on the LocalLM Lab arc. With v0.7, we've moved from prompt experimentation into real app development on Apple's Foundation Models local AI. The LocalLM Lab SDK lets you build that same on-device model and MCP client this thread has covered directly into your own app, with real tool and data access (Slack, Todoist, GitHub, Notion, Linear, plus Calendar, Reminders, Contacts and Location). And you can ship your app including through the Mac App Store. This is a big improvement over version 0.6, where the localai-cli toolkit needed LocalLM Lab installed and running. On the other hand, the SDK (LocalLMLabSDKCore) doesn't relay through anything; it links FoundationModels and a real MCP client directly into your own binary and is totally self-contained. The example included in the SDK, Plate Today, has actually been built into a sandboxed test app and verified working, with a signed path to a Mac App Store .pkg (Apple Distribution signing + provisioning profile pipeline). That's "verified signable and sandbox-compatible," to be precise. Entitlements (from personal experience: always a complicated topic): com.apple.security.app-sandbox + com.apple.security.network.client for the app itself, plus the standard personal-information entitlements per connector used (com.apple.security.personal-information.calendars, .addressbook, .location) and matching NS*UsageDescription strings in Info.plist. The one worth flagging specifically: the network entitlement is easy to miss and fails silently rather than throwing. Without it, MCP connections and Weather calls just hang with no error surfaced. OAuth handling requires the app delegate callback (application(_:open:)), not SwiftUI's .onOpenURL. Worth knowing before wiring it up if you're SwiftUI-only. Full entitlements list + SDK guide: https://github.com/ancientcomputing/locallm/blob/main/docs/sdk-guide.md Feature page: thisbrain.ai/locallm/sdk.html I hope the availability of the SDK (free, Apache 2.0 license) will give folks further incentive to explore local AI-enabled applications on the Mac. What else would you want to do that the SDK doesn't currently support? File picker? Calendar/Reminders/Contacts edits & writes?

Hi, I'm posting a boot crash here. Environment Hardware: Macbook M5 Pro OS Version: macOS 26.3.1 (25D2128) and matching version of KDK from official apple download page Kernel Version: Darwin Kernel Version 25.3.0 Reproducibility: Consistent Here is my panic log --- I truncated one field "SOCDNandContainer" as the original log is too long to post, hitting the size limit. I followed a blog post to boot the development kernel as the ReadMe file from KDK only contains instructions for Intel Macs. https://jaitechwriteups.blogspot.com/2025/10/boot-custom-macos-kernel-on-macos-apple.html I've tried a few 26.2 KDKs before 26.3.1 public launch, and they all showed same errors (26.1 and 26.0 KDKs don't have any development kernel for T8142 chip). Also, I own two fresh M5 Pro, and it is consistent across the machines. The highlight is panic(cpu 8 caller 0xfffffe0050e18010): [Exclaves] $JgOSLogServerComponent.RedactedLogServer.init(logServerNotific:OSLogServerComponent\/OSLogServerComponent_Swift.swift:815: Fatal error: invalid rawValue for TightbeamComponents.RedactedLogSer at PC ... Is this a genuine bug or am I following a wrong guide to boot the development kernel? I don't think the blog is wrong because I'm able to boot the "release" kernel included in the KDK on the same M5 Pro, and the "development" kernel on M4 Mac Mini, using the same routine. Just to be clear, I'm not compiling XNU myself, but am using the ones included in the kit.

macOS Tahoe appears to ignore /etc/fstab ro and noauto — findings and workaround I encountered what appears to be a regression in macOS Tahoe where Disk Arbitration no longer honors ro and noauto policies in /etc/fstab for external volumes. I am posting my findings here both to see whether others can reproduce the issue and to document a workaround, particularly for anyone using macOS for disk recovery or other workflows where preventing writes is important. The problem A configuration such as: UUID= none exfat noauto does not prevent the volume from automatically mounting. Similarly: UUID= none exfat ro does not result in a read-only mount. I also tested: UUID= none exfat ro,noauto with the same problem. This configuration worked for me before upgrading from macOS Sequoia to Tahoe. I initially suspected this might be related to Tahoe's newer exFAT/FSKit path, but testing APFS produced the same general behavior. It therefore appears to be broader than exFAT alone. /etc/fstab itself is being parsed correctly I tested the libc fstab interface using getfsent(). For example, an entry containing noauto is returned as: spec=UUID= | file=none | vfstype=exfat | mntops=noauto | type=rw So this does not appear to be a simple malformed-fstab problem. Tracing also shows diskarbitrationd accessing /etc/fstab. What Disk Arbitration is doing Unified logs from an affected exFAT mount show the filesystem being successfully probed, followed by Disk Arbitration mount approval callbacks. After approval, the reported mount options are: Mount options nodev,noowners,nosuid and the volume is then mounted successfully. The ro policy expected from /etc/fstab is notably absent from those mount options. Direct read-only mounting still works The filesystem itself is capable of being mounted read-only. For example, for exFAT: sudo mkdir -p /Volumes/Exchange sudo mount_exfat -o rdonly /dev/diskXsY /Volumes/Exchange This produces a genuinely read-only filesystem; a write test fails as expected. So at least in my testing, the problem appears to be associated with the normal Disk Arbitration mounting path rather than an inability of the filesystem to support read-only mounting. A working noauto workaround Disk Arbitration still supports mount approval callbacks. I tested a small client using: DAApprovalSessionCreate DARegisterDiskMountApprovalCallback DADissenterCreate The callback checks the volume UUID against /etc/fstab. If the corresponding entry contains noauto, it returns: kDAReturnNotPermitted This successfully prevents the volume from mounting. The test output looks like: [BLOCK] mount request: /dev/disk5s1 [BLOCK] mount request: /dev/disk5s2 The volume remains unmounted. Interestingly, this also blocks: diskutil mount /dev/diskXsY because diskutil mount goes through Disk Arbitration. A direct filesystem mount such as mount_exfat, however, bypasses that approval request and can still be used to deliberately mount the filesystem read-only. Why this matters For an ordinary external disk, an unexpected automount may only be annoying. For data recovery, forensic inspection, or a failing disk, the difference can be important. If /etc/fstab says: ro I expect that policy to protect the source filesystem from writes. Silently mounting the filesystem read-write instead means that the volume becomes available to Finder and other background services. That is exactly what I am trying to avoid when working with a recovery source. For this reason, I would recommend verifying the actual mount state rather than assuming that an existing /etc/fstab ro entry is still protecting a disk after upgrading to Tahoe. For example: mount or: diskutil info /dev/diskXsY should be used to confirm the resulting state. Current workaround design I am currently using a small compatibility helper that treats /etc/fstab as the source of truth: /etc/fstab ↓ compatibility helper ↓ Disk Arbitration mount approval The daemon side handles mount policy before Disk Arbitration can automatically mount the volume. An explicit mount helper can then perform a direct filesystem mount with the options specified in /etc/fstab, including read-only mounting where required. The intention is not to replace /etc/fstab, but to restore the behavior that was previously provided by the system. Reproduction request If anyone else is running macOS Tahoe, I would be interested to know whether you can reproduce this with either: UUID= none apfs noauto or: UUID= none exfat noauto and similarly with ro. Please be careful when testing ro: use a disposable/test volume rather than a disk whose contents actually depend on remaining read-only. I have also submitted this to Apple through Feedback Assistant. Feedback ID: 24677522 I will update this post if Apple provides additional information or if a later Tahoe update changes the behavior.

I'm a font developer. In the development process, I will revise a font and overwrite the OTF file that is currently enabled (registered) with macOS. If I then launch an app, it will immediately use the revised version of the font; while apps that are already loaded will continue to use the old version. This suggests that each app is loading new and separate font data, rather than getting it from some existing cache in memory. Yet macOS does have a "font cache" of some sort. Some apps, like TextEdit, seem to only load the fonts that they need to use. However, other apps, like Pages, load every enabled (registered) font on the OS!! (According to the Open Files list in Activity Monitor.) Given that /System/Library/Fonts/ is 625 Mb, and we can't disable any of it, isn't that a lot of data to be repeating? How many fonts is too many fonts? I can't find much documentation about the process.

[Q] Is it a known issue that the Xcode static analyzer hallucinates past results? Basically, the issue I've been observing for a few releases of Xcode now (including 27b) is that if you run a static analysis, fixes the reported issues and re-run a static analysis, you will get exactly the same results as with the first run. It's as if Xcode did not take into account the fixes. If you clean the builds (cmd + shift + K), and run the analysis again, this time, you will get up-to-date results.

FB24091347 On macOS 27.0 beta (26A5388g), MacBook Pro M4 Pro, the built-in ProMotion display never settles on a stable refresh cadence. Scrolling in SwiftUI judders constantly. The same app binary was smooth on macOS 26, and is smooth on a 120 Hz ProMotion iPad. I captured two 60-second Instruments traces — same app, same scene, same scrolling, no external display — changing only the display's refresh-rate setting. On ProMotion the vsync interval standard deviation is 4.093 ms across six different cadences, mostly flip-flopping between 120 Hz and 60 Hz. Forced to a fixed 60 Hz it drops to 0.391 ms with a single cadence. The app presented an identical 59 fps median in both runs — frame production is perfectly steady, the display just holds each frame for an unpredictable length of time. That's what makes this nasty: it's invisible to every frame-rate metric, so it looks like the app got slow when nothing about the app changed. I spent most of a day profiling my own code before realising the app was never the problem. Workaround: force the built-in display to 60 Hz. Worth noting, because it complicates the picture: attaching a 60 Hz Studio Display makes the built-in smooth, but the Studio itself then judders — despite its own vsync cadence measuring perfectly stable. So refresh rate alone isn't the whole story, and there may be a second mechanism. The clean, reproducible, single-variable result is the ProMotion vs forced-60 Hz comparison on the built-in panel. If you can reproduce this on an M-series MacBook Pro on 27 beta, please file a duplicate referencing FB24091347.

I’m looking for the documented Security.framework/macOS contract for this exact same-process sequence. An app creates a P-256 private key with SecKeyCreateRandomKey using: kSecAttrKeyType = kSecAttrKeyTypeECSECPrimeRandom kSecAttrKeySizeInBits = 256 kSecAttrTokenID = kSecAttrTokenIDSecureEnclave and, within kSecPrivateKeyAttrs: kSecAttrIsPermanent = true kSecAttrApplicationTag = <a unique tag> The app keeps the SecKeyRef returned directly by SecKeyCreateRandomKey alive and copies the corresponding public key with SecKeyCopyPublicKey. The app calls SecItemDelete with a query that uniquely matches that exact keychain item, and SecItemDelete returns errSecSuccess. Immediately after SecItemDelete returns, in the same process and without releasing or reacquiring the private-key reference, the app attempts a private-key operation using that same creation-returned SecKeyRef. Does errSecSuccess contractually guarantee that the already-retained SecKeyRef can no longer perform private-key operations from the point SecItemDelete returns? More concretely, is the following outcome forbidden by the API/platform contract: SecKeyCreateSignature succeeds after deletion, and the resulting signature verifies with the public key copied before deletion—that is, the public key from the same generated key pair? Or is invalidation of an already-issued SecKeyRef unspecified or otherwise not guaranteed by Security.framework? I’m asking only about the immediate post-return usability of the creation-returned SecKeyRef in this exact sequence. A clarification from Apple staff distinguishing the supported API/platform contract from current implementation behavior would be especially helpful.

Hi Apple Team, We are using the Accounts MDM payload with: PayloadType: com.apple.MCX DisableGuestAccount: true On macOS 26, even after the MDM profile is successfully applied, a local Administrator can still toggle the Guest User setting in System Settings. Expected: The setting should be enforced by MDM and should not be modifiable by an Administrator. Interestingly, the same configuration works as expected on macOS 27 beta, where the Guest User setting is shown as “This setting has been configured by a profile” and cannot be modified. Could you please confirm whether this is a known issue/regression in macOS 26 and whether there is a workaround or any permanent solution in later patches ? Environment: macOS 26.x Payload: com.apple.MCX DisableGuestAccount = true macOS 27 beta: Works as expected

When trying to access new Siri in macOS 27 beta 7 it always showing 'I’m having trouble with the connection. Please try again later.'. Tried changing the language multiple times and restarted the mac as well. But nothing resolved the issue. Has anybody faced this issue. is this related to network settings ?.

I am seeing a reproducible issue with macOS ControlCenter's per-app menu bar tracking state in a SwiftUI MenuBarExtra app. On launch the app creates its menu bar status item. ControlCenter then reads group.com.apple.controlcenter / trackedApplications, moves the app's status item host to the blocked list, sends NSStatusItemChangeVisibilityAction with visibility=0, and the app terminates because its only status item is removed. Two observations: Changing only the bundle identifier makes the menu bar item appear normally. In trackedApplications, the affected app has its own entry with isAllowed: true; a separate entry for another app has isAllowed: false, and that disallowed foreign entry's menuItemLocations contained an entry referencing the affected app. Removing only the affected app's reference from the other app's disallowed entry fixed the issue: the app launched normally, and ControlCenter no longer sent visibility=0. ControlCenter appears to associate one app's menu item identity with another app's disallowed tracked record, letting the foreign blocked record override the app's own allowed record. Is this expected? And is there a supported way to reset this per-app ControlCenter menu bar state without editing the protected group.com.apple.controlcenter plist directly? Testing Environment: macOS 26.3 (25D125) Xcode 26.3 (17C529) LSUIElement: true Sandboxed app SwiftUI MenuBarExtra Relevant log pattern: Host properties initialized; (bid:[AffectedApp]-Item-0-[pid]) State(applicationItem: true, clientRequestsVisibility: true, neverClip: false) looked up value <private> for key trackedApplications (Domain: group.com.apple.controlcenter) Moving host to blocked list; (bid:[AffectedApp]-Item-0-[pid]) Requesting blocked host to not be visible; (bid:[AffectedApp]-Item-0-[pid]) Sending action(s): <NSStatusItemChangeVisibilityAction: ...> Received action(s): NSStatusItemChangeVisibilityAction 0 agent requesting visibility=0 temporary=0 0 terminating on removal

Every macOS update fails during preflight personalization on my MacBook Pro (Mac15,6, Apple Silicon), currently on 27.0 build 26A5378j. It's failed on every build from beta 5 (26A5406e) through beta 7. Identical failure via Software Update and via startosinstall. It fails LOCALLY, before contacting Apple (gs.apple.com and gdmf.apple.com are both reachable with valid certs). Error (install.log + unified log): reaches PREFLIGHT_PERSONALIZE (~0.15), then aborts MobileSoftwareUpdateErrorDomain Code=1259 "failed to copy firmware identity" "could not obtain device identity information through SFR installer" SUMacControllerErrorPreflightPersonalizeFailed=7723 Root cause I've traced: an orphaned volume-group boot-policy directory in /System/Volumes/iSCPreboot/. ls shows two volume-group UUID dirs — the live one (matches diskutil info /) and an orphan (3D3287DE-...) with no corresponding APFS volume group (diskutil apfs list shows only one live group). Both date to Feb 2024. The preflight can't reconcile the System Recovery boot policy in the orphaned dir. Note: NOT caused by Erase All Content and Settings (unlike the commonly reported case). The orphan predates the beta, so any pre-existing second volume-group boot-policy directory reproduces it. It was harmless for ~2 years; macOS 27's stricter preflight rejects it. Ruled out (no effect): disk space, VPN, DNS, clock, Apple Account, refreshing the beta seed entitlement, reboot, Time Machine, re-downloading the installer, and Recovery reinstall (same 1259). Filed as FB24342236 — no response across beta 5, 6, 7. Questions: Is this a known issue with a planned fix, and in which build? Any supported recovery path that does NOT require a second Mac? (Recovery reinstall fails the same way.) Or is DFU Revive/Restore the only option? Will the public 27.0 release install on this machine, or hit the same preflight?

Is anyone else using one of the "Dark" editor themes (such as "Default (Dark)" or "Classic (Dark)" in Xcode? And is anyone doing this with Xcode 26 on macOS 26? Here's the result while using the "Default (Dark)" theme while my Mac is in "light" mode: Note that the black background of the editor goes all the way to the far left edge of the Xcode window. The large gray area in the project tree is the black background bleeding through the sidebar. This is really distracting. Is there a way to fix this (besides not using a dark theme - I've been using dark themes for over 30 years)? This appears to be a poor design decision in macOS 26 to have split views show the background of the secondary column behind the primary column. iPadOS 26 has the same issue (see https://developer.apple.com/forums/thread/800073).

Hello! First time posting here. As I'm using the fourth macOS Golden Gate public beta now, I'd love to see if there's more people who also think the battery percentage inside the icon looks unreadable. Dear Apple devs, could you please change the size of the battery icon or place the battery percentage outside, how it used to be in the older macOS versions? I don't have the poorest vision, yet it's still quite difficult to see it.

The iOS 26 sample below speaks well on iPhone/iPad devices and the iOS simulator. But it does not speak on "Mac (Designed for iPad)", with a voice downloaded via the macOS settings. Instead it issues this warning : Invalid maui voice identifier com.apple.voice.enhanced.en-US.Samantha How to make an iOS app speak on "Mac (Designed for iPad)", with a downloaded voice ? Note : I use iOS 26.5.2 and macOS 26.5.2. I use voices that can be found in System Settings > Accessibility > Read & Speak > System voice. I have checked that "Samantha (Enhanced)" is the "System voice" in the macOS settings. I have checked that the same issue occurs with other voices and other languages. There is no such issue for a voice that never needs to be downloaded. import AVFAudio import SwiftUI @main struct SampleApp: App { var body: some Scene { WindowGroup { SampleView() } } } struct SampleView: View { private var synthesizer = AVSpeechSynthesizer() var body: some View { Button("Speak", action: speak) } private func speak() { let utterance = AVSpeechUtterance(string: "I speak English.") utterance.voice = AVSpeechSynthesisVoice(language: "en") self.synthesizer.speak(utterance) } }

I am evaluating a macOS app for Apple-silicon Macs. I would like to know whether a third-party macOS app can create a new desktop display that ordinary existing macOS apps can use as a normal display. The intended use is an external landscape display used as a logical portrait workspace. The logical top half would be shown on the physical right half, and the logical bottom half on the physical left half. I have reviewed Quartz Display Services and ScreenCaptureKit. My understanding is that they support configuration or capture of existing displays, but not creation of a new host desktop display. Is there a supported public API for this on the current macOS release or the immediately previous release? If yes, please point me to the API and documentation. I am looking only for a supported public API path. I do not want to use private APIs, root privileges, kernel extensions, or bypass system security controls. Thank you.

So apparently Monterey has switched to creating .ips files instead of .crash files for application crashes. Console.app can convert these .ips files to "old-style" crash format. But is there a command-line tool to do the same thing?

I have an orphaned asset folder taking up 9.13GB located at: /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/c0d3fd05106683ba0b3680d4d1afec65f098d700.asset It contains SimulatorRuntimeAsset version 18.5 (Build 22F77). Active Version: My current Xcode setup is using version 26.2 (Build 23C54). I checked the plist files in the directory and found what seems to be the cause of the issue: The "Never Collected" Flag: The Info.plist inside the orphaned asset folder explicitly sets the garbage collection behavior to "NeverCollected": <key>__AssetDefaultGarbageCollectionBehavior</key> <string>NeverCollected</string> The Catalog Mismatch: The master catalog file (com_apple_MobileAsset_iOSSimulatorRuntime.xml) in the parent directory only lists the new version (26.2). Because the old version (18.5) is missing from this XML, Xcode and mobileassetd seem to have lost track of it entirely. What I Have Tried (All Failed) Xcode Components: The version 18.5 does not appear in Settings -> Components, so I cannot delete it via the GUI. Simctl: xcrun simctl list runtimes does not list this version. Running xcrun simctl runtime delete 22F77 fails with: "No runtime disk images or bundles found matching '22F77'." Manual Deletion: sudo rm -rf [path] fails with "Operation not permitted", presumably because /System/Library/AssetsV2 is SIP-protected. Third-party Tools: Apps like DevCleaner do not detect this runtime (likely because they only scan ~/Library or /Library, not /System/Library). Has anyone found a way to force the system (perhaps via mobileassetd or a specific xcrun flag) to re-evaluate this folder and respect a deletion request? I am trying to avoid booting into Recovery Mode just to delete a cache file. Any insights on how AssetsV2 handles these "orphaned" files would be appreciated.

I’m looking for clarification on supported public API semantics on macOS. Target runtime: arm64 macOS 15.4.1 build 24E263 The question is whether macOS provides a supported public API, or a supported composition of public APIs, that allows an external launcher or OS observer to: Obtain and freeze an identifier I(P) for the exact post-exec occurrence of a process P before P sends a security-sensitive IPC request. Later obtain OS-supplied sender identity J(M) for an individual XPC or raw Mach message M. Determine, using documented comparison semantics, whether J(M) identifies the same process-image occurrence as I(P). The comparison needs to distinguish cases such as: two concurrent processes with the same UID and signed code; exec replacement while retaining a PID; exit, restart, and PID reuse; stale or queued messages; a transferred XPC endpoint or Mach send right; an undelegated proxy. PID, UID, code-signing identity, launch labels, connection/right possession, or “first message wins” are not sufficient by themselves for this requirement. I have looked at mechanisms including: suspended process launch; task identity tokens; Endpoint Security AUTH_EXEC process identity; XPC per-message sender identity; SecCodeCreateWithXPCMessage; Mach audit trailers. What I have not found is public documentation defining a common process-occurrence identity and a supported comparison procedure across the pre-IPC and later message-sender surfaces. A token generated by the target and sent in its first message also would not solve this specific problem, because the process claiming the token has already selected itself before the external observer binds the expected occurrence. Is there a supported public way to achieve this? If so, I would appreciate pointers to: the relevant public APIs; the canonical comparison procedure; required entitlements, task rights, TCC permissions, root privileges, or system-extension requirements; documented behavior across exec, exit, restart, and PID reuse; relevant Apple documentation or sample code. If there is no supported public API that provides this property, confirmation of that would also be very helpful. I’m specifically interested in documented, supported public API semantics rather than private SPI or undocumented implementation behavior.

How can a local AI agent use MLX/Metal unattended while remaining confined to an authorized workspace? I am developing an AI-driven local media-processing workflow on an Apple-silicon Mac and am trying to understand the correct architecture for allowing it to run unattended without giving the AI agent unrestricted access to my primary personal computer. I am not a software engineer, so I may be missing an established macOS mechanism or using the wrong terminology. I would appreciate guidance from people familiar with MLX, Metal, sandboxing, and macOS security. What I am building I use OpenAI Codex as the local execution/software-development agent. The working system currently: ingests and verifies original video and still media while preserving immutable originals; performs visual semantic analysis and divides video into meaningful time-coded segments; separately analyzes spoken language rather than assuming audio and video are semantically equivalent; uses MLX Whisper locally on Apple silicon for time-coded speech transcription; stores visual and language semantics in a relational SQLite media catalog. These five stages are working. My current test corpus contains 148 original media files, 126 visual semantic segments, and 765 speech segments. The next stages are AI editorial construction from the semantic database and generation of instructions/scripts for a DaVinci Resolve rough cut. The security architecture I want Codex to operate autonomously within a deliberately bounded development environment. I do not want to solve this simply by granting an autonomous agent Full Disk Access to my primary personal Mac. The concern is ordinary fault containment. Codex generates and executes scripts, invokes applications and command-line tools, and manipulates files. A mistaken path or defective generated script should not have unrestricted consequences for the rest of my computer. I therefore separated AI execution from ordinary personal files. Codex is configured for Workspace Write access with explicitly authorized project roots. Canonical media resides on a separately authorized external SSD, and temporary AI working artifacts are kept separately. Ordinary Python and FFmpeg operations now run autonomously within these authorized areas. The problem The difficulty appears when the workflow invokes capabilities that cannot operate inside the ordinary Codex sandbox. The clearest example is MLX Whisper. I am using: MLX Whisper 0.4.3 mlx-community/whisper-small-mlx Apple silicon local transcription MLX Whisper works successfully and its transcription quality is sufficient for my semantic-retrieval application. However, MLX could not access Apple Metal/GPU execution from inside the ordinary Codex sandbox. Codex therefore requested permission to execute the transcription operation outside the sandbox. Once approved, MLX/Metal worked and the entire corpus was successfully transcribed. The processing therefore works, but the workflow cannot run genuinely unattended. A future operation should be able to run: new media → integrity verification → visual semantic analysis → MLX Whisper transcription → language semantic analysis → SQLite update → QA But if execution stops midway waiting for a human to click Allow, the pipeline is not operationally autonomous. What I have already tried I initially encountered permission problems even with ordinary file operations. I therefore: separated Codex work from ordinary personal documents; created dedicated project/work areas; explicitly authorized the required working roots; configured Workspace Write; separately authorized the external media repository; tested shell/Python and FFmpeg operations within those boundaries. Those changes worked. Routine Python and FFmpeg operations now run without approval prompts. The remaining issue occurs with MLX/Metal and some other application/runtime operations that require sandbox escalation. My question Is there a supported architecture for allowing a local AI agent to invoke MLX/Metal and other deliberately authorized development tools unattended, while still confining the agent to defined project/workspace boundaries rather than granting unrestricted access to the entire Mac? For example, should I be investigating: App Sandbox entitlements; a signed helper tool or XPC service; security-scoped resources; a dedicated executable with appropriate entitlements; a different method of launching MLX/Metal; or another macOS mechanism? In particular, can Metal/GPU access coexist with persistent bounded filesystem access without requiring interactive approval each time the AI invokes it? I am also unsure which security layer is actually responsible here: the Codex sandbox, macOS App Sandbox, TCC, executable/code-signing rules, Metal restrictions, or some interaction among them. If this kind of bounded unattended execution is intentionally not supported, that would also be useful to know. My alternative would be a dedicated Apple-silicon Mac containing only the AI-development environment and replaceable project data, where broader permissions would have a much smaller failure domain. I can provide the Codex configuration, exact successful and failing commands, directory/root configuration, macOS/hardware information, and sandbox diagnostics. I would particularly appreciate guidance on which security layer is causing the MLX/Metal escalation and what the supported architecture would be for this use case. Thank you.