Hi Kevin, Apologies for the long silence — wanted to actually have the 26.6 data before replying rather than guess. Direct answer to your question: yes, still reproducible on 26.6, so r.178808025 does not appear to be the fix. Three confirmed deny(1) clusters since upgrading past 26.5.2, each with a fresh sysdiagnose captured automatically at the time: 2026-08-12, 09:54 local — macOS 26.6.1 (25G76) 2026-08-13, 09:59 local — macOS 26.6.1 (25G76) 2026-09-06, 10:19 local — macOS 26.6.2 (25G83), currently installed build I've attached the 09-06 sysdiagnose directly to FB23576006 in Feedback Assistant (not here in the forum) — it's the most recent capture and matches the currently installed build. Happy to add the two 26.6.1 captures there too if useful. One more data point that may be useful: the overall frequency has dropped a lot since late July (from roughly 1-2 clusters/day down to about 1 every 9 days), but the cause is unclear to me — no code or config change I can point to lines up cleanly with the drop. The most recent occurrence (09-06) happened on my home network, not while traveling, so it's not simply a "stable network = never happens" situation — just rarer. I also want to flag how much this has affected day-to-day work, beyond the automated probe data: I've had to route a large and growing share of file operations against the NFS-mounted machine through SSH instead of the mount itself, because the mount intermittently returns EPERM on ordinary reads (same deny(1) signature) mid-session. At this point most of my regular workflows against that machine — including routine service restarts — go through SSH rather than relying on the mount being usable. It's become a very frequent, everyday workaround, not just something that shows up in occasional test clusters. Thanks again for staying with this.

Quick update while this is still fresh. The launcher-app fix has continued to hold for the FDA-attribution side — no regressions there — but as expected, the underlying intermittent kernel Sandbox deny(1) is still occurring, same as every prior cluster in this thread. Concrete data point: this morning (2026-08-08, ~05:11 and again ~09:35 local), the same signature recurred — mount listed the NFS volume as connected, but ls/touch returned "Operation not permitted." Confirmed in the kernel log: kernel: (Sandbox) System Policy: mount_nfs(60197) deny(1) file-mount /Users/Shared/Stefan-Hem This was a Terminal-launched process, FDA granted throughout (as established since 2026-07-14), so — consistent with everything so far — not an attribution issue on my end. Manual remount cleared it, same as every prior occurrence. One new piece of evidence since my last note: I extended the sentinel probe to test three call variants against the same path in parallel — a raw POSIX read, a plain open -g, and a Finder "reveal" (open -g -R, routed through LaunchServices). This morning's result at the mount root: raw=ok open=ok reveal=DENIED (open -g -R /Users/Shared/Stefan-Hem/...) So a plain read and a plain open both succeeded while the LaunchServices-mediated reveal call was denied at the same moment. If useful, this might narrow down which API layer the Sandbox check is actually evaluating against — worth comparing policy evaluation between a raw open(2) and a LaunchServices-mediated call, if that's visible on your side. Also have a fresh sysdiagnose captured automatically at the exact moment of this morning's first deny (05:11) — happy to upload it if still useful; my last submitted one was from mid-July. One loosely-held hypothesis, not confirmed: this morning's failure landed within the same second as a system "Maintenance Wake" cycle (mDNSResponder background network housekeeping — happens even with Power Nap off). Not enough samples to call it a real correlation yet, but if you have visibility into how often Sandbox network-volume policy gets re-evaluated around dark-wake cycles, that might be worth a look. To be clear on scope again: FDA-attribution stays fixed, this is purely the original kernel-level deny(1) — still unresolved five weeks in, still recurring roughly daily, still self-clearing via manual remount every time.

Thanks, Kevin — good to have that confirmed, and appreciate the extra context on why the bundled-app path is the right default (broadest toolbox, most-tested code path) rather than a point fix for this one symptom specifically. One honest update while I have you: the launcher-app change has fully solved the FDA-attribution problem for the watchdog daemon itself (no more "GUI says granted, daemon's own canary says no"), but it hasn't touched the original, broader issue this thread is about. The intermittent kernel Sandbox/System Policy deny(1) on the NFS mount is still occurring independent of that fix. Concrete data point: this morning (2026-08-04, ~09:21 local), a Terminal-launched process hit the same signature we've seen throughout this thread — mount still listed the NFS volume as connected, but ls returned "Operation not permitted." Terminal has had Full Disk Access granted since 2026-07-14 (well before the launcher-app change), so this wasn't an FDA-attribution issue — it's the same stale-mount/deny(1) behavior as the earlier clusters. Manual remount (unmount + retry) cleared it, same as every prior occurrence. So to be precise about scope: the bundled-app fix resolved the specific problem it targeted (stable FDA grant for a launchd-spawned binary), but the underlying intermittent kernel-level denial that FB23576006 is about remains unresolved a month in, across processes that already have FDA. Wanted to flag that clearly rather than let the good news on the launcher-app side read as if the whole thread is closed.

