Thank you for following up. Yes, all three assumptions are correct: I am using OpenAI’s Codex desktop application. I am a user of Codex, not a developer working on Codex itself. JXA means JavaScript for Automation. To clarify my earlier description, there is an intermediate Node.js process belonging to the application I am developing. The execution chain is: Codex’s local command execution environment → my application’s Node.js process → Node.js child_process.spawn(..., { shell: false }) → /usr/bin/osascript -l JavaScript → JXA calls the Security framework → the local login keychain So, in this implementation, my Node.js process launches osascript; Codex does not directly invoke it. The fixed JXA script runs inside osascript and uses ObjC.import('Security') to call the Security framework. It explicitly opens ~/Library/Keychains/login.keychain-db using SecKeychainOpen. It does not use the Data Protection Keychain or iCloud synchronization. When testing the addition of a dummy generic-password item, SecItemAdd returned OSStatus 100001. I have not yet established the exact internal process hierarchy of Codex’s command execution environment or which restrictions may be inherited by the child processes. What process information or diagnostic evidence would be most useful to collect next to identify the source of this permission denial?

Thank you. I confirmed that this Mac is running macOS 26.6.2 (build 25G83). This is a new Keychain integration. We have not tested it on earlier macOS versions, so we cannot confirm whether this is an OS regression. What diagnostic logs or checks would you recommend to distinguish an inherited App Sandbox restriction from MAC?