macOS 26 (Tahoe): updates fail with EPERM "Failed to create installation cache directory" (app-bound provenance on ~/Library/Caches/<bundle-id>/)

[bazl-E]

Summary

On macOS 26 (Tahoe), Sparkle's Autoupdate helper fails to install downloaded
updates for non‑sandboxed, Developer‑ID signed host apps. The helper aborts
with:

SUSparkleErrorDomain Code=10 (SPUInstallerError)
"Failed to create installation cache directory in
 /Users/<user>/Library/Caches/<bundle-id>/org.sparkle-project.Sparkle/Installation"

Reproduced on Sparkle 2.9.2 (current release) and on 2.9.1. The
underlying syscall is mkdtemp(3) returning EPERM even though the
parent directory exists, is owned by the user, and is mode 0700. The cause
appears to be Tahoe's expanded app‑bound data protection (the
com.apple.provenance xattr) on ~/Library/Caches/<bundle-id>/, which gates
writes by a process whose code identity differs from the directory's
"owning" app — and Autoupdate has a different cdhash than the host.

A workaround that stages the installer under the per‑user Darwin temp dir
($TMPDIR) instead of ~/Library/Caches/<bundle-id>/ fixes it; verified
on‑device. Filing now to confirm reproduction and discuss the fix shape
before opening a PR.

---

1. Environment

Item	Value
OS	macOS 26.4.1 (build 25E253)
Arch	arm64 (Apple Silicon)
Sparkle	2.9.2 (also reproduced on 2.9.1)
Distribution	SPM, resolved to 2.9.2 (xcframework binaryTarget)
Host app	Non‑sandboxed, Hardened Runtime, Developer ID signed, LSUIElement = true
Signing identity	Developer ID Application: <redacted> (TEAMID)
Update flow	Standard Sparkle: in‑app check → download → Autoupdate extracts → relaunch

Sandboxed apps were not tested; the report scope is non‑sandboxed
Developer‑ID hosts.

---

2. Reproduction

1. Build and ship a non‑sandboxed, Developer‑ID, Hardened‑Runtime app that
   embeds Sparkle 2.9.2 via SPM (xcframework).
2. Install it on macOS 26 (Tahoe).
3. Publish a newer version in the appcast.
4. Launch the app, invoke "Check for Updates", accept the update.
5. The download succeeds. The install step fails with Code=10 SPUInstallerError. The user sees the standard error alert; the app does
   not relaunch.

This is reproducible on first‑install, and recurs after clearing
~/Library/Caches/<bundle-id>/ between attempts.

---

3. Symptom — observed logs

Clean, uninstrumented build (stock Sparkle 2.9.2):

E  Autoupdate[xxxxx] [org.sparkle-project.Sparkle:Sparkle] Error: Error:
   Failed to create installation cache directory in
   /Users/<user>/Library/Caches/<bundle-id>/org.sparkle-project.Sparkle/Installation
   (null) (URL (null))

E  <HostApp>[xxxxx]  [org.sparkle-project.Sparkle:Sparkle] Error: Error:
   Failed to create installation cache directory in
   /Users/<user>/Library/Caches/<bundle-id>/org.sparkle-project.Sparkle/Installation
   (null) (URL (null))

The same error is logged twice: once by the Autoupdate helper that fails,
once relayed back to the host process.

The error originates in Autoupdate/AppInstaller.m when
+[SPULocalCacheDirectory createUniqueDirectoryInDirectory:] returns nil.

Underlying syscall

With a locally instrumented Sparkle build (added SULog around mkdir(2) /
mkdtemp(3) inside SPULocalCacheDirectory), the failing call is:

mkdtemp(".../org.sparkle-project.Sparkle/Installation/XXXXXXXXX")
    -> errno = 1 (EPERM, "Operation not permitted")

Key detail: the parent directory …/org.sparkle-project.Sparkle/Installation
exists, is owned by the same uid (501), and has POSIX mode 0700.
POSIX permits the write. EPERM is being returned by something other than
POSIX — see §4.

---

4. What we measured

