For the endpoint security capability it shows as "Development Developer ID" under provisioning support. I don't know if that means it is development only or also Developer ID distribution?

The profile says <key>com.apple.developer.endpoint-security.client</key> <true/>, so I guess endpoint security is correctly added to the profile. When trying to archive using xcodebuild we also get this error: error: exportArchive: There is a problem with the request entity Error Domain=DeveloperAPIServiceErrorDomain Code=5 "There is a problem with the request entity" UserInfo={IDEDistributionIssueSeverity=3, NSLocalizedRecoverySuggestion=You already have a current Developer ID Application Managed (With Kext) certificate or a pending certificate request., NSLocalizedDescription=There is a problem with the request entity} I have the Developer ID certificate on my machine, but for same reason we get this error from the Developer API. We have tried on multiple Macs with the same error. We have multiple Developer ID certificates. I have no idea what a pending certificate is or where to see those?

Could you help get my ticket looked into? I have only gotten a generic reply so far. Case number: 102278105696

Found a related issue on GitHub: https://github.com/koekeishiya/yabai/issues/2688

Same as my post: https://developer.apple.com/forums/thread/806156 I found a workaround. Drag the binary (e.g sshd-keygen-wrapper) from Finder to the full disk access list in System Settings window. The permission will be given, but it won't show in the list

Good to know. This is a really critical bug. CLI apps can have full disk access or other permissions, but you cannot see it in the list

Bug is still present in macOS 26.2 beta

We have also noticed that if the full disk access is configured using a MDM profile the entry is not added to the TCC.db, but the binary will still have the permission. Something is really broken regarding TCC on 26.1.

maartenweyns: Are you running any security software? Or software that has a SecurityAgent Plugin. Quinn: Our product contains a SecurityAgent plugin and is an essential part of our product. We do a lot of testing, but this issue seems to be hitting some customers depending on maybe their MDM setup and software installed on the Macs. Could you make help me some documentation on changes in 26.1? We do have an SFAuthorizationPluginView, but that is not even invoked for this issue

We are seeing the same issue with our product, except we can see it on Sequoia as well. We see the issue when we are inserting into rights: com.apple.ServiceManagement.daemons.modify We are also adding a mechanism to com.apple.ServiceManagement.daemons.modify. I can't rule out that it also happens in Sequoia, but many of our users see the problem very often on Tahoe.

This is related to this: https://developer.apple.com/forums/thread/806187 This is totally broken on macOS 26.1.

[quote='866132022, DTS Engineer, /thread/807112?answerId=866132022#866132022'] What right is being authorised when this happens? Have you confirmed that the right is still set up the way you think it’s set up? If this is happening in managed environments then my experience is that such environments often have multiple security products installed. It’s easy to imagine these products fighting each other over how a specific right might be authorised. [/quote] It's the com.apple.ServiceManagement.daemons.modify right. We see it on MDM enrolled Macs with only our product installed, but on Macs not enrolled there is no issue. Seems like the SecurityAgent is doing something in the background on MDM Macs. Triggering the plugin should be fine, but taking focus when no UI is shown seems wrong

[quote='866406022, DTS Engineer, /thread/807112?answerId=866406022#866406022'] What does it look like after your modifications? [/quote] { "class" => "evaluate-mechanisms" "comment" => "Preferences." "created" => 784744897.064658 "mechanisms" => [ 0 => "MyAuth:invoke" ] "modified" => 784745142.85089 "shared" => false "tries" => 10000 "version" => 0 }

@ehale I'm testing on latest macOS 26.2 beta 3. I have not seen the focus issue yet. Have you tested on that?

Turns out I was too quick. The issue still occurs on the latest beta, unfortunately.