Thank you for your reply. Here are the exact details. 1. Successful checks in the graphical Terminal On October 28, 2026, macOS 27.2 (build 26B123), Apple Silicon: For /usr/bin/true: /usr/bin/codesign --verify --strict --verbose=2 /usr/bin/trueResult: valid on disk satisfies its Designated RequirementExit status: 0. For the official python.org Python 3.13.17 executable: /usr/bin/codesign --verify --strict --all-architectures --verbose=2 /Library/Frameworks/Python.framework/Versions/3.13/bin/python3.13Result: the same two successful verification messages. Exit status: 0. 2. What was different? The failures occurred during read-only checks launched through an automated coding-agent execution environment (Cody/Codex), rather than a manually opened graphical Terminal. In that environment, verification of /usr/bin/true failed with CSSMERR_TP_NOT_TRUSTED (exit status 1). Verification of Python also failed with invalid signature (exit status 1). Both contexts reported the same numeric user ID (501), but I have not established whether they shared the same bootstrap/security session, environment variables, Keychain access, or process ancestry. I also cannot confirm that every verification option was identical across the runs. Therefore, I am not claiming to have proven the root cause. 3. My use case I am developing a personal, local Python-based market-data analysis and paper-trading simulation project. I am not trying to sign, notarize, or distribute a macOS application. I only need to run the official Python interpreter and understand why code-signature verification sometimes fails in the automated execution context. I would prefer to diagnose this using read-only commands without altering Keychain trust settings or disabling macOS security protections. Could you recommend the most useful read-only diagnostics for comparing the two execution contexts? Thank you again for your help.