I see the same failure as the original poster on Catalina (10.15.7) but retrying the same command and file on Big Sur (11.1) succeeds.

Thanks Quinn for the detailed response. I'll take it item by item. I can try with our Apple Dev identity. It's more involved with the pipeline builds, but I'll try it if you think it will help. Also, the com.apple.security.device entitlement isn’t a thing. Sorry, I made a mistake in my report. It was this entitlement: com.apple.security.device.usb that you mentioned later. If I run the test using a JDK bundle without that entitlement, then open fails with the same error code in my personal user account the same as the agent account with the com.apple.security.device.usb entitlement. Here's how it looks in the xml formatted entitlements: <key>com.apple.security.device.usb</key> <true/> So, when you say that you’re running the test logged in as the Jenkins agent, are you actually logged in? Or relying on Jenkins to log you in? This is through Terminal and sudo su - jenkins-agent. So logged in, but not through the mac login UI. And, if use the login window to log in as the Jenkins user account on the GUI, does your program work? I don't have the credentials for this account since they're managed by another group. But I was able to try with a new testuser account with admin privileges and logging in directly succeeds to open HID like my personal account. If I log in with sudo su - testuser, then it fails with the same error code as the jenkins-agent account. Is there an entitlement that would help in this scenario? Or is it better to just use the Apple Dev identity to sign the JDK?

I was able to sign the JDK with the cert that we ship products with: Apple Developer ID Application. It didn't change the outcome at all. I found that HID open works if sudo is used in the pipeline. I would rather not use that as a permanent solution since it isn't how users run our software, but maybe that helps with diagnosis.

I’m not really a HID expect, but I suspect that this entitlement only works if you’re running in a GUI login context. This makes sense when you think about it; you don’t want random processes running in background contexts to be messing with HID devices. However, your CI system is not running in a GUI login context, and hence this problem. I was able to corroborate this today. The test (HID open) for my logged in personal account was only working over SSH because I also had a screen share to this machine (remote CI node) at the same time. If I only ssh to this machine without GUI login, then the test fails for my personal account just like the CI agent. It looks like the only practical way around it for my needs is sudo. It's good to understand the why at least. If you’ve enabled the App Sandbox, you could try disabling it. That might help. If not, the only good answer I see is to reconfigure your CI system to run a GUI login context. It's a nice suggestion. I may pursue that idea in a GUI driven test at some point in the future. Thanks for all your help on this.