Thank you. Yes—the failing invocation is launched through the command-execution tool in the ChatGPT desktop app (Codex), rather than entered directly in Terminal.app. My Mac is running macOS 27.0.1, build 26A434. The app reports version 26.1013.40934, with “Powered by Codex & OWL” branding. I have not independently identified its bundled command-runner version. The tool reports a workspace-write sandbox with restricted network access. OpenAI documents the use of Seatbelt on macOS, but I have not captured the effective sandbox profile or established whether access to a particular security service is denied. The exact verification command was: /usr/bin/codesign --verify --strict --verbose=6 -R '=anchor apple' /usr/bin/printf On October 23, the results were: From the agent’s command tool, with a pre-verification timestamp of 08:51:00 UTC: CSSMERR_TP_NOT_TRUSTED, architecture arm64e.x1, exit status 1. From ordinary Terminal.app, with a pre-verification timestamp of 08:57:15 UTC: all three verification messages indicated success, exit status 0. The timestamps are 6 minutes 15 seconds apart, so this was not a simultaneous or cache-controlled comparison. Separately collected OS/build information, SHA-256 hashes of both executables, UID, launchctl manageruid and managername matched between the two contexts. These checks do not establish identical sandbox or service-access conditions. I have not changed certificate trust settings or disabled security protections. Is there a supported, narrowly scoped diagnostic that would distinguish certificate trust-evaluation failure from inability to reach a required trust/security service in the restricted execution context? I would prefer not to collect broad private logs or modify the sandbox.