macOS code signing: CSSMERR_TP_NOT_TRUSTED in different execution contexts

Code Signing General
ZeusTech63 OP
Created
Replies 2
Boosts 0
Views 111
Participants 2

Hello Apple Developer Community,

I'm running macOS 27.2 on Apple Silicon with Python 3.13.17 installed from the official python.org installer.

I am investigating an inconsistency in macOS code-signing and trust verification.

What I have observed:

  • In the normal graphical Terminal, code-signature checks for /usr/bin/true and the installed Python 3.13 executable succeed.
  • In an earlier, different execution context, trust verification reported CSSMERR_TP_NOT_TRUSTED.
  • The Mac's date and time are configured automatically.
  • The exact cause of the difference between execution contexts remains unknown.

My questions:

  1. What could cause macOS trust evaluation to differ between execution contexts?
  2. Which read-only diagnostics could identify the cause?
  3. How can I investigate this without modifying Keychain trust settings, disabling system security or purchasing a paid developer membership?

I can provide sanitized diagnostic logs if needed.

Thank you for your help!

Replies  2
Boosts 0
Views  111
Participants  2
Etresoft OP

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?
ZeusTech63 OP

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.