Thank you very much for your help and guidance throughout this investigation. I agree that we can close this investigation for now. If the issue occurs again, I'll capture a sysdiagnose immediately and report back with the relevant logs. I really appreciate your time and support.

I completed another Documents-directory test with the sysdiagnose procedure ready in case the problem reproduced. It did not reproduce. T0 was 2026-10-07 20:23:34 JST. Immediately after signing, the app and extension both passed default, arm64, and x86_64 strict verification. I then checked both approximately once per minute for 30 minutes; all 30 checks succeeded. The full six verification cases also succeeded again at 30 minutes. There were no changes to SHA-256 hashes, sizes, inode numbers, link counts, mtimes, or complete regular-file manifests. Interestingly, unlike my previous test, the signing information also remained completely normal from T0 through 30 minutes: Authority=Developer ID Application: [redacted] (XY2B8MLPV8) Authority=Developer ID Certification Authority Authority=Apple Root CA TeamIdentifier=XY2B8MLPV8 flags=0x10000(runtime) Secure timestamps were also displayed normally. CSSMERR_CSP_INVALID_KEYATTR_MASK again occurred 12 times during signing, but there were no occurrences after T0. Despite those log entries, the resulting signatures remained fully valid throughout the test. Because the invalid state did not occur, I did not trigger sysdiagnose. I have the procedure ready and will trigger it immediately if the problem reproduces. At this point I have not been able to reproduce the delayed invalidation again since updating the host to macOS 26.7.1 (25G241).

I repeated the Documents-folder test, this time making sure that no verification or diagnostic operation started until all signing processes had completely finished. The host is now macOS 26.7.1 (25G241), with 0 extension(s). I defined T0 as the point where signing of both the app and extension had completed successfully with exit status 0: T0: 2026-10-06 21:36:27 JST Immediately after T0, strict verification succeeded for both the app and Quick Look extension in all six cases: default, arm64, and x86_64. I then verified both approximately once per minute for 30 minutes. All 30 checks succeeded. At 30 minutes, detailed strict verification again succeeded for default, arm64, and x86_64 for both bundles. There were no changes to SHA-256 hashes, sizes, inode numbers, link counts, mtimes, or complete regular-file manifests. So on macOS 26.7.1 I have now had two 30-minute tests without the delayed verification failure: /private/tmp on local APFS: remained valid for 30 minutes my local Documents folder on the same APFS Data volume: remained valid for 30 minutes However, I noticed something else that may be important. From immediately after T0 through the end of the 30-minute test, codesign -d --verbose=4 consistently reported for both the app and extension: Authority=(unavailable) Info.plist=not bound TeamIdentifier=XY2B8MLPV8 flags=0x10000(runtime) Strict verification nevertheless continued to succeed throughout the test. I also could not see the secure timestamp in this display output. CSSMERR_CSP_INVALID_KEYATTR_MASK occurred 12 times during signing, but there were no new occurrences after T0. So while the delayed codesign --verify failure did not reproduce, I am not sure whether this Developer ID signature should be considered completely healthy given the persistent Authority=(unavailable) and Info.plist=not bound output. Also, the earlier delayed failures occurred on macOS 26.6.2 (25G83), whereas these two stable 30-minute tests were performed after the host had updated to macOS 26.7.1 (25G241). Does the persistent Authority=(unavailable) / Info.plist=not bound output indicate a problem even though strict verification succeeds? And would you recommend any specific diagnostic to determine why the signing information is not being displayed normally?

I completed the additional diagnostic test. This time I created and signed a fresh build entirely under /private/tmp, on the local APFS Data volume (/dev/disk3s1, mounted at /System/Volumes/Data), with no cloud-synced directory involved. systemextensionsctl list reported: 0 extension(s) One important difference I noticed during this test is that the host is now running macOS 26.7.1 (25G241). The earlier reproductions were on macOS 26.6.2 (25G83). The app and Quick Look extension both verified successfully immediately after signing, for default, arm64, and x86_64 verification. I then verified both once per minute for 30 minutes. Every verification returned exit status 0. At the 30-minute point, both the app and extension still passed default, arm64, and x86_64 verification. The SHA-256 hashes, sizes, inode numbers, link counts, mtimes, and complete regular-file manifests were unchanged between immediately after signing and 30 minutes later. So the delayed signature invalidation did not reproduce in this test. There is one other potentially interesting result. During signing, the Security log recorded 12 occurrences of: CSSMERR_CSP_INVALID_KEYATTR_MASK The final occurrence was at 20:16:18.735338 JST. There were no new occurrences after signing completed or during the 30-minute monitoring period. Thus, in this test, CSSMERR_CSP_INVALID_KEYATTR_MASK occurred during signing even though the resulting signatures remained valid for the entire 30-minute observation period. Because both the storage location and the OS version differ from my earlier reproductions, I don't think this test by itself tells us whether the change is due to using /private/tmp, the update from macOS 26.6.2 to 26.7.1, or some other host-state difference. Would you recommend that I next repeat the same test from my normal local Documents project location on macOS 26.7.1, so that the storage location is the main variable?

