macOS is the operating system for Mac.

Posts under macOS tag

200 Posts

Post

Replies

Boosts

Views

Activity

File Keychain ACL + partition list: how are the two authorization conditions combined?
I’m trying to clarify the supported authorization semantics for a private key in a file-based Keychain. I’ve read the existing Apple guidance around SecAccess / trusted applications and the commonly documented codesign setup that combines a trusted-application ACL with an apple: partition list. I think I understand those pieces individually, but I haven’t been able to find a public contract for how they compose when both are present. My case has three legitimate users of the same private key: a project-owned, reviewed helper that performs a bounded private-key challenge; /usr/bin/codesign; /usr/bin/productbuild. I want to grant no broader access than those callers and their required signing operations, and I don’t want to infer authorization semantics merely because a particular configuration happens to work on one macOS release. So my main question is: When a private-key ACL contains both trusted-application restrictions and a partition list, are these independent conditions that must both be satisfied by the calling process? In particular, suppose the trusted-application ACL explicitly contains my non-Apple helper, while the partition list contains only apple:. Is the helper expected to be denied because it does not satisfy the partition condition, despite being explicitly trusted by the ACL? If so, is there a supported partition configuration for a key that must be usable by both a specifically trusted non-Apple helper and Apple signing tools such as codesign / productbuild, without broadening access to an application class? I’m specifically looking for the supported contract here. A successful experiment would be useful qualification evidence later, but I don’t want to use that experiment to infer undocumented authorization semantics. Thanks.
2
0
959
Sep ’26
macOS Tahoe appears to ignore /etc/fstab ro and noauto — findings and workaround
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.
1
0
541
Sep ’26
Notice of Terminal shell change to zsh appeared on OS26.6.2 Suspicious?
Hi, I understand that users of mac OS 10 were notified that the Terminal default-shell had changed from Bash to zsh. I have not seen that message since. However, my current MacBookPro running OS26.6.2 has just popped up that old message: Last login: Tue Sep 15 17:42:23 on ttys000 The default interactive shell is now zsh. To update your account to use zsh, please run chsh -s /bin/zsh. For more details, please visit https://support.apple.com/kb/HT208050. MacBook-Pro:~ [My Name$] After all this time, should I be suspicious?
0
0
164
Sep ’26
Spotlight Shows "Helper Apps" That Are Inside Main App Bundle That Are Not Intended to Be Launched By The User
I have Mac apps that embed “Helper Apps” inside their main bundle. The helper apps do work on behalf of the main application. The helper app doesn’t show a dock icon, it does show minimal UI like an open panel in certain situations (part of NSService implementation). And it does make use of the NSApplication lifecycle and auto quits after it completes all work. Currently the helper app is inside the main app bundle at: /Contents/Applications/HelperApp.app Prior to Tahoe these were never displayed to user in LaunchPad but now the Spotlight based AppLauncher displays them. What’s the recommended way to get these out of the Spotlight App list on macOS Tahoe? Thanks in advance.
8
0
1.1k
Sep ’26
iMac gpuRestart and then crash
Hi all, This has been bothering me for quite a while. Basically my new iMac (bought for a few months only) started to crash randomly. I went to the genius bar and they couldn't do anything to identify the issue, I tried reinstalling the OS and even reinstalling an older version of Mac OS as well, but still seeing this issue. Today it happened twice and below are the details: Mac specs: Model Name: iMac  Model Identifier: iMac20,1  Processor Name: 10-Core Intel Core i9  Processor Speed: 3.6 GHz  Number of Processors: 1  Total Number of Cores: 10  L2 Cache (per Core): 256 KB  L3 Cache: 20 MB  Hyper-Threading Technology: Enabled  Memory: 16 GB  Boot ROM Version: 1554.100.64.0.0 (iBridge: 18.16.14556.0.0,0)  Serial Number (system): xxx  Hardware UUID: xxx  Activation Lock Status: Enabled The DiagnosticReports around the time it crashed has a lot of files with .gpuRestart, e.g.: Kernel_2021-04-27-213412_Zhuzengs-iMac.gpuRestart and file WindowServer_2021-04-27-213319_Zhuzengs-iMac.userspace_watchdog_timeout.spin in between. The details of the the first gpuRestart file Tue Apr 27 21:32:13 2021 Event: GPU Reset Date/Time: Tue Apr 27 21:32:13 2021 Application: Path: Tailspin: /Library/Logs/DiagnosticReports/gpuRestart2021-04-27-213213.tailspin GPUSubmission Trace ID: 0 OS Version: Mac OS X Version 10.15.7 (Build 19H1030) Graphics Hardware: AMD Radeon Pro 5300 Signature: 2 Report Data: GPU Log Version: 1 Restart Channel: 18 VMPT --THE STATE OF THE DRIVER AMDRadeonX6000_AMDNavi14GraphicsAccelerator state: ENABLED PCIe Device: [3:0:0], DID=0x7340, RID=0x47, SSID=0x219 TotalVideoRAMBytes: 0x00000000ff000000 (4278190080) Uptime 21:50:05.077572 [00] Channel: GFX, last reset at 0:00:00.000000 CompletedTS = 0x005be078, SubmittedTS = 0x005be079 SentTS = 0x005be078, sent at 21:49:00.896511, ScheduledTS = 0x005be079, submitted at 21:50:03.672539 Wait for Channel 18, TS 0xef924 PendingEvent: YES NumberOfPendingCB = 1, FirstPendingTS = 0x005be079, LastPendingTS = 0x005be079 FirstPendingCB: ProcessID = 225, ProcessName = WindowServer, SubmitContext = Unknown (0) GPUAddress = 0x0000000431cef000, Size = 0x000001d3, VMID = 2 ContentValidation = PASS Buffer range 0x0 .. 0x100:c0012800 80000000 80000000 c0026900 00000081 80000000 40004000 c0026900 By searching online this seems to be happening to others as well but I failed to find a common fix for this. Any help would be hugely appreciated!!!
3
1
1.9k
Sep ’26
Title bar double-click / Fill on macOS 27
I’m seeing a reproducible title-bar interaction issue on macOS 27 RC (26A428). This issue has been present since at least macOS 27 build 26A5416b (Developer Beta 6 / Public Beta 4) and is still reproducible on the Release Candidate, build 26A428. My System Settings → Desktop & Dock → Window title bar double-click action is configured to Fill. In several system apps with sidebars, including: Finder System Settings Reminders Feedback Assistant the right side of the title bar shows a visible rectangular region when the pointer hovers over it. The more important problem is that the middle portion of this region appears to intercept the title-bar double-click. Double-clicking there does nothing, while double-clicking very close to the top or bottom edge of the same region correctly triggers Fill. This makes the normal title-bar gesture surprisingly difficult to use because the center of the title bar is naturally where I would double-click. Interestingly, the sidebar area does not have this problem: double-clicking the top, middle, or bottom portions of the sidebar title-bar area all works normally. Feedback Assistant makes the behavior particularly easy to see because its left sidebar and rightmost pane behave normally, while the title-bar region above the middle pane exhibits the problem. Steps to reproduce: Set “Double-click a window’s title bar” to Fill in Desktop & Dock settings. Open Finder, System Settings, Reminders, or Feedback Assistant. Move the pointer over the right/content portion of the title bar until the rectangular hover region appears. Double-click around the center of that region. The Fill action does not occur. Double-click very close to the upper or lower edge of the same region. Fill works normally. I have reproduced this on macOS 27 RC build 26A428, including: a newly created macOS user account Safe Mode so it does not appear to be caused by migrated preferences, caches, login items, or third-party software. A screen recording demonstrating the exact hit-testing behavior was submitted through Feedback Assistant. Feedback: FB24462749 Is anyone else able to reproduce this? It looks as though some view or overlay in the new title-bar/toolbar area may be intercepting mouse events.
1
0
545
Sep ’26
SMAppService LaunchDaemon: is privilege drop followed by same-PID exec supported before Mach service check-in?
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.
4
0
688
Sep ’26
Macbook M5 Development Kernel Panic
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.
1
1
1.2k
Sep ’26
Is it a known issue that Xcode static analyzer hallucinates past results?
[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.
1
0
769
Sep ’26
Does SecItemDelete guarantee immediate invalidation of an already-retained Secure Enclave SecKeyRef on macOS?
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.
1
0
733
Aug ’26
DisableGuestAccount can be overridden by Admin on macOS 26
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
0
0
1.5k
Aug ’26
ControlCenter blocks a MenuBarExtra item due to foreign trackedApplications entry
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
Topic: UI Frameworks SubTopic: SwiftUI Tags:
3
0
1.3k
Aug ’26
Xcode 26 on macOS 26 with a Dark theme in Light Mode
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).
1
0
652
Aug ’26
macOS Golden Gate Beta battery percentage appearance
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.
0
0
515
Aug ’26
Is there a supported public API to create a macOS desktop display?
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.
1
0
569
Aug ’26
Supported public API to prebind a macOS process occurrence and match a later XPC or Mach sender
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.
2
0
1.2k
Aug ’26
How can a local AI agent use MLX/Metal unattended on macOS while remaining confined to an authorized workspace?
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.
0
0
876
Aug ’26
pkgbuild giving signing identity error
The actual error: pkgbuild: error: Could not find appropriate signing identity for “Developer ID installer: My Name (DeveloperID)”. I'm trying to sign a program written with gfortran. The steps worked the last time (Mar 23) I built this code. The steps to error: a) xcrun notarytool store-credentials --apple-id "xxx" --team-id "yyy" Giving Profile Name zzz and App-specific password b) codesign --force --timestamp --options=runtime -s "Developer ID Application: My Name (yyy)" AppName c) pkgbuild --root ROOT --identifier org.aaa.bbb --version "1.1.1" --sign "Developer ID installer: My Name (yyy)" AppName.pkg ROOT contains the package contents At this point I get the error pkgbuild: error: Could not find appropriate signing identity for “Developer ID installer: My Name (yyy)” Are there steps that have changed. Any suggestions? Thanks, David
Topic: Code Signing SubTopic: General Tags:
3
0
2.2k
Aug ’26
File Keychain ACL + partition list: how are the two authorization conditions combined?
I’m trying to clarify the supported authorization semantics for a private key in a file-based Keychain. I’ve read the existing Apple guidance around SecAccess / trusted applications and the commonly documented codesign setup that combines a trusted-application ACL with an apple: partition list. I think I understand those pieces individually, but I haven’t been able to find a public contract for how they compose when both are present. My case has three legitimate users of the same private key: a project-owned, reviewed helper that performs a bounded private-key challenge; /usr/bin/codesign; /usr/bin/productbuild. I want to grant no broader access than those callers and their required signing operations, and I don’t want to infer authorization semantics merely because a particular configuration happens to work on one macOS release. So my main question is: When a private-key ACL contains both trusted-application restrictions and a partition list, are these independent conditions that must both be satisfied by the calling process? In particular, suppose the trusted-application ACL explicitly contains my non-Apple helper, while the partition list contains only apple:. Is the helper expected to be denied because it does not satisfy the partition condition, despite being explicitly trusted by the ACL? If so, is there a supported partition configuration for a key that must be usable by both a specifically trusted non-Apple helper and Apple signing tools such as codesign / productbuild, without broadening access to an application class? I’m specifically looking for the supported contract here. A successful experiment would be useful qualification evidence later, but I don’t want to use that experiment to infer undocumented authorization semantics. Thanks.
Replies
2
Boosts
0
Views
959
Activity
Sep ’26
macOS Tahoe appears to ignore /etc/fstab ro and noauto — findings and workaround
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.
Replies
1
Boosts
0
Views
541
Activity
Sep ’26
Notice of Terminal shell change to zsh appeared on OS26.6.2 Suspicious?
Hi, I understand that users of mac OS 10 were notified that the Terminal default-shell had changed from Bash to zsh. I have not seen that message since. However, my current MacBookPro running OS26.6.2 has just popped up that old message: Last login: Tue Sep 15 17:42:23 on ttys000 The default interactive shell is now zsh. To update your account to use zsh, please run chsh -s /bin/zsh. For more details, please visit https://support.apple.com/kb/HT208050. MacBook-Pro:~ [My Name$] After all this time, should I be suspicious?
Replies
0
Boosts
0
Views
164
Activity
Sep ’26
Spotlight Shows "Helper Apps" That Are Inside Main App Bundle That Are Not Intended to Be Launched By The User
I have Mac apps that embed “Helper Apps” inside their main bundle. The helper apps do work on behalf of the main application. The helper app doesn’t show a dock icon, it does show minimal UI like an open panel in certain situations (part of NSService implementation). And it does make use of the NSApplication lifecycle and auto quits after it completes all work. Currently the helper app is inside the main app bundle at: /Contents/Applications/HelperApp.app Prior to Tahoe these were never displayed to user in LaunchPad but now the Spotlight based AppLauncher displays them. What’s the recommended way to get these out of the Spotlight App list on macOS Tahoe? Thanks in advance.
Replies
8
Boosts
0
Views
1.1k
Activity
Sep ’26
iMac gpuRestart and then crash
Hi all, This has been bothering me for quite a while. Basically my new iMac (bought for a few months only) started to crash randomly. I went to the genius bar and they couldn't do anything to identify the issue, I tried reinstalling the OS and even reinstalling an older version of Mac OS as well, but still seeing this issue. Today it happened twice and below are the details: Mac specs: Model Name: iMac  Model Identifier: iMac20,1  Processor Name: 10-Core Intel Core i9  Processor Speed: 3.6 GHz  Number of Processors: 1  Total Number of Cores: 10  L2 Cache (per Core): 256 KB  L3 Cache: 20 MB  Hyper-Threading Technology: Enabled  Memory: 16 GB  Boot ROM Version: 1554.100.64.0.0 (iBridge: 18.16.14556.0.0,0)  Serial Number (system): xxx  Hardware UUID: xxx  Activation Lock Status: Enabled The DiagnosticReports around the time it crashed has a lot of files with .gpuRestart, e.g.: Kernel_2021-04-27-213412_Zhuzengs-iMac.gpuRestart and file WindowServer_2021-04-27-213319_Zhuzengs-iMac.userspace_watchdog_timeout.spin in between. The details of the the first gpuRestart file Tue Apr 27 21:32:13 2021 Event: GPU Reset Date/Time: Tue Apr 27 21:32:13 2021 Application: Path: Tailspin: /Library/Logs/DiagnosticReports/gpuRestart2021-04-27-213213.tailspin GPUSubmission Trace ID: 0 OS Version: Mac OS X Version 10.15.7 (Build 19H1030) Graphics Hardware: AMD Radeon Pro 5300 Signature: 2 Report Data: GPU Log Version: 1 Restart Channel: 18 VMPT --THE STATE OF THE DRIVER AMDRadeonX6000_AMDNavi14GraphicsAccelerator state: ENABLED PCIe Device: [3:0:0], DID=0x7340, RID=0x47, SSID=0x219 TotalVideoRAMBytes: 0x00000000ff000000 (4278190080) Uptime 21:50:05.077572 [00] Channel: GFX, last reset at 0:00:00.000000 CompletedTS = 0x005be078, SubmittedTS = 0x005be079 SentTS = 0x005be078, sent at 21:49:00.896511, ScheduledTS = 0x005be079, submitted at 21:50:03.672539 Wait for Channel 18, TS 0xef924 PendingEvent: YES NumberOfPendingCB = 1, FirstPendingTS = 0x005be079, LastPendingTS = 0x005be079 FirstPendingCB: ProcessID = 225, ProcessName = WindowServer, SubmitContext = Unknown (0) GPUAddress = 0x0000000431cef000, Size = 0x000001d3, VMID = 2 ContentValidation = PASS Buffer range 0x0 .. 0x100:c0012800 80000000 80000000 c0026900 00000081 80000000 40004000 c0026900 By searching online this seems to be happening to others as well but I failed to find a common fix for this. Any help would be hugely appreciated!!!
Replies
3
Boosts
1
Views
1.9k
Activity
Sep ’26
Title bar double-click / Fill on macOS 27
I’m seeing a reproducible title-bar interaction issue on macOS 27 RC (26A428). This issue has been present since at least macOS 27 build 26A5416b (Developer Beta 6 / Public Beta 4) and is still reproducible on the Release Candidate, build 26A428. My System Settings → Desktop & Dock → Window title bar double-click action is configured to Fill. In several system apps with sidebars, including: Finder System Settings Reminders Feedback Assistant the right side of the title bar shows a visible rectangular region when the pointer hovers over it. The more important problem is that the middle portion of this region appears to intercept the title-bar double-click. Double-clicking there does nothing, while double-clicking very close to the top or bottom edge of the same region correctly triggers Fill. This makes the normal title-bar gesture surprisingly difficult to use because the center of the title bar is naturally where I would double-click. Interestingly, the sidebar area does not have this problem: double-clicking the top, middle, or bottom portions of the sidebar title-bar area all works normally. Feedback Assistant makes the behavior particularly easy to see because its left sidebar and rightmost pane behave normally, while the title-bar region above the middle pane exhibits the problem. Steps to reproduce: Set “Double-click a window’s title bar” to Fill in Desktop & Dock settings. Open Finder, System Settings, Reminders, or Feedback Assistant. Move the pointer over the right/content portion of the title bar until the rectangular hover region appears. Double-click around the center of that region. The Fill action does not occur. Double-click very close to the upper or lower edge of the same region. Fill works normally. I have reproduced this on macOS 27 RC build 26A428, including: a newly created macOS user account Safe Mode so it does not appear to be caused by migrated preferences, caches, login items, or third-party software. A screen recording demonstrating the exact hit-testing behavior was submitted through Feedback Assistant. Feedback: FB24462749 Is anyone else able to reproduce this? It looks as though some view or overlay in the new title-bar/toolbar area may be intercepting mouse events.
Replies
1
Boosts
0
Views
545
Activity
Sep ’26
SMAppService LaunchDaemon: is privilege drop followed by same-PID exec supported before Mach service check-in?
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.
Replies
4
Boosts
0
Views
688
Activity
Sep ’26
Macbook M5 Development Kernel Panic
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.
Replies
1
Boosts
1
Views
1.2k
Activity
Sep ’26
Is it a known issue that Xcode static analyzer hallucinates past results?
[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.
Replies
1
Boosts
0
Views
769
Activity
Sep ’26
Does SecItemDelete guarantee immediate invalidation of an already-retained Secure Enclave SecKeyRef on macOS?
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.
Replies
1
Boosts
0
Views
733
Activity
Aug ’26
DisableGuestAccount can be overridden by Admin on macOS 26
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
Replies
0
Boosts
0
Views
1.5k
Activity
Aug ’26
ControlCenter blocks a MenuBarExtra item due to foreign trackedApplications entry
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
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
3
Boosts
0
Views
1.3k
Activity
Aug ’26
Xcode 26 on macOS 26 with a Dark theme in Light Mode
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).
Replies
1
Boosts
0
Views
652
Activity
Aug ’26
macOS Golden Gate Beta battery percentage appearance
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.
Replies
0
Boosts
0
Views
515
Activity
Aug ’26
Is there a supported public API to create a macOS desktop display?
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.
Replies
1
Boosts
0
Views
569
Activity
Aug ’26
Command-line tool for .ips files?
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?
Replies
11
Boosts
1
Views
8.3k
Activity
Aug ’26
Supported public API to prebind a macOS process occurrence and match a later XPC or Mach sender
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.
Replies
2
Boosts
0
Views
1.2k
Activity
Aug ’26
How can a local AI agent use MLX/Metal unattended on macOS while remaining confined to an authorized workspace?
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.
Replies
0
Boosts
0
Views
876
Activity
Aug ’26
pkgbuild giving signing identity error
The actual error: pkgbuild: error: Could not find appropriate signing identity for “Developer ID installer: My Name (DeveloperID)”. I'm trying to sign a program written with gfortran. The steps worked the last time (Mar 23) I built this code. The steps to error: a) xcrun notarytool store-credentials --apple-id "xxx" --team-id "yyy" Giving Profile Name zzz and App-specific password b) codesign --force --timestamp --options=runtime -s "Developer ID Application: My Name (yyy)" AppName c) pkgbuild --root ROOT --identifier org.aaa.bbb --version "1.1.1" --sign "Developer ID installer: My Name (yyy)" AppName.pkg ROOT contains the package contents At this point I get the error pkgbuild: error: Could not find appropriate signing identity for “Developer ID installer: My Name (yyy)” Are there steps that have changed. Any suggestions? Thanks, David
Topic: Code Signing SubTopic: General Tags:
Replies
3
Boosts
0
Views
2.2k
Activity
Aug ’26