Fact	Evidence
The com.apple.provenance xattr is present on every level of ~/Library/Caches/<bundle-id>/… (host‑app container, org.sparkle-project.Sparkle/ subdir, Installation/ subdir).	xattr -l <path> shows com.apple.provenance at each level.
The xattr value is identical at every level (same hex), even though Installation/ is created by a different process (Autoupdate) than its parents (host app).	xattr -px com.apple.provenance <path> returns the same hex at all three levels.
The xattr is immutable from userspace: xattr -d com.apple.provenance <dir> is silently rejected.	Reproduced repeatedly.
The two writers have different code identities (different cdhashes), even after the helper is re‑signed with a host‑prefixed identifier (com.<bundle-id>.Sparkle.Autoupdate).	codesign -dvvv on both binaries.
POSIX ownership/permissions are correct (uid 501, mode 0700); the write is denied despite POSIX allowing it.	Instrumented mkdtemp(3) returns errno=1 (EPERM).
The failure is per‑parent‑directory and intermittent: in one captured run the host‑app‑created Launcher/ subtree succeeded in the same process where the Autoupdate‑created Installation/ subtree failed; minutes later, after the cache was cleared and recreated, the same Installation/ path succeeded.	Two log windows from the same machine, ~6 minutes apart.

---

5. Why this hits Sparkle specifically

Sparkle ships two separately code‑signed executables that share a uid
but differ in cdhash:

1. The host app — runs in‑process Sparkle (the framework).
2. The Autoupdate / installer helper — a distinct Mach‑O with its own
   signature (and, in our case, a host‑prefixed identifier
   com.<bundle-id>.Sparkle.Autoupdate).

Stock Sparkle stages everything under one shared tree:

~/Library/Caches/<bundle-id>/org.sparkle-project.Sparkle/
    ├── PersistentDownloads/   ← created by the HOST APP
    ├── Launcher/              ← created by the HOST APP
    └── Installation/          ← created by AUTOUPDATE   ← FAILS (EPERM)

Sequence:

1. The host app creates …/org.sparkle-project.Sparkle/ (and
   PersistentDownloads/, Launcher/). The kernel stamps that subtree with
   the host app's provenance.
2. Autoupdate (different cdhash) then tries to create
   …/org.sparkle-project.Sparkle/Installation. Because the parent is
   provenance‑bound to the host app, Autoupdate gets EPERM.

The failure is therefore per‑parent‑directory: a differently‑signed
helper cannot create a child inside any directory created by the host
app's identity, regardless of POSIX permissions.

---

6. Why $TMPDIR works (workaround)

confstr(_CS_DARWIN_USER_TEMP_DIR, …) returns the per‑user Darwin temp
directory ($TMPDIR), e.g.:

/var/folders/<xx>/<yy>/T/

This directory is:

• Created and owned by launchd (not by any app) → it is not
  stamped with any app's provenance.
• mode 0700, owned by the user → user‑private.
• Shared by all of that user's processes regardless of cdhash → both
  the host app and Autoupdate can create their own subtrees in it.

After patching Autoupdate/AppInstaller.m (via a wrapper in
SPULocalCacheDirectory) to put the installer staging root under
$TMPDIR/<bundle-id>.org.sparkle-project.Sparkle.Installation/… instead of
under ~/Library/Caches/<bundle-id>/…/Installation, the install step
completes and the relaunch succeeds. Verified on macOS 26.4.1.

