How are you running this script? From Terminal? It's a shell (bash) executor on a GitLab runner. I don't know if that qualifies as a yes or a no answer here. However it hadn't been showing differences to local Terminal-executed commands so far.

Based on the open-source code (this make()method is called in SecKeychainCreate()) I understand this must come from either The preference domain being set to the system domain over the user domain, but I don't understand how this could happen, given that there isn't a security command-line-tool equivalent for SecKeychainSetPreferenceDomain(). or the user having wrong settings for $HOME or passwd->pw_dir, but we did check these and they seem to be correct.

Thank you Quinn for your response! I just wanted to come back and reply to myself because I have just found the solution - then I saw your reply and it is exactly what was needed :) I first came to realize that my ACL is actually incorrect deep down because of the partition_list part (security dump-keychain -a path/to/keychain helped me figure this out). It only included the apple-tool: partition (I am creating the keychain items as a pre-run script of the target). Then I found the set-generic-password-partition-list command, the one you suggest. Changing the partition list to apple-tool:,teamid:[my_team_id] solved the problem and the prompt no longer comes up.

Hi, I have just found this thread, and I am an XPC/daemon developer (for an authorization plugin, which is also important here), so I cannot move to data protection keychain. Our flow has been the following: Create a keychain item in System keychain in the daemon: SecTrustedApplicationCreateFromPath to create trusted app references for all variations of authorizationhost and SecurityAgentHelper. SecAccessCreate to create a SecAccess item that includes all SecTrustedApplications from above. SecItemAdd / SecItemUpdate to save the item with this SecAccess instance added to the attributes dictionary: [kSecAttrAccess as String: access] This is all working fine. But then, if I were to Delete this keychain item in the daemon: SecTrustedApplicationCreateFromPath to create trusted app references for all variations of authorizationhost and SecurityAgentHelper. SecAccessCreate to create a SecAccess item that includes all SecTrustedApplications from above. SecItemDelete to delete the item with this SecAccess instance added to the attributes dictionary: [kSecAttrAccess as String: access] I get the above mentioned errSecInvalidOwnerEdit error. What I noticed is that if I add the daemon itself as another SecTrustedApplication to the SecAccess that is created, then the issue is solved. Why can I create and update an item from the daemon, but not delete, if it was the daemon that created the keychain item previously, in another invocation? Is this an expected behavior?

Thank you Quinn for your answer and the confirmation. Reading your post again ("Packaging Mac Software for distribution"), I realized that the Mac Installer Distribution certificate will not show up with security find-identity -p codesigning because it is not a code signing certificate. I removed the -p part and then it listed the certificate as CSSMERR_TP_CERT_EXPIRED. I'm hoping this will fix the issue, but this forum question has been answered. Thanks again!