codesign on Mac: Chrome Fails --strict, Gatekeeper Passes

I ran codesign --verify --deep --strict "/Applications/Google Chrome.app" on macOS 26.4.1. After 13 seconds it printed resource fork, Finder information, or similar detritus not allowed and exited 1. Gatekeeper's own check on the same bundle, spctl -a -vv, answered accepted and source=Notarized Developer ID. So the strictest form of the codesign command on Mac rejects an app that the system is happy to launch.

That result came out of a morning of probes on a Mac mini M4 (Mac16,10, macOS 26.4.1 build 25E253). I signed and broke throwaway binaries and bundles, timed verification on the five largest apps in /Applications, and read all 598 Stack Overflow questions with "codesign" in the title. Below is what the tool does, where its output actually goes, and which errors are worth worrying about.

What codesign is on a Mac

/usr/bin/codesign is Apple's command-line tool for adding, checking and printing code signatures. On this machine it is a 459,824-byte universal binary (x86_64 and arm64e) from the codesign-83.100.6 project, itself signed by Apple. Run with no arguments it prints a five-line usage summary and exits 2. The modes you will meet are -s (sign), -v (verify), -d (display) and -h (show what is hosting a process). The man page lists four exit codes. 0 means everything passed and 1 means a signing or verification failure. 2 means bad arguments, and 3 means the signature was valid but did not satisfy a -R requirement.

If you saw "codesign" in Activity Monitor, it is a short-lived process that some other program launched to sign or check something. On Apple Silicon, Homebrew 7.0.7 does not launch it at all: its keg relocation code signs bottles in-process with ruby-macho and only shells out to codesign on Intel Macs. The usual parents are Xcode builds and packaging tools such as Flutter, PyInstaller and Electron builders, which together account for most of the Stack Overflow questions further down. To see which program launched one, run ps -o ppid= -p <pid> while it is running (the ps command on Mac post covers the flags). I did not catch a high-CPU codesign process on this machine, so I can't name a culprit beyond that.

The first trap: everything goes to stderr

codesign -dv /Applications/Safari.app prints 11 lines. I redirected the two streams to files: standard output got 0 lines and standard error got all 11. That is why this pipeline matches nothing:

$ codesign -dv /Applications/Safari.app | grep -c TeamIdentifier
Executable=/System/Volumes/Preboot/Cryptexes/App/System/Applications/Safari.app/...
...(all 11 lines appear on the terminal, unfiltered)
0
$ echo $pipestatus
0 1

$ codesign -dv /Applications/Safari.app 2>&1 | grep TeamIdentifier
TeamIdentifier=not set

The lines scroll past on the terminal, so it looks as though grep ignored its pattern. In fact grep never saw them. Add 2>&1 before the pipe. The entitlements dump is the exception: codesign -d --entitlements - (with or without --xml) writes the entitlements to standard output and only the Executable= header to standard error. That makes an unanswered 2023 Ask Different question, Grepping output from Codesign, a different bug. Its command was codesign -d --entitlements - /Applications/Safari.app | grep -i "*sandbox". macOS's BSD grep treats a leading * as a literal asterisk, so it matched 0 lines, while grep -i sandbox matched 7. The older --entitlements :- form still works but now prints "Specifying ':' in the path is deprecated".

Signing: what each command did

I compiled a one-line C program with clang, then signed, re-signed, stripped and damaged it. No signing identity exists on this machine (security find-identity -v -p codesigning reports 0 valid identities found), so everything below uses ad-hoc signing, -s -.

Command	Exit	Message / result
Fresh clang output, codesign -dv	0	flags=0x20002(adhoc,linker-signed): the linker already signed it
codesign -s - m on that linker-signed file	0	No message, signature silently replaced (flags become 0x2(adhoc))
codesign -s - m again	1	m: is already signed
codesign -f -s - m	0	m: replacing existing signature
codesign -f -s "Developer ID Application" m	1	Developer ID Application: no identity found
--remove-signature, then -v	1	code object is not signed at all; running it: exit 137
Flip one byte after signing, then -v	1	invalid signature (code or signature have been modified); running it: exit 137
codesign -s - s.sh (a shell script)	0	Signature stored in three com.apple.cs.* extended attributes
Append a line to s.sh, then -v	1	invalid or unsupported format for signature; the script still runs, exit 0

