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.