macOS re-prompts for every permission after each update, because the fork build is ad-hoc signed with a new identity every time

[radroid]

Every time the app updates itself, macOS asks for all its permissions again. This is not the updater misbehaving — it is a code-signing problem, and it is fixable for $0.

Diagnosis

Our build is completely unsigned. scripts/build-desktop-artifact.ts:1996 sets CSC_IDENTITY_AUTO_DISCOVERY=false when --signed is not passed, so electron-builder ships the stock prebuilt Electron binary with its original linker signature untouched:

$ codesign -dv --verbose=4 "/Applications/T3 Code (Alpha).app"
Identifier=Electron # <- not com.t3tools.t3code
CodeDirectory flags=0x20002(adhoc,linker-signed)
Signature=adhoc
Info.plist=not bound # <- signature does not cover our Info.plist
TeamIdentifier=not set
Sealed Resources=none

Compare upstream's official build, installed alongside:

$ codesign -dv --verbose=4 "/Applications/T3 Code (Nightly).app"
Identifier=com.t3tools.t3code
CodeDirectory flags=0x10000(runtime)
Authority=Developer ID Application: T3 Tools, Inc. (ARK85ZXQ4Z)
$ spctl -a -vvv ... -> accepted, source=Notarized Developer ID

TCC (the permissions database) keys each grant to the app's designated requirement, derived from its code signature. A signed app's DR is stable — bundle ID plus signing cert — so grants survive updates. An ad-hoc bundle has no cert and no sealed resources, so the DR degrades to the binary's cdhash, which is different on every single build. Each update is therefore a brand-new app as far as macOS is concerned, and every Screen Recording / Accessibility / Microphone / Files-and-Folders / Local Network grant is re-requested from scratch.

Two things that are not the cause, so we do not chase them:

• Quarantine / Gatekeeper. Already handled — installCommands.ts:62 and :78 strip com.apple.quarantine from the dmg and recursively from the staged app. The installed bundle carries only com.apple.provenance.
• Over-broad usage descriptions. Info.plist does declare camera, microphone, Bluetooth, and audio-capture strings we may not need, but those only prompt on first use of the feature, not on update. Worth trimming separately, not the fix here.

Proposed fix: a self-signed code-signing certificate ($0, no Developer Program)

We do not need the $99 Developer Program to get a stable identity — only to get a trusted one. A self-signed cert gives us stability, which is the whole problem.

1. Keychain Access -> Certificate Assistant -> Create a Certificate: self-signed, type Code Signing. Name it something like T3X Local Build.
2. Mark it Always Trust for code signing.
3. Teach build-desktop-artifact.ts a third signing mode between --signed and unsigned — call it local/self-signed — that sets CSC_NAME to that cert instead of forcing CSC_IDENTITY_AUTO_DISCOVERY=false, and enables hardened runtime with the existing entitlements.
4. Point the autobuild pipeline (the t3code-build worktree watcher) at that mode.

The resulting designated requirement is identifier "com.t3tools.t3code" and certificate leaf = <our cert> — identical across every rebuild, so TCC grants persist. The user grants each permission once, ever.

Trade-offs, stated plainly:

• The app still is not notarized, so a freshly downloaded copy would hit the unidentified-developer wall. Irrelevant to the update path, which already de-quarantines.
• The cert lives in one Mac's keychain. Anyone else installing this fork would see the prompts again. Acceptable for a personal fork; a blocker if this is ever distributed.
• Existing grants will be re-prompted one final time when the first self-signed build lands, since the identity changes from cdhash to cert. After that they stick.

Acceptance

Build twice with the new mode, install the second over the first via the normal update path, and confirm no permission dialog reappears. codesign -dv should report our bundle ID as Identifier, a TeamIdentifier, and sealed resources.

Notes

Related but distinct: #41 (autobuild relaunch race).

[radroid]

Looked at this overnight and did not build it — the "$0" cost is right, but the seam cost is not zero

Two things stood in the way of doing this unattended, and both are worth recording before someone picks it up.

1. There is no fork-owned path to a self-signed build

The plan's step 3 — "teach build-desktop-artifact.ts a third signing mode" — is the only way in, and I checked whether the existing flags could be bent instead. They cannot:

• scripts/build-desktop-artifact.ts:1996 sets CSC_IDENTITY_AUTO_DISCOVERY=false whenever --signed is absent, so an unsigned build actively suppresses the cert we would want it to find. Setting CSC_NAME from outside does nothing.
• Passing --signed instead is not a shortcut. On macOS it takes the passkey path, which fails without T3CODE_CLERK_PUBLISHABLE_KEY / T3CODE_CLERK_PASSKEY_RP_DOMAINS (:708), and turns on hardened-runtime and notarization expectations we cannot satisfy with a self-signed cert.

So the third mode really does have to live in that file. And that file is upstream-owned — every commit to it is an upstream PR — and it is not one of the seam ledger's rows. It is also the file SEAMS.md:46 records the fork deliberately not editing, for #47:

serialising the desktop build for #47 is done with vp run build:desktop --concurrency-limit 1 rather than editing build-desktop-artifact.ts.

That does not make this a bad idea — a permanent end to TCC re-prompting is worth a ledger row, and the edit would be additive (a new mode alongside the two that exist). But it is a row on a hot upstream file, and that is your call to spend, not one to make quietly at 2am.

2. The acceptance criterion cannot be met without you

"Build twice with the new mode, install the second over the first via the normal update path, and confirm no permission dialog reappears." Creating the certificate needs Keychain Access and an admin authorisation to mark it Always Trust; the verification needs two full desktop builds and a real permission grant on your machine. None of that is automatable from here, and a signing-mode change that has never produced a bundle is not worth landing.

One thing worth adding to the plan

The issue notes existing grants get re-prompted one final time when the first self-signed build lands. Worth stating in the runbook too, next to the autobuild's install step — otherwise the first build after this ships looks exactly like the bug it fixes, and the natural conclusion is that the fix did not work.

Related, since it came up

#72 (the install-instruction work, PR #78) writes the first-launch copy against the current Gatekeeper behaviour — the app is called damaged, and right-click → Open does not help. If this lands and downgrades that verdict to the ordinary unidentified-developer dialog, the copy to change is two strings in scripts/t3x/install-instructions.json, and the test that pins the wording is what will tell you to change them. So this is not blocked by that work, and that work is not blocked by this.