macOS code signing: CSSMERR_TP_NOT_TRUSTED in different execution contexts

In the normal graphical Terminal, code-signature checks for /usr/bin/true and the installed Python 3.13 executable succeed.

What kind of checks? Please be specific.

In an earlier, different execution context, trust verification reported CSSMERR_TP_NOT_TRUSTED.

Different in what way?

purchasing a paid developer membership

What are you really trying to do there then? There's nothing wrong with not having paid membership. But after a certain point, you may be in territory that goes beyond the expected free use-cases. So what is your use case?

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/true

Result:

valid on disk
satisfies its Designated Requirement

Exit 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.13

Result: 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.

an automated coding-agent execution environment (Cody/Codex)

Ah! Probably should've led with that.

I only need to ... understand why code-signature verification sometimes fails in the automated execution context.

It doesn't.

Could you recommend the most useful read-only diagnostics for comparing the two execution contexts?

Are you sure you really want to dig into this? The short answer is your AI software is doing it wrong. And I'm not even sure what "it" is or why it would be trying to check code signatures.

I don't know what to tell you. There do exists different execution contexts. Sometimes, a given execution context requires a logged-in user session. Usually this is because some command-line tool is trying to break through the user interface/command-line barrier. That's only possible when there is a user logged in to the machine, and using Terminal. But when logged in via ssh remotely, it's a different execution environment and those boundary-crossing operations will fail.

All that being said, when I try this on a remote ssh connection, codesign works fine. So while there is an conceptual artifact that corresponds to what you're describing, the cause is probably something else. I wouldn't be at all surprised if they just vibe-coded it.

See my response on this thread.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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/ls

Both 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.

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?

Are you using AI to write these replies? That's a problem, because the bug is in your AI.