codesign authorization dialog hangs; XCTest re-sign fails with errSecInternalComponent while standalone signing succeeds

Question

Created 1w

Replies 3

Boosts 0

Participants 2

I’m seeing a reproducible code-signing failure on macOS 26.6.2 with Xcode 26.6 while building an iOS XCTest bundle for a physical device.

A newly created Apple Development identity is valid and can successfully sign and verify a standalone test binary using /usr/bin/codesign. However, xcodebuild build-for-testing reaches the first XCTest re-sign operation and the macOS Keychain authorization dialog for the same development private key becomes unresponsive after entering the login Keychain password and clicking “Always Allow.”

The failing command is effectively:

/usr/bin/codesign --force --sign <Apple Development SHA-1> -o runtime --timestamp=none ... libXCTestSwiftSupport.dylib

and returns:

errSecInternalComponent

The exact same development certificate successfully signs a standalone binary immediately beforehand. The build is running from an ordinary logged-in Terminal session, not SSH or CI.

After aborting the build, inspection showed the XCTest artifacts retained Apple’s original Software Signing certificate rather than the Development certificate, confirming the re-sign did not complete.

I have already recreated the login Keychain once and recreated the Apple Development identity. I do not want to make further Keychain ACL/partition changes without understanding the underlying cause.

Question: What diagnostic should I collect to determine why SecurityAgent/codesign cannot complete private-key authorization for the XCTest re-sign operation when direct signing with the same identity succeeds?

Answer 1

DTS Engineer OP

Apple

1w

Well, that’s not good.

I’d like to clarify one point:

The exact same development certificate successfully signs a standalone binary immediately beforehand

This is specifically referring to your running codesign directly from Terminal, right?

I see two ways to interpret the above:

You ran codesign from Terminal, then ran xcodebuild, and then the first codesign run by xcodebuild has this problem.
You ran xcodebuild, it run codesign once, which worked, and then ran codesign again, which failed.

And I’d like to know which one you’re hitting.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Answer 2

etkrasinski OP

1w

Hi Quinn, yes, I’m specifically referring to running codesign directly from Terminal.

It’s the first case you described:

I ran codesign directly from Terminal against a standalone test binary using the same Apple Development identity. That completed successfully, and I later verified the artifact was signed with the expected development certificate. I then ran xcodebuild build-for-testing. The first CodeSign operation performed by that xcodebuild invocation was for libXCTestSwiftSupport.dylib, and that is where the Keychain authorization dialog became unresponsive and the signing operation returned errSecInternalComponent.

So it is not a case where one CodeSign step inside the same xcodebuild succeeded and a subsequent one failed.

I’ve since reproduced the same authorization-dialog behavior with a brand-new minimal iOS + XCTest project using Product → Build For → Testing, which is the focused sample project I submitted with the DTS case.

Happy to provide the exact standalone codesign command and the failing xcodebuild CodeSign block if useful.

Thanks, Edmund

Answer 3

DTS Engineer OP

Apple

5d

So I suspect that there’s something environmental in play here. If this were affecting everyone using Xcode 26.6 on macOS 26.6.2 the world would be alight with reports like this.

Have you tried this on more than one Mac?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"