What does 'a sealed resource is missing or invalid' mean?

It means the macOS app or plugin bundle was modified after it was code signed. codesign seals the exact contents of the bundle; adding, removing, or changing any file afterward breaks the seal, so codesign --verify reports 'a sealed resource is missing or invalid'. The fix is to make signing the final build step and re-sign the bundle after any change.

Code signing errors › sealed resource is missing or invalid

"a sealed resource is missing or invalid"

Short answer: the bundle was changed after it was code signed. A signature seals the exact bytes of every file in the bundle; touch anything afterward — even a resource, a symlink, or an Info.plist tweak — and the seal no longer matches. Re-sign the bundle as the very last step, after all edits, and the error goes away.

The full message

YourPlugin.vst3: a sealed resource is missing or invalid
file modified: /…/YourPlugin.vst3/Contents/Resources/…

Why it happens

macOS codesign records a cryptographic hash of every file in the bundle at signing time. codesign --verify recomputes those hashes and fails if anything differs. Common culprits for plugin and app developers:

A build script copies a file, bumps a version string, or rewrites Info.plist after the signing step.
Notarization stapling or a packaging step writes into the bundle after signing (staple the right object — see below).
A tool "fixes up" a framework or dylib post-sign (dSYM stripping, install-name changes with install_name_tool).
The bundle was zipped/unzipped with a tool that altered metadata or symlinks.

How to fix it

Make code signing the final step of your build. Nothing may write into the bundle after codesign runs.
Re-sign the bundle after any change, signing inside-out — embedded frameworks and helpers first, then the outer bundle:
```
codesign --force --options runtime --timestamp \
  --sign "Developer ID Application: Your Co (TEAMID)" \
  YourPlugin.vst3
```
If you use install_name_tool or strip symbols, do it before signing, never after.
Stapling a notarization ticket to a bundle is allowed and does not break the seal — but stapling must target the bundle, not files inside it.

How to confirm it's fixed

codesign --verify --deep --strict --verbose=2 YourPlugin.vst3
# expect: valid on disk / satisfies its Designated Requirement

A passing codesign --verify is necessary but not sufficient for shipping — the artifact also needs a Developer ID signature, the hardened runtime, a secure timestamp, and notarization. Confirm the whole picture with spctl -a -vvv on a clean machine.

Check your actual build in 30 seconds

Upload your finished bundle, pkg, or zip and get the exact reason it passes or fails Apple's checks — free, no account.

Check my installer →

Preventing it entirely

This error is a symptom of hand-managed signing where a step touches the bundle after the seal. SignetKeys runs signing as the final, atomic step of a fixed inside-out pipeline — sign, timestamp, harden, notarize, staple, verify — so nothing modifies a bundle after it's sealed, and your Developer ID key stays in hardware custody, never in your CI. See how it works →

← All code signing errors