The host startup volume is APFS: Volume Name: Macintosh HD File System Personality: APFS Type (Bundle): apfs The files are under my local Documents folder, but iCloud Drive's "Desktop & Documents Folders" option is disabled. The Documents folder is therefore not being synced by iCloud Drive. I am also not intentionally using any third-party cloud sync service for this project. There is another interesting complication: the exact specimen that failed verification on October 5 has now returned to a valid state, without me intentionally modifying or re-signing it. I ran: codesign --verify --deep --strict -vvvvv "MatFrame Composer.app" and the embedded extension was prepared and validated successfully. The app then reported: MatFrame Composer.app: valid on disk MatFrame Composer.app: satisfies its Designated Requirement I also ran codesign --verify --strict -vvvvv directly on the Quick Look extension, and it is currently valid as well. So unfortunately I cannot capture the detailed verbose failure output from this specimen at the moment. Its verification state has now changed from valid immediately after signing, to invalid approximately six minutes later, and then back to valid again, without any intentional modification. The next time it enters the invalid state, I will immediately run verbose verification on both the app and extension before doing anything else and report the complete output.

I performed the A/B test after completely uninstalling Intego/NetBarrier and rebooting the Mac. Before starting the test: systemextensionsctl list 0 extension(s) Unfortunately, the same problem reproduced. I created a newly signed build using the same Developer ID Application identity. Immediately after signing (20:31:16 JST), both the app and Quick Look extension verified successfully with: default verification arm64 verification x86_64 verification The authority chain, Team ID, Hardened Runtime, secure timestamp, and extension entitlements were all correct. At 20:37:17, approximately six minutes later, both the app and extension failed all three verification tests with: code or signature have been modified and codesign -d reported: Authority=(unavailable) Info.plist=not bound I verified that the files had not changed during that interval. The executable and CodeResources SHA-256 hashes were unchanged, the complete regular-file manifests were identical, and size, inode, link count, and mtime were unchanged. I stopped immediately after reproducing the failure and did not re-sign, package, or notarize the build. So removing NetBarrier and its System Extension did not prevent the issue. It appears that NetBarrier is not a necessary condition for the signature verification failure. I still have this exact failing signed app preserved, as well as the clean macOS VM where the previous failing specimen verified successfully. Would you like me to copy this new failing specimen to the clean VM as well, or is there another diagnostic you would prefer me to run on the host while it is in the failing state?

I performed the clean-VM test you suggested, and the result is quite clear. I reproduced the failure again on the host Mac with a newly signed build. Immediately after signing, both the app and its Quick Look extension verified successfully with codesign --verify --strict, including separate arm64 and x86_64 verification. Approximately five minutes later, without modifying any files, both the app and extension failed verification on the host with: code or signature have been modified and codesign -d reported: Authority=(unavailable) Info.plist=not bound SHA-256 manifests taken immediately after signing and after the failure were identical. I stopped at that point without re-signing, packaging, or notarizing the build, and archived the failing signed app using ditto. I then copied that ZIP to a newly installed macOS VM which had never seen the app before. The VM is running the exact same OS version as the host: macOS 26.6.2 Build 25G83 The ZIP SHA-256 before testing in the VM was: adb286fed8205c12e17c09f2ffa6109afb5ee4771c2690c03701be707fb5c24a which matched the ZIP created on the host. On the clean VM, the exact same signed app verifies successfully: MatFrame Composer.app: valid on disk MatFrame Composer.app: satisfies its Designated Requirement This succeeds for default verification, arm64, and x86_64. The embedded Quick Look extension also verifies successfully for all three: MatFrameQuickLook.appex: valid on disk MatFrameQuickLook.appex: satisfies its Designated Requirement So the same signed code that fails verification on the host Mac verifies successfully in a clean VM running the same macOS build. Regarding your question about third-party security software: I checked and found that Intego NetBarrier is installed on the host. systemextensionsctl list shows: TCG22P5KE4 com.intego.app.netbarrier.firewall.extension (10.9.40/995) NetBarrier Extension [activated enabled] There is also an older 10.9.38 extension in: [terminated waiting to uninstall on reboot] The Mac is not DEP or MDM enrolled; it is my personal Mac. For this latest signing test I turned NetBarrier protection off in its UI before signing. The signature failure still reproduced after approximately five minutes. However, systemextensionsctl continued to show the NetBarrier extension as [activated enabled], so I don't think this test rules NetBarrier out. Would you recommend completely uninstalling Intego/NetBarrier and rebooting the host before repeating the signing test?