Exit 137 is the kernel's SIGKILL. On Apple Silicon an arm64 binary with no valid signature is not allowed to run, which is the same failure behind zsh: killed after patching or copying a binary. A script is different, because the kernel runs the interpreter, not the script, so a broken script signature changes nothing at launch. The error text differs too. A modified Mach-O reports "modified", while a modified script reports "invalid or unsupported format for signature", so searching for one message will not find the other.

Which extended attributes break signing

The detritus error is the one people search for, so I tested it attribute by attribute. Each row is a fresh bundle with an unsigned executable and one resource file, r.txt, carrying the attribute.

Attribute on r.txt (or location)	codesign -s -
none	0, signed
com.apple.FinderInfo	1, detritus not allowed
com.apple.ResourceFork	1, detritus not allowed
com.apple.quarantine	0, signed
com.apple.metadata:kMDItemWhereFroms	0, signed
com.apple.provenance	0, signed
an arbitrary user.test	0, signed
FinderInfo on the .app folder itself, or on the main executable	1, detritus not allowed
an extra junk.txt at the bundle root	1, unsealed contents present in the bundle root

Only two attribute names matter: FinderInfo and ResourceFork. Quarantine and provenance, the ones that make macOS show "downloaded from the internet" warnings (see No such xattr: com.apple.quarantine), do not block signing. On a bundle that is already signed, adding a quarantine attribute or a .DS_Store at the bundle root still passes -v --strict. A FinderInfo attribute added afterwards does not. Editing or adding a resource file gives a sealed resource is missing or invalid.

Apple's fix in Technical Q&A QA1940 (2016, when macOS Sierra introduced the rule) is xattr -lr to find the files and xattr -cr to clear them. That worked here. com.apple.provenance survives xattr -cr, but it doesn't block signing, so verification passed. The most-voted question on the error, Code Sign Error in macOS Monterey (127,322 views), has a 113-vote answer recommending find . | xargs -0 xattr -c. I ran it on three files carrying FinderInfo: it exited 1 with xattr: No such file and cleared none of them. -0 tells xargs to split on NUL bytes, and plain find never emits one, so xargs passed the whole newline-joined list as a single file name. find . -print0 | xargs -0 xattr -c cleared all three (more on that pairing in xargs on macOS).

Why Chrome fails --strict

With -vvvv, codesign named the item it stopped on: Disallowed xattr com.apple.FinderInfo found on .../Google Chrome Framework.framework. I then listed every attribute in the bundle. 69 of its 918 directories, and none of its files, carry a 32-byte FinderInfo attribute, all with the same bytes. Bytes 10 to 13 are FF and the rest are zero, which in a folder's Finder info is the icon-position field set to (-1, -1). The other eight apps in /Applications, including Slack, Discord and VS Code, have none. The bundle also holds three framework versions (153.0.8010.54, 155.0.8059.40 and 155.0.8059.80), left over from updates.

I don't know what wrote those attributes. QA1940 says browsing a bundle with Finder's Show Package Contents can add Finder info, and I can't rule that out. The Contents folder and the newest framework version were both last modified at 06:15:29 on 2026-10-16, but modification times don't record who set an attribute. Plain codesign -v and --deep without --strict both pass, and Gatekeeper accepts the app, so for running Chrome this changes nothing. It matters if a script checks downloaded apps with --strict, or if you copy the bundle and re-sign it. I left the attributes in place, because Chrome isn't my app to modify.

How long verification takes

