When you run your tool, are you running it from within Terminal? Or double clicking it in the Finder? I'm running the app from the terminal. It is not intended to be clickable from Finder. But I notice that applications that have entitlements are not clickable compared to applications that have no entitlements. Seems the binary is ok: spctl -a -t open -vvv --context context:primary-signature ./xtensa-esp-elf-gdb-3.11 ./xtensa-esp-elf-gdb-3.11: accepted source=Notarized Developer ID origin=Developer ID Application: ESPRESSIF SYSTEMS (SHANGHAI) CO., LTD. (QWXF6GB4AV) codesign -vvvv -R="notarized" --check-notarization ./xtensa-esp-elf-gdb-3.11 ./xtensa-esp-elf-gdb-3.11: valid on disk ./xtensa-esp-elf-gdb-3.11: satisfies its Designated Requirement ./xtensa-esp-elf-gdb-3.11: explicit requirement satisfied Can I install syspolicy_check to Macos 13? Or it requires kernel changes?

After notarization succeeds, I distribute tar.gz/tar.xz archives

Should I send exactly the same archive to notary service? Now I send only binaries in zip archive to notary service and than pack application with all required files to tag.gz/tar.xz archive. Should I change the approach?

@eskimo , There are no dangling paths in my executable. (/usr/lib/***.dylib and @executable_path/../lib/***.dylib are ok to use) The reason was found by accident (seems gatekeeper does not provide any debug messages :(. I download application from a build server. And sometimes I have to run xattr -d com.apple.quarantine ./xtensa-esp-elf-gdb-3.11 to make it works. I wonder why I have to do this for codesigned and notarized application. Thought that avoiding messages like "from undefined developer" was the target of these actions... What else I have to do to make Gatekeeper happy??

For both cases used the same GDB binary with python support I mean the same binary but signed with different entitlements

@eskimo , let me explain with examples: For both cases used the same GDB binary with python support (xtensa-esp-elf-gdb-3.11). $ otool -L xtensa-esp-elf-gdb-3.11 xtensa-esp-elf-gdb-3.11: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0) @executable_path/../lib/libpython3.11.dylib (compatibility version 3.11.0, current version 3.11.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 907.9.0) Case 1 (library symlink) Use entitlements (disable-library-validation): codesign -d --entitlements - --xml xtensa-esp-elf-gdb-3.11 <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.security.cs.disable-library-validation</key><true/></dict></plist> Run from executable directory: mkdir ../lib ln -s /Library/Frameworks/Python.framework/Versions/3.11/lib/libpython3.11.dylib ../lib/libpython3.11.dylib ./xtensa-esp-elf-gdb-3.11 This does work Case 2 (DYLD_LIBRARY_PATH) Use entitlements (allow-dyld-environment-variables + disable-library-validation): $ codesign -d --entitlements - --xml xtensa-esp-elf-gdb-3.11 <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd"><plist version="1.0"><dict><key>com.apple.security.cs.allow-dyld-environment-variables</key><true/><key>com.apple.security.cs.disable-library-validation</key><true/></dict></plist> Run: export DYLD_LIBRARY_PATH=/Library/Frameworks/Python.framework/Versions/3.11/lib ./xtensa-esp-elf-gdb-3.11 This does not work. Popup window with message about "unidentified developer". How can I see more details about the issue?

@eskimo , thanks for suggestions! Adding com.apple.security.cs.disable-library-validation resolved my issue. However, I encountered a problem when adding com.apple.security.cs.allow-dyld-environment-variables. The application can't start because SIP complains that "it is from an unidentified developer," but app is definitely signed. I found a workaround for this issue by removing allow-dyld-environment-variables but keeping disable-library-validation. Instead DYLD_LIBRARY_PATH variable I can create a symlink to the Python library (@executable_path/../lib/libpython3.11.dyld -> PATH_TO_LIBPYTHON). This solution works like a charm. For both approaches allow-dyld-environment-variables and symlink I using the same binary signed with different entitlements. $ otool -L xtensa-esp-elf-gdb-3.11 xtensa-esp-elf-gdb-3.11: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0) @executable_path/../lib/libpython3.11.dylib (compatibility version 3.11.0, current version 3.11.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 907.9.0) I'm curious if there's a way to use DYLD_LIBRARY_PATH without such a symlink workaround?

@eskimo , it is not