Yes. I checked, and I do have Intego NetBarrier installed on the main Mac. systemextensionsctl list shows the following active third-party system extension: TCG22P5KE4 com.intego.app.netbarrier.firewall.extension (10.9.40/995) NetBarrier Extension [activated enabled] There is also an older version (10.9.38/988) in the state: [terminated waiting to uninstall on reboot] The Mac is not managed: Enrolled via DEP: No MDM enrollment: No This is my personal Mac, not an organisation-managed environment. I had not considered NetBarrier as a possible factor in the code-signing issue. Would you recommend that I completely uninstall Intego/NetBarrier and reboot before doing the next signing and verification test?

Thanks — I performed the test you suggested, and the result is quite interesting. I created a clean macOS VM that had never seen the app before. No Apple Developer certificates or Xcode were installed in the VM. Before transferring anything to the VM, I reproduced the failure again on the host Mac with a freshly signed build. The timeline on the host was: 19:58:09 JST: the app and its Quick Look extension both verified successfully with codesign --verify --strict, including separate arm64 and x86_64 verification. 20:03:42 JST: the same app and extension both failed verification for arm64 and x86_64 with: code or signature have been modified At that point codesign -d also reported: Authority=(unavailable) Info.plist=not bound I verified that the signed files had not changed during that interval. The complete file manifests for both the app and extension were identical, and the executable SHA-256, size, inode, link count, mtime, and _CodeSignature/CodeResources SHA-256 were unchanged. I stopped at that point without re-signing the app. I then zipped that failing app and copied the ZIP to the clean VM. Before extracting it, I verified the ZIP SHA-256 on the VM against the hash recorded on the host: a7b652edeb3f17478bc7f4ba99a622ab6d67422a92218d1251e0a5931e36b0a5 The hashes matched. I extracted the ZIP locally on the VM and ran: codesign --verify --strict --verbose=4 codesign --verify --strict --verbose=4 --arch arm64 codesign --verify --strict --verbose=4 --arch x86_64 against both the app and its Quick Look extension. All six verifications succeeded on the clean VM: valid on disk satisfies its Designated Requirement I left the extracted app untouched and repeated the same six verification tests approximately 10 minutes later. All six still succeeded. So the same signed app that was consistently reported as invalid on the host Mac verifies as valid on a clean macOS VM, both immediately after transfer and again after 10 minutes. This seems to indicate that the signature itself is intact and that the failure is specific to the code-signing validation state on the host Mac. What would you recommend checking next on the host? I can collect Security logs, run specific codesign or Security.framework diagnostics, or provide a sysdiagnose while the host is in the failing state.

Thanks. I don't have access to a second physical Mac, so I have now installed a clean macOS VM specifically to perform the test you suggested. However, I discovered something interesting before I could perform the test. Yesterday I made an independent copy of the failing Quick Look extension. At that time, both the original and the copy failed codesign --verify --strict, including architecture-specific verification for both arm64 and x86_64. I also verified that the copy was byte-for-byte identical, had a different inode, contained no hard links or extended attributes, and had identical executable and CodeResources hashes. Today, without modifying that copied extension, the exact same copy now verifies successfully: valid on disk satisfies its Designated Requirement for the default verification as well as both arm64 and x86_64. I checked the other Developer ID-signed copies that I still have, and they currently verify successfully as well. So at the moment I no longer have a specimen that is failing on the host Mac. This appears to show that the verification state can change from invalid back to valid without intentionally modifying the signed code. I have the clean macOS VM ready now. As soon as the failure reproduces again, I will immediately ZIP the failing specimen, copy that ZIP to the clean VM, and run the same codesign --verify there before doing any further troubleshooting. I'll report the host and clean-VM results when I have a failing specimen again.