/private/tmp is also exempt (it's mode 1777, system‑owned), so it
works as a workaround too — but it's world‑writable, so it is not an
appropriate staging location for a signed bundle. $TMPDIR is the
security‑correct choice.

---

7. What we tried before patching Sparkle

These did not fix it on macOS 26:

• Re‑signing Autoupdate with a host‑prefixed identifier
  (com.<bundle-id>.Sparkle.Autoupdate). The cdhash of the host and the
  helper still differ, and the EPERM still occurs.
• Removing the sandboxed Downloader.xpc / Installer.xpc from the
  embedded Sparkle.framework for our non‑sandboxed host (per
  Sparkle's sandboxing docs).
  This is independently required for non‑sandboxed hosts but does not
  address the EPERM.
• Pre‑creating ~/Library/Caches/<bundle-id>/org.sparkle-project.Sparkle/Installation
  from the host app at launch (so it exists with the host's provenance
  before Autoupdate runs). Autoupdate still gets EPERM when it tries
  to mkdtemp inside that pre‑created directory.
• Clearing ~/Library/Caches/<bundle-id>/ between attempts. The failure
  recurs on the next attempt because the host app recreates the parent
  subtree first.

---

8. What we cannot prove from outside

• The exact rule the kernel uses to authorize a cross‑identity write into a
  provenance‑stamped directory. The fact that the xattr value is identical
  at every level (rather than per‑creator) suggests the value is associated
  with the app data container (bundle id), not stamped per creating
  process. The precise authorization predicate (team id, designated
  requirement, MACL, sandbox container ID, or a combination) is not publicly
  documented.
• Whether this is an intentional Tahoe hardening or a regression. There is
  no Apple statement either way; we are filing in parallel via Feedback
  Assistant.

There is no Apple developer documentation of com.apple.provenance
semantics that we are aware of. The most thorough public writing is Howard
Oakley's Eclectic Light Co. series (2023–2025), which is explicitly
reverse‑engineered observation, not Apple specification.

---

9. Ask

1. Can anyone with a macOS 26 machine and a non‑sandboxed Developer‑ID
   Sparkle host reproduce the install failure with stock 2.9.2? (We've
   reproduced on one machine; broader confirmation would help.)
2. Would the maintainers be open to a PR that relocates only the
   installer's staging root (rootCacheInstallationPath in
   Autoupdate/AppInstaller.m) to a top‑level entry under $TMPDIR, with a
   graceful fallback to the legacy ~/Library/Caches/…/Installation path
   for pre‑Tahoe / unusual environments? The host‑app paths
   (PersistentDownloads/, Launcher/) would be left untouched so the
   download‑cache behavior across launches does not change.
3. Alternatively, would a guarded fallback inside
   +[SPULocalCacheDirectory createUniqueDirectoryInDirectory:] (retry
   under $TMPDIR on EPERM) be preferred so the canonical
   ~/Library/Caches path is always attempted first?

Happy to implement whichever shape is preferred and open a PR against the
2.x branch.

---

10. Repro artifacts available on request

• Failure logs from stock 2.9.2 and 2.9.1 builds.
• Success log from the patched build (instrumented; [diag] prefixed lines
  are from local SULog instrumentation added to SPULocalCacheDirectory,
  not stock Sparkle).
• xattr -l / xattr -px com.apple.provenance dumps for the three
  directory levels.
• codesign -dvvv for host and Autoupdate binaries (with cdhash).

[zorgiepoo]

I am skeptical about this report for a number of reasons. Sparkle is widely used in "non‑sandboxed, Developer‑ID, Hardened‑Runtime apps" in Tahoe. We have no other reports of this, and this related code in Sparkle has not changed in a long time, so the reproducible steps (re: section 2) are not convincing or lacking in detail. I suspect this is a specific one-off/edge case if you are running into this kind of error. Your report implies Autoupdate succeeds in creating Installation intermediate directory but fails creating a subdirectory in there using mkdtemp().

Further, directories in ~/Library/Caches/ are not specifically really protected; they're not like sandbox containers. Even further, intentional code signing protections usually have a same team-ID policy or something logical to handle different processes or development/production certificates from same app developer. Lastly, using AI to generate this report makes this less believable (if you have).

[fbarbat]

I just hit this error today while doing an update. The update didn't work in that run but it did work in subsequent runs. I also could see a macOS notification saying ""App" was prevented from modifying apps on your Mac." I'm investigating and trying to reproduce the issue.

[zorgiepoo]

If you get that notification, the app probably has an entry in System Settings > Privacy & Security > App Management. To reproduce the state you were at before you may want to remove the app in that table and relaunch it.

The last issue related to that we had was in #2591
If your app has a custom NSUpdateSecurityPolicy set for other App Store fronts, I highly suggest not overriding that for Sparkle builds (the default implicit policy is a same team ID policy). Even still, Sparkle tries to make this warning not surface and in some cases the update doesn't fail to install even if it does trigger. Also, this app modification prevention prompt is for protecting against modifying apps (specifically apps that have been notarized and scanned by Gatekeeper), not against modifying directories outside of app bundles.

More info would be helpful like attaching logs and OS system version, unless you can get a very specific repro.

[zorgiepoo]

Can you or @bazl-E hint at what your bundle ID is in any way, specifically the last component of it?

[fbarbat]

Thanks! A few answers and a fuller trace.

• No NSUpdateSecurityPolicy anywhere in our Info.plist or code, so we are on the default implicit same team ID policy.
• Non-sandboxed, Developer ID, hardened runtime, notarized and stapled.
• macOS 26.x mostly, also seen on 14 and 15. The failing step is in macOS's Gatekeeper scan rather than in Sparkle's own code (and the original report here was on 2.9.x), so it does not look Sparkle-version specific.

Here is an annotated trace of one failing run:

# Sparkle launches its two helpers (the installer and the progress UI)
2026-06-02 14:57:06.544623-0300  launchd[1]: [gui/501/<bundle-id>-sparkle-updater [33447]:] Successfully spawned Autoupdate[33447] because semaphore
2026-06-02 14:57:06.550522-0300  launchd[1]: [gui/501/<bundle-id>-sparkle-progress [33448]:] Successfully spawned Updater[33448] because semaphore

# syspolicyd (Gatekeeper) cannot build a code object for the helper it is scanning,
# so the scan comes back with no identity: no team, no id, not even a bundle
2026-06-02 14:57:06.553324-0300  syspolicyd[507]: [com.apple.syspolicy:default] Failed to generate SecStaticCode for <private> error: -67028
2026-06-02 14:57:06.554814-0300  syspolicyd[507]: [com.apple.syspolicy.exec:default] GK performScan: PST: (path: 2eb1f4224b80c40c), (team: (null)), (id: (null)), (bundle_id: (null))
2026-06-02 14:57:06.555358-0300  syspolicyd[507]: [com.apple.syspolicy.exec:default] Error Domain=GatekeeperPolicyScanError Code=-67068 "Failed to create SecStaticCode for URL" UserInfo={NSURL=<private>, NSLocalizedDescription=Failed to create SecStaticCode for URL}
2026-06-02 14:57:06.555359-0300  syspolicyd[507]: [com.apple.syspolicy.exec:default] Returning early error from scanTarget because errors: <private>
# (the -67028 line repeats ~15 more times through 14:57:06.700)

# with no team to match the same-team-ID exemption, App Management denies the helper (no prompt, an "unentitled" binary cannot be prompted)
2026-06-02 14:57:06.627169-0300  tccd[648]: [com.apple.TCC:access] Service kTCCServiceSystemPolicyAppBundles does not allow prompting for unentitled binaries; returning denied.
# macOS immediately queues the user-facing banner for this denial
2026-06-02 14:57:06.627756-0300  usernoted[734]: [com.apple.unc:UserNotifications] Adding new request, remove notifications similar to: <NotificationRecord app:"com.apple.tccd" ident:"B67A-D886" req:"93362490-ACCC-48D6-9617-90D9CB935DA0" uuid:"EFE08DB2" source:"144DF73B" category:"com.apple.tcc.notification.kTCCServiceSystemPolicyAppBundles">

# the denial surfaces to Autoupdate as EPERM creating the staging dir
2026-06-02 14:57:06.647377-0300  Autoupdate[33447]: [org.sparkle-project.Sparkle:Sparkle] Failed to create directory with intermediate components at /Users/<user>/Library/Caches/<bundle-id>/org.sparkle-project.Sparkle/Installation with error Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “Installation” in the folder “org.sparkle-project.Sparkle”." UserInfo={NSFilePath=/Users/<user>/Library/Caches/<bundle-id>/org.sparkle-project.Sparkle/Installation, NSURL=file:///Users/<user>/Library/Caches/<bundle-id>/org.sparkle-project.Sparkle/Installation, NSUnderlyingError=0xbacc140f0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}
# and the host app gets Sparkle's errors back, and the install aborts
2026-06-02 14:57:06.648591-0300  App[33435]: (Sparkle) [org.sparkle-project.Sparkle:Sparkle] Error: An error occurred while running the updater. Please try again later. The remote port connection was invalidated from the updater. For additional details, please check Console logs for Autoupdate. If your application is sandboxed, please also ensure Installer Connection & Status entitlements are correctly set up: https://sparkle-project.org/documentation/sandboxing/ (URL (null))
2026-06-02 14:57:06.648594-0300  App[33435]: (Sparkle) [org.sparkle-project.Sparkle:Sparkle] Error: Error: Failed to create installation cache directory in /Users/<user>/Library/Caches/<bundle-id>/org.sparkle-project.Sparkle/Installation (null) (URL (null))

# ~100 ms later the OS shows the banner ("... was prevented from modifying apps on your Mac")
2026-06-02 14:57:06.732142-0300  usernoted[734]: [com.apple.unc:application] Presenting <NotificationRecord app:"com.apple.tccd" ident:"B67A-D886" req:"93362490-ACCC-48D6-9617-90D9CB935DA0" uuid:"EFE08DB2" source:"144DF73B" category:"com.apple.tcc.notification.kTCCServiceSystemPolicyAppBundles"> as alert (["badge", "sound", "alert"])

On a successful run on the same machine, with the same on-disk helper, the same scan resolves cleanly to our Developer ID team:

2026-06-02 18:16:06.131093-0300  syspolicyd[507]: [com.apple.syspolicy.exec:default] GK evaluateScanResult: 3, PST: (path: a616f8c0259fa594), (team: <TEAMID>), (id: org.sparkle-project.Sparkle.Updater), (bundle_id: org.sparkle-project.Sparkle.Updater), 0, 0, 1, 0, 4, 4, 1

So on your same team ID point: we do not override the policy, it just has no team to match when that scan fails (team: (null) above, vs team: <TEAMID> on success). And on whether Caches is even protected: the denial is specifically kTCCServiceSystemPolicyAppBundles, and after a failure the user TCC db has a denied row for it, matching the System Settings entry you mentioned.

Nothing on disk changes between the success and the failure, only whether that SecStaticCode scan succeeds, which is why it is intermittent and reads like a race evaluating the freshly copied helper.

On reproducing it: I spent several hours yesterday trying to trigger it deliberately with no luck. I removed the App Management entry as you suggested and relaunched, and then removed the binary entirely for a fully clean slate, and still could not reproduce it on demand. That is consistent with an intermittent race rather than a persistent state.

On "no other reports": it is intermittent, but it is not a one off for us, and this is not only from telemetry, we have also had direct user reports about the notification. In our logs the "Failed to create installation cache directory" failure shows up on roughly 1% of update install attempts, on macOS 14, 15 and 26. Per user it is almost always a single occurrence and the next launch installs fine, so the update itself does eventually self recover. The part that worries us is the notification: a user who sees "… was prevented from modifying apps on your Mac" reads it as a security warning about our app, which erodes trust, even though the update succeeds on a later run.

I'm happy to send the raw logs and more information from when I hit it myself over a private channel if that is useful. The -67028 / team: (null) on the helper scan is the part I would most value your read on.

[zorgiepoo]

Can you or @bazl-E hint at what your bundle ID is in any way, specifically the last component of it?

This question wasn't answered. Both of you are redacting the bundle id.
I think I can reproduce the issue now if I use a bundle id ending with ".app" but I am not sure if that's what both of you are doing or not. To reproduce you may also need to remove the caches directory of the app.

Private email: zorgiepoo (at) gmail (dot) com

[fbarbat]

Sorry I missed that critical detail! Indeed, in my case, the bundle ID finishes with a .app. And it is also true that the app I was using for testing does not end with .app and maybe that's why I couldn't reproduce it? Sending you the full logs to your email now. Thanks!

[zorgiepoo]

#2882 has a workaround for resolving this issue.
edit: build artifact is here: https://github.com/sparkle-project/Sparkle/actions/runs/26926127843

@fbarbat confirmed that their app bundle identifier ends with .app
I assume that is the case with @bazl-E 's app too but it is not confirmed.

If your bundle identifier ends with .app I am curious to know why and how you chose your bundle identifier that way. Or did some other tool guide you that way? Because it is very unusual from the standard reverse-DNS convention (tld.myorg.myappname)