richmond62 wrote: ↑Sat Feb 07, 2026 10:18 am
Is that only true for Catalina?
And what are the reasons for that?
Nowadays you stand a much better chance of getting both a more accurate and definitely a faster answer using one of the many free (or free-tier) LLMs. The role of forums is diminishing day by day but probably forums will still remain in some form, especially for niche areas (like LiveCode) where specific knowledge isn't published widely enough to secure a correct answer from LLMs. But for generic questions like this, LLMs are better. For example:
Question posted to ChatGPT:
please see web page:
viewtopic.php?f=7&t=40058
The last post asks:
>Is that only true for Catalina?
>And what are the reasons for that?
can you answer?
And the (instant) response:
ChatGPT wrote:
1. Is the problem only true for Catalina?
No — but it is particularly visible starting with macOS Catalina (10.15).
macOS Catalina introduced stricter privacy and security protections that didn’t exist in earlier macOS versions. On older macOS releases (e.g., Mojave or earlier), running codesign from the command line against an app bundle didn’t tend to trigger the same kind of “Operation not permitted” errors because those releases did not enforce as many sandbox or disk-access restrictions at the system level.
However:
• Some of the underlying restrictions (System Integrity Protection and notarization requirements) exist in major macOS releases both before and after Catalina — but Apple made them stricter and enforced them more aggressively in Catalina and later major versions. 
• Later versions of macOS (Big Sur, Monterey, Ventura, etc.) have similar or even stricter security policies than Catalina, especially around notarization and full disk access.
So the behavior of hitting an “Operation not permitted” error when codesigning without appropriate permissions isn’t exclusively a Catalina-only problem — but Catalina is the first macOS release where many developers began encountering it commonly because of new privacy protections and notarization enforcement.
⸻
2. Why does this happen (the reasons)?
There are three main reasons this sort of error happens on Catalina (and later macOS releases):
A. New Privacy / Full Disk Access Controls
Starting with macOS Mojave and reinforced in Catalina, Apple introduced privacy protections that block processes from accessing certain directories (e.g., Desktop, Documents, Downloads) unless:
• the process is granted “Full Disk Access” under System Preferences → Security & Privacy → Privacy, or
• the app has specific entitlements.
Without those permissions, many file-related operations can produce an “Operation not permitted” error in the Terminal or scripts. 
Codesigning tools run in Terminal are subject to this:
even if you run codesign with sudo, macOS still enforces privacy restrictions — so if Terminal (or whatever shell you’re using) hasn’t been granted Full Disk Access, it may be blocked from reading/writing certain files inside the app bundle.
B. Catalina’s Notarization & Hardened Runtime Requirements
Catalina also introduced notarization checks, which are part of Apple’s package signing security:
• Notarization ensures that the app has been scanned and approved by Apple’s servers.
• Catalina will warn users (or block execution by default) if an app is not notarized.
• Code signing must include the correct entitlements and bundles.
If the app’s code signature is missing or incorrect, or if parts of the bundle aren’t signed, macOS can refuse to proceed with codesign operations or with executing the app. (Later versions of macOS continue to enforce and expand on this.) 
C. System Integrity Protection (SIP) and Protected Areas
Even when you have administrative (root) privileges, System Integrity Protection (SIP) — a macOS kernel security feature — prevents certain system-level modifications unless explicitly allowed. SIP was first introduced earlier (OS X El Capitan), but combined with Catalina’s privacy controls, it makes these permission issues more obvious to end-users. 
⸻
Summary
Is the issue only true for Catalina?
→ No. Catalina is where it became widespread and visible due to new privacy and notarization requirements, but similar protections exist in later releases and partly in earlier ones as well.
Why does it happen?
→ Because of macOS security design:
• Full Disk Access / privacy protections block Terminal/shell access to certain files by default. 
• Notarization and hardened runtime requirements enforce stricter signing rules for app bundles. 
• System Integrity Protection limits even root from accessing certain protected areas unless entitlements and permissions are correctly granted. 
To avoid this error, you typically need to ensure that your terminal/shell has Full Disk Access granted (and that you are signing and notarizing your app correctly), which is a change introduced by Apple’s security model in Catalina and later macOS versions.
⸻
If you want, I can tailor a short step-by-step on how to properly grant permissions and codesign/notarize a LiveCode standalone on modern macOS.
This is probably the best way to solve issues relating to code signing and similar generic issues (ie not specifically LiveCode-related), although it does a decent job at taking a stab at LiveCode Script as well.
