macOS 26.5.1: generated rsync scripts cannot read Pods under ~/Desktop (Operation not permitted)

• I've read and understood the CONTRIBUTING guidelines and have done my best effort to follow.

Report

What did you do?

Built an iOS workspace generated by CocoaPods with the project located under ~/Desktop:

~/Desktop/SampleApp

The failure occurs in all three kinds of CocoaPods-generated copy phases:

• [CP] Copy XCFrameworks
• [CP] Copy Pods Resources
• [CP] Embed Pods Frameworks

It affects unrelated dependencies, including Facebook SDK, AppsFlyer, Braintree and AppLovin, rather than one specific Pod.

ENABLE_USER_SCRIPT_SANDBOXING is already NO in the Pods project and app targets. Xcode has Desktop-folder access and Full Disk Access. File ownership and POSIX permissions are normal.

I also reproduced the failure outside Xcode using the same system tool generated by CocoaPods:

mkdir -p /tmp/cp-test
/usr/bin/rsync -av   ~/Desktop/SampleApp/Pods/FBSDKCoreKit_Basics/XCFrameworks/FBSDKCoreKit_Basics.xcframework/ios-arm64/FBSDKCoreKit_Basics.framework/   /tmp/cp-test/FBSDKCoreKit_Basics.framework/

What did you expect to happen?

CocoaPods-generated scripts should copy XCFramework slices, resources and embedded frameworks successfully when a project is stored under ~/Desktop.

What happened instead?

The generated rsync commands can enumerate the source directory but cannot open its files:

rsync: error: .../FBSDKCoreKit_Basics.framework/FBSDKCoreKit_Basics: open (2) in /Users/<user>/Desktop/SampleApp: Operation not permitted
rsync: error: .../FBSDKCoreKit_Basics.framework/Info.plist: open (2) in /Users/<user>/Desktop/SampleApp: Operation not permitted
rsync error: some files could not be transferred (code 23)

The same error occurs for bundle files in [CP] Copy Pods Resources.

Useful comparison:

• cp can read the same files from the Desktop project.
• /usr/bin/ditto source destination successfully copies the same framework/bundle.
• Moving the same source file outside ~/Desktop makes rsync work.
• Setting ENABLE_USER_SCRIPT_SANDBOXING = NO does not resolve this case.

As a local workaround, replacing rsync with ditto in the generated XCFramework/resource/framework scripts allows the build to proceed.

This appears related to macOS 26.5.1 protected-folder access for rsync, but it impacts CocoaPods because current generators rely on rsync in these build phases. Would it be possible to use ditto/another copy mechanism, or add a compatible fallback when rsync is denied?

CocoaPods Environment

   CocoaPods : 1.16.2
        Ruby : ruby 3.3.7 [arm64-darwin25]
    RubyGems : 3.5.22
        Host : macOS 26.5.1 (25F80)
       Xcode : 26.5 (17F42)
         Git : git version 2.50.1 (Apple Git-155)

Installation: rbenv / RubyGems

Related issue

This resembles #12073, but differs in two important ways:

1. ENABLE_USER_SCRIPT_SANDBOXING is already disabled.
2. The failure is specifically reproducible when rsync reads Pods under ~/Desktop on macOS 26.5.1, including from Terminal.

Project that demonstrates the issue

A private production project reproduced the problem. The standalone rsync command and the ditto comparison above reproduce the filesystem behavior without application source code. I can prepare a minimal public sample if needed.