For people who occur "deny(1) file-write-create" error: This update (Xcodeproj 1.26) may potentially break the earlier version of CocoaPods custom shell script [CP] Embed Pods Frameworks, if xcodeproj's version was not locked properly, due to introducing ENABLE_USER_SCRIPT_SANDBOXING = YES.
If you are installing earlier CocoaPods version afterwards, consider locking xcodeproj version prior to 1.26 (a possible way is via Gemfile, as suggested in https://github.com/CocoaPods/CocoaPods/issues/12664#issuecomment-2442796217). Technically, Xcodeproj 1.26 was prepared for a newer CocoaPods version and not backward compatible. So if an old CocoaPods depends upon it, may break. The newer CocoaPods adapted to the new xcodeproj 1.26 was done in https://github.com/CocoaPods/CocoaPods/pull/12656 and released as CocoaPods 1.16.
(How it went wrong? : Before this update, project created by Xcodeproj<1.26 (employed by CocoaPods) would not set this flag explicitly, so at that time, project would only break when somehow Xcode defaults come in (e.g. new project created by Xcode). (Some people have noticed this issue and tried to add some verbose assertions in the [CP] shell script to help people manually recover, see https://github.com/CocoaPods/CocoaPods/pull/12235.) Now, with this update, even the earlier version of CocoaPods can also depend on Xcodeproj>=1.26 (if you install old version of CocoaPods afterwards, without version locks), which makes the old CocoaPods behave differently, as it would set this flag when creates new project, and that results to failure.)
For people who occur "deny(1) file-write-create" error: This update (Xcodeproj 1.26) may potentially break the earlier version of CocoaPods custom shell script [CP] Embed Pods Frameworks, if
xcodeproj's version was not locked properly, due to introducingENABLE_USER_SCRIPT_SANDBOXING = YES.If you are installing earlier CocoaPods version afterwards, consider locking
xcodeprojversion prior to 1.26 (a possible way is viaGemfile, as suggested in https://github.com/CocoaPods/CocoaPods/issues/12664#issuecomment-2442796217). Technically, Xcodeproj 1.26 was prepared for a newer CocoaPods version and not backward compatible. So if an old CocoaPods depends upon it, may break. The newer CocoaPods adapted to the newxcodeproj1.26 was done in https://github.com/CocoaPods/CocoaPods/pull/12656 and released as CocoaPods 1.16.(How it went wrong? : Before this update, project created by Xcodeproj<1.26 (employed by CocoaPods) would not set this flag explicitly, so at that time, project would only break when somehow Xcode defaults come in (e.g. new project created by Xcode). (Some people have noticed this issue and tried to add some verbose assertions in the [CP] shell script to help people manually recover, see https://github.com/CocoaPods/CocoaPods/pull/12235.) Now, with this update, even the earlier version of CocoaPods can also depend on Xcodeproj>=1.26 (if you install old version of CocoaPods afterwards, without version locks), which makes the old CocoaPods behave differently, as it would set this flag when creates new project, and that results to failure.)