App	Size	Files	-v real	-v --deep --strict real	user + sys
Google Chrome	2,152 MB	1,013	0.04 s	13.0 s (fails)	4.1 s
Visual Studio Code	1,497 MB	2,729	0.13 s	4.7 s	2.6 s
Claude	683 MB	1,918	0.06 s	3.1 s	1.7 s
Slack	312 MB	322	0.02 s	1.5 s	0.5 s
Tailscale	68 MB	122	0.10 s	0.1 s	0.1 s

Each command ran twice and the table shows the second run. The two deep runs differed by at most 0.11 s, so file caching did not change those numbers. Most of the deep time is not CPU: Chrome's 13 seconds include only 4.1 seconds of user and system time. A plain -v checks the main executable and the resource seal without opening nested code, which is why it takes well under a second even for Chrome. --deep descends into every framework and helper, and on Chrome that is more than 300 times slower. Note also that --deep is deprecated for signing since macOS 13, according to the man page. It is still fine for verifying.

What people actually ask about codesign

The Stack Exchange API returns 598 Stack Overflow questions with the word "codesign" in the title (2008 to 2026, 4,018,897 views combined), 15 on Ask Different and 1 on Super User. I sorted the Stack Overflow titles into groups by keyword:

Title group	Questions	Views
"failed with exit code" / "Failed to codesign" (no cause in title)	265	1,884,788
Identity, certificate or provisioning profile	52	456,654
Keychain access prompts, errSecInternalComponent	44	751,851
CI, SSH or scripted signing	25	156,312
Frameworks, dylibs, nested code	19	124,685
Not signed / sealed resource / modified	10	85,002
Notarization or Gatekeeper	8	79,582
Entitlements	6	7,886
Everything else (includes 1 detritus title)	169	472,137

The most-viewed single question, at 296,151 views, is codesign asking for a keychain password over and over. 151 of the 598 titles name iOS, Flutter, Xamarin or another mobile toolchain. Detritus barely shows up, with 1 title, but that is because people title those questions with the error text. A separate title search for "detritus" finds 11 Stack Overflow questions with 157,372 views. Ten are this signing error and one is about R's CRAN checks, and only one of the 11 also has "codesign" in its title. Of the 598, 406 have an answer that was upvoted or accepted and 271 have an accepted one. The other 192, about one in three, have neither.

For moving signed apps between machines without stripping or adding attributes, see the ditto command on Mac.

FAQ

What is codesign on Mac?

codesign is Apple's command-line tool at /usr/bin/codesign for signing apps and binaries, verifying signatures and printing signature details. When it shows up in Activity Monitor, another program (usually Xcode or a build or packaging tool) launched it to sign or check files. It exits when the job is done.

How do I fix "resource fork, Finder information, or similar detritus not allowed"?

Run xattr -lr on the app bundle to find files carrying com.apple.FinderInfo or com.apple.ResourceFork, then xattr -cr on the bundle to clear them and sign again. Only those two attributes trigger the error. Quarantine and provenance attributes do not. If you use find with xargs -0, add -print0 to find, or nothing is cleared.

How do I check if an app is signed on Mac?

Run codesign -dv followed by the app path to print the signing details, and codesign -v to verify it. A valid signature gives exit code 0 and no output. Both commands write to standard error, so add 2>&1 before piping the output to grep. To see whether Gatekeeper would allow the app, run spctl -a -vv on it.

How this was checked: every command ran on 2026-10-17 on a Mac mini M4 (Mac16,10) with macOS 26.4.1 (25E253) and /usr/bin/codesign from codesign-83.100.6. Signing tests used a throwaway C program and hand-built bundles in a scratch folder, signed ad-hoc because the machine has no signing identity. Installed apps were only read and verified, never modified. Timings are /usr/bin/time -p over two runs each. The question counts come from the Stack Exchange API title search on 2026-10-17, grouped by keyword matching on titles, which is my classification, not the sites'. The Homebrew behaviour is from Homebrew 7.0.7's source on this machine, checked against the current GitHub version.