Hi Quinn, Thank you for your response. I appreciate your help. Let me clarify the exact checks, execution contexts, and intended use case. 1. Exact checks and observations The host is an Apple Silicon Mac running macOS 27.2 (build 26B123). In a normal interactive GUI Terminal, these read-only checks succeeded: /usr/bin/codesign --verify --strict --verbose=2 /usr/bin/true /usr/bin/codesign --verify --strict --verbose=2 /bin/lsBoth returned exit status 0. The official python.org Python 3.13.17 installer also passed pkgutil --check-signature, identifying the Python Software Foundation signing team (BMM5U3QVKW). In a separate AI coding assistant (Cody/Codex) execution context on the same Mac, earlier checks produced different results: codesign verification of Apple-supplied system executables returned CSSMERR_TP_NOT_TRUSTED (exit 1). security dump-trust-settings reported No keychain is available. Verification of the installed Python executable also reported signature-related failures. These observations were collected on different occasions, not as a simultaneous controlled A/B test. Therefore, I cannot yet conclude that the execution context itself caused the discrepancy. 2. Intended use case I am developing a local Python-based research and risk-controlled paper-trading system for personal use. Before allowing the system to execute external-data processing components, I want to establish that its installed Python runtime and relevant executable dependencies pass appropriate integrity and code-signing checks. I am using the official python.org installer. I am not distributing an application, issuing my own Developer ID certificates, or attempting to bypass macOS security protections. I would prefer not to enroll in the paid Apple Developer Program unless it is genuinely required for this use case. 3. My question What is the recommended Apple-supported way to diagnose a discrepancy where codesign verification of the same system executable succeeds in a normal GUI Terminal but fails in another execution context? In particular, which read-only diagnostics would help distinguish a Keychain/session accessibility issue from a code-signing trust evaluation failure? I can perform a controlled comparison and provide exact commands, stderr, exit codes, and relevant process-context information. I would like to investigate this without modifying Keychain trust settings, disabling Gatekeeper/SIP, or changing certificates. Thank you again for your guidance.

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.