---Update: it's been 12 days since we deployed the launcher-app approach (bundled Swift app running the Python job via NSTask, granted FDA on 2026-07-22) and the result looks very promising: Before the change: recurring deny(1) file-mount clusters roughly every 1-3 days (confirmed via automatic sysdiagnose captures tied directly to the denial signature), most recently 2026-07-22 16:24 — about an hour before the launcher app went live. Since 2026-07-22 17:38: zero deny(1) file-mount events in the system log, and zero new sysdiagnose captures, despite the same machine/network having plenty of ordinary flakiness (SSH timeouts, stale mounts) in that window — so the monitoring is definitely still exercising the failure paths, it's just not hitting the sandbox denial anymore. This is by far the longest clean streak we've seen in this whole investigation (the path-scope and plain-FDA hypotheses both fell apart within days of testing). Your diagnosis — that bare binaries never get a stable FDA/TCC grant in a launchd context, and wrapping the job in a proper .app bundle fixes that — looks correct. Will keep watching and report back if anything regresses, but wanted to confirm this as soon as it crossed a meaningful threshold. Thanks for sticking with this.

Hi Kevin, FDA update: enabled it via System Settings on 2026-07-14 for both /usr/bin/python3 (the exact binary launchd runs the monitoring daemon with) and Terminal — confirmed blue/on for both. Two days later, three real deny(1) clusters hit on 2026-07-16 (20:58, 21:03, 21:09 local). My daemon tags every denial event with a live FDA check (opens its own ~/Library/.../TCC.db as the test) run from inside the actual long-running check, not an ad-hoc shell test: All three clusters logged FDA: no Access was denied identically to before: mount_nfs / ls / diskutil all still hit "Operation not permitted" on the same paths One thing that rules out the obvious "stale process" explanation: the daemon has no KeepAlive, so launchd spawns a completely fresh python3 process every 30s — there's no long-lived process that could be missing a refreshed grant. So it looks like (1) FDA doesn't fix the underlying denial, and (2) the daemon isn't actually getting FDA despite the GUI showing it granted for that exact binary — which is itself odd and maybe worth its own look. I don't have a way to independently query the system TCC database to confirm the grant landed there (would need sudo I don't have queued up), but the daemon's own runtime check is consistently "no" across three separate live incidents.

Kevin, Thanks for the clarification on open vs. NSWorkspace.activateFileViewerSelectingURLs / "Show in Finder" — that's a useful distinction I hadn't considered (preflighting + the event-emission restrictions). I've already added a "reveal" probe alongside the existing raw-read and open -g probes, using open -g -R , which goes through the same Finder-reveal service you described rather than opening the file's content. It's wired into the same sentinel locations and fires on the next confirmed deny(1) cluster. One cluster hit today right after I deployed it, but the timing meant the new probe only got a clean result on the control location outside any mount (not denied, as expected) — no denial data on the mount points themselves yet. I'll follow up with real numbers once a few more clusters accumulate, same as the raw/open() data I posted last time. To answer your question directly — what do we actually need to work: the process driving most of this is a background daemon (launchd, no interactive session, no Terminal window) that needs continuous, unattended read/write access — checking git status, writing health-check/log data — across several independent project directories on these mounts. There's no Finder interaction anywhere in that path; a human isn't browsing these files. So if your intuition is right that Finder-mediated access survives while programmatic/background access is what's actually broken, that's consistent with what we're seeing (the deny(1) hits are on ls, perl, diskutil, mount_nfs, and our own Python daemon — never anything Finder-initiated). It would also mean the "Show in Finder" test is useful for confirming the diagnosis, but doesn't by itself point to a usable workaround for this specific use case. That leads to a question about the File Access Temporary Exceptions suggestion: those are App Sandbox entitlements, which apply to code-signed apps that have opted into App Sandbox. The processes actually hitting this (the launchd daemon, shell scripts, Terminal-invoked tools) aren't sandboxed apps at all — they're plain CLI processes. Is the temporary-exception entitlement applicable outside of App Sandbox in any form, or is there a different mechanism (e.g. something at the launchd/daemon level, or a signed helper tool) that would be the right analog for a non-sandboxed background process needing the same kind of "hard-coded" path exception? Will report back with the reveal-probe numbers as soon as the next cluster gives us real data.

Hi Kevin, Following up with the actual sentinel/isolation data, as promised. Since the extended probe went live (2026-07-08), it has fired 7 times (2026-07-11 10:23 / 10:44, 2026-07-12 07:55 / 08:15 / 08:42 / 08:53 / 09:27), each time a deny(1) cluster was detected. Raw open() results per location: outside_shared (/Users/Shared/testfile.txt) — sibling of the mount, not itself a mount point — denied 0/7 home_baseline (~/watchdog_sentinel.txt) — plain local file, sanity control — denied 0/7 stefan_hem_root (/Users/Shared/Stefan-Hem/...) — production NFS mount root — denied 4/7 stefan_hem_subdir (/Users/Shared/Stefan-Hem/TestFolder/...) — one level deeper in the same mount — denied 4/7 test_pi_root (~/nfs-scope-test/raspberrypi/...) — control NFS mount to a second server, deliberately placed OUTSIDE /Users/Shared/ — denied 7/7 The control mount I set up specifically to test your workaround suggestion (relocate outside /Users/Shared/) was denied more consistently than the production mount that's actually under /Users/Shared/ — 7/7 vs 4/7. Both mounts sit on completely independent servers/hardware, so this isn't a server-side coincidence. Based on this, moving the mount point doesn't look like it would resolve the issue for us; the denial doesn't appear to be scoped to the /Users/Shared/ path specifically, more generally to NFS mount points regardless of where they're rooted in the filesystem. One more wrinkle worth flagging: for test_pi_root, the two probe methods disagreed at least once — at 2026-07-11 10:23, the raw open() call was denied but the open -g (LaunchServices) call succeeded. In every later occurrence both methods were denied together. Not sure if that's meaningful or just a timing artifact of the probe (1.5s between the two calls), but flagging it in case it's useful. Happy to keep running this and report a larger sample if it's helpful — the probe is unattended and only fires on an actual cluster (5 min cooldown), so it costs nothing to leave running.

Kevin — really appreciate the time you're putting into this, especially the level of detail (the "process vs. session" distinction on open in particular was something I hadn't considered). Thank you. Re: the umount(28561) deny(1) file-unmount line — yes, that's my own remediation script, and it explains the diskutil(28562) call too, not a separate observation. My watchdog's health check failed for the mount, which triggers a recovery script. That script does (paraphrased): if is_mounted && !is_fs_ok: /sbin/umount -f "$VOLUME" || /usr/sbin/diskutil unmount force "$VOLUME" So the sequence is: umount -f (PID 28561) — denied (file-unmount) because that command failed, the || fallback on the same line fires: diskutil unmount force (PID 28562) — also denied (file-read-data), which is what produced the StorageKit errno=1 log line 16 microseconds later. So the diskutil call isn't a separate/independent data point — it's literally the next step on the same script line, triggered because the first command was denied. The whole chain (umount attempt → diskutil fallback → StorageKit error log) is one causal sequence, every step blocked by what looks like the same path-scoped policy decision. Combined with the earlier finding (ls, perl, python3, mount_nfs all denied identically in the same ~7s window), that's now 8 different binaries — including my own recovery tooling trying to clean up a broken mount — all blocked on the same path. Nothing on that list is privileged or unusual; it's plain user-owned processes doing ordinary I/O under /Users/Shared/Stefan-Hem. Good call on being skeptical of "clean" network logs — noted, I won't lean on absence-of-magicsock-lines as proof nothing happened on the network going forward. On the isolation test: I've already extended it along the lines you suggested, before writing this reply. In addition to the parallel mount outside /Users/Shared/ that was already running, I now have: sentinel files at 5 points: outside /Users/Shared entirely, at /Users/Shared/ itself, at the mount root, one folder deeper, and on the outside-mount control path each one probed two ways: a raw open() from my own watching process, and open -g (LaunchServices, backgrounded so it doesn't steal focus) per your suggestion — so I can tell "my process got denied" from "the system-mediated open path got denied" too both probes spaced ~1.5s apart per file, so the timeline in the log stays unambiguous instead of a burst It only fires when a live deny(1) cluster is actually detected (not every cycle), so I'm not hammering the system — but it's live now, so the next cluster will produce real counts instead of a guess. One known wrinkle: I haven't found a clean way to auto-dismiss the TextEdit windows the open probe spawns (tried a few AppleScript approaches, no luck yet) — for now they just pile up one at a time and I close them by hand, exactly the annoyance you flagged. Will report back with actual data once the next cluster hits.

Found it — and it's more than a timestamp coincidence. I extracted system_logs.logarchive from the sysdiagnose I already had (2026-07-05, attached to FB23576006) and searched for the StorageKit/SKManager signature around that timestamp. Your log line is there exactly as shown (10:52:14.292554+0200, PID 28562). But the line immediately preceding it, 16 microseconds earlier, same PID, is this: 10:52:14.292538 kernel: (Sandbox) System Policy: diskutil(28562) deny(1) file-read-data /Users/Shared/Stefan-Hem 10:52:14.292554 diskutil: (StorageKit) [SKManager _diskForPath:isNetworkMount:]: open() failed: errno=1 Same process, same microsecond, errno=1 = EPERM. This isn't a separate bug that r.171126338 introduced — it's diskutil's own StorageKit code logging the exact kernel Sandbox denial I've been reporting, at the moment diskutil itself got caught in a deny(1) window. So r.171126338 (whatever it changed) likely just added visibility into an open() call that was already going to fail — it didn't cause the failure. For context, here's the full sequence from that same ~7-second window, all against /Users/Shared/Stefan-Hem, all denied identically: 10:52:11.066 Python(28544) deny(1) file-read-data (my own watchdog script) 10:52:11.094 ls(28547) deny(1) file-read-data 10:52:13.109 ls(28548) deny(1) file-read-data 10:52:14.254 perl(28557) deny(1) file-read-data 10:52:14.263 perl(28560) deny(1) file-read-data 10:52:14.268 umount(28561) deny(1) file-unmount 10:52:14.292 diskutil(28562) deny(1) file-read-data ← your StorageKit line follows immediately 10:52:18.007 mount_nfs(28569) deny(1) file-mount Six unrelated processes/binaries denied within 7 seconds, all on the same path, all with identical Sandbox System Policy signature. That's what convinced me this is path-scoped rather than mount_nfs- or process-specific — diskutil is just one more victim in the list, not a separate codepath. If it's useful, I have the same signature repeating across ~9 sysdiagnose captures now (2026-07-05 through 2026-07-07) if you want more samples to compare PIDs/timing against your side of r.171126338. Re: the workaround test — running now. I've mounted the same RaspberryPi NFS export in parallel at a second location outside /Users/Shared/ (my home directory), alongside the untouched production mount, and I'm logging deny(1) hits separately for each over the next week. Will report back with actual counts rather than a guess.

Thanks for looking into this. Re: timing — I can't give you a clean before/after-26.5 comparison. This specific NFS mount setup only went live on 2026-07-03, and I was already on 26.5.1/26.5.2 (25F84) at that point — so I have no data on this exact mount configuration under an earlier OS version. I did run a different mount method (SSHFS/macFUSE) at the same path before that, on earlier OS builds, but it failed differently (kext/Gatekeeper corruption), not with this deny(1) signature — so I can't say this is a regression tied to a specific OS version, only that it's new since I switched mount methods. Re: the StorageKit/r.171126338 log line — the timestamp you posted (2026-07-05 10:52:14+0200) lands within seconds of a deny(1) cluster I already captured a full sysdiagnose for (10:52:11–10:52:54, attached to FB23576006). I'll dig through that archive specifically for the StorageKit/SKManager entries around r.171126338 and report back what I find. Re: the workaround — good lead, and it lines up with something I found independently: during that same cluster, two completely independent NFS mounts under /Users/Shared/ (different remote hosts, different networks) were denied simultaneously with an identical signature, and the denial hit every process touching that path (ls, diskutil, umount, python3), not just mount_nfs. That's consistent with /Users/Shared/ itself being the scoped resource rather than something specific to NFS. I'll relocate one of the two mounts outside /Users/Shared/ (e.g. into my home directory) and watch whether it stops seeing deny(1) while the other one (still under /Users/Shared/) keeps failing — that would be a strong isolation test. Will report results either way. One thing that would help: is there any more context you can share on what r.171126338 actually changed? Knowing whether it touches StorageKit/diskarbitrationd's interaction with mount_nfs specifically vs. something in the Sandbox layer generally would help me target the sysdiagnose search.

Bug number: FB23576006 Happy to attach additional sysdiagnose captures if useful — I have an automated watchdog that grabs one live whenever the deny(1) pattern recurs.