fix(t3x): sign the macOS build with a stable identity so permission grants survive updates (#70) - #85
Merged
Merged
Conversation
…rants survive updates (#70) macOS keys every permission grant to the app's designated requirement. Ad-hoc bundles have no certificate to name, so codesign falls back to the binary's cdhash — which changes every build: $ codesign -d --requirements - "/Applications/T3 Code (Alpha).app" # designated => cdhash H"d48d810e7b110d8d70a793f827dd23a7b2506405" Every update was therefore a brand-new app to macOS, and Screen Recording, Accessibility, Microphone, Files & Folders and Local Network were re-requested from scratch each time. Upstream's own build names a certificate instead and keeps its grants, which is the shape this copies. The fix is not "sign it" but "sign it with an identity that does not move", so a free self-signed certificate is enough — it does not have to be trusted by Apple, it has to be the same one next time. - scripts/t3x/setup-mac-signing.sh creates that identity (10 years, its own keychain so no GUI keychain dialog can block an unattended build), self-verifies it, and exports the p12 for CI. - t3x-release.yml imports it on the mac runner and exports CSC_NAME. - auto-build-desktop.sh picks the same identity up locally, so both paths produce one identical requirement rather than two. - scripts/t3x/verify-mac-signature.ts asserts it on the .app inside the shipped dmg, and fails a CHANGED identity as well as a missing one: a build signed by a different certificate is perfectly signed and still costs a round of dialogs. electron-builder only WARNS when it finds no identity, so without this check the regression is invisible until the dialogs come back days later. No upstream file is edited, and #70's plan to add a third signing mode to build-desktop-artifact.ts turned out to be unnecessary: app-builder-lib consults CSC_IDENTITY_AUTO_DISCOVERY only when no identity was named, so exporting CSC_NAME around the existing unsigned build is the whole mechanism. Zero new SEAMS.md rows. Expect one final round of prompts when the first signed build installs — the identity moves from a cdhash to a certificate — then silence. That install looks exactly like the bug it fixes, so the fix is judged on the second one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…ws with upstream (#70) Stable signing was necessary but not sufficient. macOS stores one TCC permission row per (service, bundle id), and both apps report the same id: $ mdls -name kMDItemCFBundleIdentifier "/Applications/T3 Code (Alpha).app" \ "/Applications/T3 Code (Nightly).app" com.t3tools.t3code com.t3tools.t3code So the fork's build and upstream's nightly shared one row per permission, and whichever launched last owned it — the other was re-prompted no matter how well either was signed. Anyone running both was getting dialogs from this on top of the cdhash problem. The fork now uses dev.curlycloud.coil, after coil (coil.curlycloud.dev). DESKTOP_APP_ID becomes an env escape hatch rather than a changed literal: `process.env.T3X_DESKTOP_APP_ID?.trim() || "com.t3tools.t3code"`. That keeps upstream's default, upstream's three assertions on the value, and upstream's behaviour on an unset environment — a changed literal would have cost a second seam row on build-desktop-artifact.test.ts as well. One line, ten of comment, recorded in SEAMS.md as the ledger's 38th row and its first deletion. Two deliberate non-changes: - productName stays "T3 Code (Alpha)". The updater refuses an install when the .app name inside the dmg differs from the installed one, so renaming the app would break the update path this is meant to make quiet (#71). - User data does not move: ~/Library/Application Support/t3code comes from a hardcoded userDataDirName, not from the bundle id. Landing in the same release as the signing change costs ONE round of permission prompts between them rather than two. Guarded from the fork side, because a silent revert here is invisible until the dialogs come back days later on someone's machine: mac-signature.test.ts asserts the hook still exists and that the release workflow, the local autobuild and the certificate setup all set it to the same value, and verify-mac-signature.ts fails any artifact whose signing identifier is not that value. The one remaining failing test is the pinned designated requirement, which does not exist yet — it lands with the certificate's trust step. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
12 tasks
…#70) Recorded from the identity itself, and proven stable before being trusted: two stub bundles with different contents (CDHash e7c414c8… vs 6e01fb0b…) signed with this certificate produce one byte-identical requirement, and both satisfy it under `codesign --verify --deep --strict`. identifier "dev.curlycloud.coil" and certificate leaf = H"267dc442f7…" Compare what shipped before — `cdhash H"d48d810e7b110d8d70a793f827dd23a7b2506405"`, a different value on every build, which is the entire bug. This file is what turns "is it signed?" into "is it signed by the same thing as last time?". Rehearsed both ways against the real identity: a build signed with it verifies clean, and one signed with a different valid certificate is refused with the requirement diff, exit 1. Also cross-references #71: renaming the certificate would move this string and cost another round of prompts, and renaming productName makes the updater refuse the first renamed build by design. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…e upstream line The header still said 'zero upstream seams', which was true of the signing half and stopped being true when the bundle-id change landed in the same PR. A doc that contradicts SEAMS.md is worse than no doc. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… that is fine `add-trusted-cert -k /Library/Keychains/System.keychain` copies the certificate into the System keychain as well as trusting it, so find-identity reports the identity from two keychains. Verified that codesign by name with no --keychain — electron-builder's exact call — still resolves and signs correctly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Uh oh!
There was an error while loading. Please reload this page.
radroid added a commit
that referenced
this pull request
Aug 12, 2026
…ures (#71) The rename is mechanical; the risk is not. Four of the strings involved are load-bearing for something that outlives the merge, and each fails without an error surface: - the build counter is github.run_number, keyed to a WORKFLOW FILENAME, so renaming t3x-release.yml restarts it at 1 against clients sitting at 26 and every one of them skips forever. The issue attributes this hazard to the version string; that part is genuinely safe. The filename is not. - the relay hostname is compiled into builds already on disk, so the old Worker has to serve permanently. The shim proxies rather than redirects: relayClient talks through Effect's HttpClient and treats any non-2xx as bad-status, and redirect behaviour on a live SSE stream cannot be tested against builds already in the field. - a LaunchAgent plist hardcodes scripts/t3x/auto-build-desktop.sh, so the rename stops the nightly build with no log line. Same failure class as #41. - app.setName() sets the safeStorage Keychain service name, so saved environment tokens stop decrypting. Threads are unaffected -- userDataDirName is a hardcoded literal, not derived -- which is why #85 moved nobody's data. Also records the two deliberate displacement edits (APP_BASE_NAME, productName) that break the fork's +N/-0 seam invariant, so a later sync reads them as recorded rather than as drift. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
radroid added a commit
that referenced
this pull request
Aug 12, 2026
…tificate (#71) APP_BASE_NAME T3 Code -> T3 Coil (DesktopEnvironment.ts) productName T3 Code (Alpha) -> T3 Coil (Alpha) (apps/desktop/package.json) bundle id dev.curlycloud.coil -> dev.curlycloud.t3coil signing certificate T3X Code Signing -> T3 Coil Code Signing APP_BASE_NAME is the one that matters: displayName is derived from it, and that reaches app.setName(), the About panel, every window title, the Linux .desktop entry, and — through getAppBranding() — the web UI, which reads the injected value rather than hardcoding one. So renaming one literal renames the app almost everywhere it is computed. Almost. 31 upstream-owned files still say "T3 Code" in body copy ("T3 Code needs the relay client..."). Renaming those means displacement edits on 31 more upstream files for prose, which is a bad trade against the sync cost; left alone deliberately, not missed. Three things that look like they should have moved and must not: - legacyUserDataDirName stays "T3 Code (Alpha)". It names a directory that already exists on disk and is a hardcoded literal, not derived from APP_BASE_NAME. That is why #85 moved nobody's threads and why this does not either. DesktopAppIdentity.test.ts now asserts both spellings a few lines apart, with a comment, because the pair looks like a typo and is not. - branding.test.ts's injected-branding case keeps "T3 Code" fixtures. It asserts that injection WINS over the module constant; matching the fixture to the constant would make it pass whether injection works or not. - resolveDesktopProductName's "T3 Code (Nightly)" is upstream's literal on a branch this fork never reaches, since nothing here builds a -nightly.<d>.<d> version. The bundle id and certificate each invalidate every macOS TCC grant, because the designated requirement names both. Done together so the user pays one round of permission dialogs rather than two. The certificate half is NOT complete in code alone: a new name means a new certificate, so setup-mac-signing.sh --rotate has to run before this merges, and designated-requirement.txt has to be re-recorded from it. What is committed here has the new identifier and the CURRENT leaf hash, which is exactly right until the rotation happens and loudly wrong after it — the release compares that file byte for byte. Also renames the pnpm-lock.yaml importer for the relay directory move in the previous commit; without it `pnpm install --frozen-lockfile` fails, which is how it was caught. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
radroid added a commit
that referenced
this pull request
Aug 17, 2026
…ures (#71) The rename is mechanical; the risk is not. Four of the strings involved are load-bearing for something that outlives the merge, and each fails without an error surface: - the build counter is github.run_number, keyed to a WORKFLOW FILENAME, so renaming t3x-release.yml restarts it at 1 against clients sitting at 26 and every one of them skips forever. The issue attributes this hazard to the version string; that part is genuinely safe. The filename is not. - the relay hostname is compiled into builds already on disk, so the old Worker has to serve permanently. The shim proxies rather than redirects: relayClient talks through Effect's HttpClient and treats any non-2xx as bad-status, and redirect behaviour on a live SSE stream cannot be tested against builds already in the field. - a LaunchAgent plist hardcodes scripts/t3x/auto-build-desktop.sh, so the rename stops the nightly build with no log line. Same failure class as #41. - app.setName() sets the safeStorage Keychain service name, so saved environment tokens stop decrypting. Threads are unaffected -- userDataDirName is a hardcoded literal, not derived -- which is why #85 moved nobody's data. Also records the two deliberate displacement edits (APP_BASE_NAME, productName) that break the fork's +N/-0 seam invariant, so a later sync reads them as recorded rather than as drift. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
radroid added a commit
that referenced
this pull request
Aug 17, 2026
…tificate (#71) APP_BASE_NAME T3 Code -> T3 Coil (DesktopEnvironment.ts) productName T3 Code (Alpha) -> T3 Coil (Alpha) (apps/desktop/package.json) bundle id dev.curlycloud.coil -> dev.curlycloud.t3coil signing certificate T3X Code Signing -> T3 Coil Code Signing APP_BASE_NAME is the one that matters: displayName is derived from it, and that reaches app.setName(), the About panel, every window title, the Linux .desktop entry, and — through getAppBranding() — the web UI, which reads the injected value rather than hardcoding one. So renaming one literal renames the app almost everywhere it is computed. Almost. 31 upstream-owned files still say "T3 Code" in body copy ("T3 Code needs the relay client..."). Renaming those means displacement edits on 31 more upstream files for prose, which is a bad trade against the sync cost; left alone deliberately, not missed. Three things that look like they should have moved and must not: - legacyUserDataDirName stays "T3 Code (Alpha)". It names a directory that already exists on disk and is a hardcoded literal, not derived from APP_BASE_NAME. That is why #85 moved nobody's threads and why this does not either. DesktopAppIdentity.test.ts now asserts both spellings a few lines apart, with a comment, because the pair looks like a typo and is not. - branding.test.ts's injected-branding case keeps "T3 Code" fixtures. It asserts that injection WINS over the module constant; matching the fixture to the constant would make it pass whether injection works or not. - resolveDesktopProductName's "T3 Code (Nightly)" is upstream's literal on a branch this fork never reaches, since nothing here builds a -nightly.<d>.<d> version. The bundle id and certificate each invalidate every macOS TCC grant, because the designated requirement names both. Done together so the user pays one round of permission dialogs rather than two. The certificate half is NOT complete in code alone: a new name means a new certificate, so setup-mac-signing.sh --rotate has to run before this merges, and designated-requirement.txt has to be re-recorded from it. What is committed here has the new identifier and the CURRENT leaf hash, which is exactly right until the rotation happens and loudly wrong after it — the release compares that file byte for byte. Also renames the pnpm-lock.yaml importer for the relay directory move in the previous commit; without it `pnpm install --frozen-lockfile` fails, which is how it was caught. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
radroid added a commit
that referenced
this pull request
Aug 17, 2026
The first-update note said the builds were unsigned and to expect screen-recording and automation prompts. All three claims were wrong. They have been signed since #70/PR #85 — verified on the installed 0.0.33-coil.105, whose designated requirement matches the recorded one byte-for-byte and still satisfies itself after an in-app update. The app requests neither screen recording nor automation: there is no desktopCapturer, getDisplayMedia, osascript or Apple Event use anywhere in apps/desktop/src. The dialog users actually get is App Management — "wants access to data from other apps" — and it has a different cause. macOS blocks one app modifying another's bundle unless both are signed by the same development team, and installing an update is exactly that: the swap replaces the bundle in /Applications. The builds carry a self-signed certificate with no team identifier, so there is no team to match. This mattered more than a wording nit. The stale note kept describing the symptom of a bug PR #85 had already fixed, so it pointed the diagnosis at the signature and away from the missing team — which is where it went, until the dialog was read literally. The new copy quotes the dialog's own words, because recognition is the entire job of a note shown once, and says it is asked once. That last part is now observed, not assumed: allowing it survived builds 102 to 105, which is what the stable designated requirement predicted. NSUpdateSecurityPolicy is recorded as a dead end in the comment — its AllowProcesses map is keyed by team identifier, so it needs the one thing this build lacks. Removing the dialog for good means a paid Developer ID. Tests now pin the dialog's wording and assert the note does NOT say "unsigned", so this cannot quietly rot back. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
radroid added a commit
that referenced
this pull request
Aug 18, 2026
…ures (#71) The rename is mechanical; the risk is not. Four of the strings involved are load-bearing for something that outlives the merge, and each fails without an error surface: - the build counter is github.run_number, keyed to a WORKFLOW FILENAME, so renaming t3x-release.yml restarts it at 1 against clients sitting at 26 and every one of them skips forever. The issue attributes this hazard to the version string; that part is genuinely safe. The filename is not. - the relay hostname is compiled into builds already on disk, so the old Worker has to serve permanently. The shim proxies rather than redirects: relayClient talks through Effect's HttpClient and treats any non-2xx as bad-status, and redirect behaviour on a live SSE stream cannot be tested against builds already in the field. - a LaunchAgent plist hardcodes scripts/t3x/auto-build-desktop.sh, so the rename stops the nightly build with no log line. Same failure class as #41. - app.setName() sets the safeStorage Keychain service name, so saved environment tokens stop decrypting. Threads are unaffected -- userDataDirName is a hardcoded literal, not derived -- which is why #85 moved nobody's data. Also records the two deliberate displacement edits (APP_BASE_NAME, productName) that break the fork's +N/-0 seam invariant, so a later sync reads them as recorded rather than as drift. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
radroid added a commit
that referenced
this pull request
Aug 18, 2026
…tificate (#71) APP_BASE_NAME T3 Code -> T3 Coil (DesktopEnvironment.ts) productName T3 Code (Alpha) -> T3 Coil (Alpha) (apps/desktop/package.json) bundle id dev.curlycloud.coil -> dev.curlycloud.t3coil signing certificate T3X Code Signing -> T3 Coil Code Signing APP_BASE_NAME is the one that matters: displayName is derived from it, and that reaches app.setName(), the About panel, every window title, the Linux .desktop entry, and — through getAppBranding() — the web UI, which reads the injected value rather than hardcoding one. So renaming one literal renames the app almost everywhere it is computed. Almost. 31 upstream-owned files still say "T3 Code" in body copy ("T3 Code needs the relay client..."). Renaming those means displacement edits on 31 more upstream files for prose, which is a bad trade against the sync cost; left alone deliberately, not missed. Three things that look like they should have moved and must not: - legacyUserDataDirName stays "T3 Code (Alpha)". It names a directory that already exists on disk and is a hardcoded literal, not derived from APP_BASE_NAME. That is why #85 moved nobody's threads and why this does not either. DesktopAppIdentity.test.ts now asserts both spellings a few lines apart, with a comment, because the pair looks like a typo and is not. - branding.test.ts's injected-branding case keeps "T3 Code" fixtures. It asserts that injection WINS over the module constant; matching the fixture to the constant would make it pass whether injection works or not. - resolveDesktopProductName's "T3 Code (Nightly)" is upstream's literal on a branch this fork never reaches, since nothing here builds a -nightly.<d>.<d> version. The bundle id and certificate each invalidate every macOS TCC grant, because the designated requirement names both. Done together so the user pays one round of permission dialogs rather than two. The certificate half is NOT complete in code alone: a new name means a new certificate, so setup-mac-signing.sh --rotate has to run before this merges, and designated-requirement.txt has to be re-recorded from it. What is committed here has the new identifier and the CURRENT leaf hash, which is exactly right until the rotation happens and loudly wrong after it — the release compares that file byte for byte. Also renames the pnpm-lock.yaml importer for the relay directory move in the previous commit; without it `pnpm install --frozen-lockfile` fails, which is how it was caught. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
radroid added a commit
that referenced
this pull request
Aug 18, 2026
The first-update note said the builds were unsigned and to expect screen-recording and automation prompts. All three claims were wrong. They have been signed since #70/PR #85 — verified on the installed 0.0.33-coil.105, whose designated requirement matches the recorded one byte-for-byte and still satisfies itself after an in-app update. The app requests neither screen recording nor automation: there is no desktopCapturer, getDisplayMedia, osascript or Apple Event use anywhere in apps/desktop/src. The dialog users actually get is App Management — "wants access to data from other apps" — and it has a different cause. macOS blocks one app modifying another's bundle unless both are signed by the same development team, and installing an update is exactly that: the swap replaces the bundle in /Applications. The builds carry a self-signed certificate with no team identifier, so there is no team to match. This mattered more than a wording nit. The stale note kept describing the symptom of a bug PR #85 had already fixed, so it pointed the diagnosis at the signature and away from the missing team — which is where it went, until the dialog was read literally. The new copy quotes the dialog's own words, because recognition is the entire job of a note shown once, and says it is asked once. That last part is now observed, not assumed: allowing it survived builds 102 to 105, which is what the stable designated requirement predicted. NSUpdateSecurityPolicy is recorded as a dead end in the comment — its AllowProcesses map is keyed by team identifier, so it needs the one thing this build lacks. Removing the dialog for good means a paid Developer ID. Tests now pin the dialog's wording and assert the note does NOT say "unsigned", so this cannot quietly rot back. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes#70.
The bug, in two commands
macOS keys every permission grant to the app's designated requirement. With no certificate to
name, codesign falls back to the binary's
cdhash, which changes when any byte of the app changes —so every update was a brand-new app to macOS, and Screen Recording, Accessibility, Microphone,
Files & Folders and Local Network were re-requested from scratch every time.
The fix is not "sign it" but "sign it with an identity that does not move", which is why a free
self-signed certificate is enough. It does not have to be trusted by Apple; it has to be the same one
next time.
What landed
scripts/t3x/setup-mac-signing.sh— creates the identity (self-signed, 10 years, in its ownkeychain so
set-key-partition-listcan run non-interactively and no GUI keychain dialog can wedgean unattended build), trusts it, self-verifies by signing a throwaway bundle, and exports the p12
for CI. Idempotent. Prints the exact
sudocommand instead of hanging when there is no terminal.t3x-release.yml— imports the p12 secret on the mac runner and exportsCSC_NAME.auto-build-desktop.sh— picks the same identity up locally, so the release path and the localautobuild produce one identical requirement instead of two.
scripts/t3x/verify-mac-signature.ts(+ 17 tests) — asserts the claim on the.appinside theshipped
.dmg. Fails a changed identity as well as a missing one: a build signed by a differentcertificate is perfectly signed and still costs a full round of dialogs, so the requirement is
pinned in
docs/t3x/mac-signing/designated-requirement.txtand compared byte for byte.docs/t3x/mac-signing-runbook.md— setup, verification, rotation, and what this does not fix.Zero new SEAMS.md rows
#70's plan called for a third signing mode inside
scripts/build-desktop-artifact.ts— a row on a hotupstream file. It turned out to be unnecessary.
CSC_IDENTITY_AUTO_DISCOVERY=falseis only consultedwhen no identity was named:
So exporting
CSC_NAMEaround the existing unsigned build is the whole mechanism. An emptyCSC_NAMEis identical to noCSC_NAME, which is what makes it safe to wire in unconditionally.Verification
different cdhashes) signed with one certificate produce a byte-identical designated
requirement, both
codesign --verify --deep --strictclean.correctly signed
.appinside a.dmg(exit 0, mounts and detaches cleanly), and with--allow-unsigned(exit 0, warns).scriptspackage: 218 tests pass, typecheck and lint clean. Release-workflow YAML parses and thenew steps are ordered correctly.
dialog on the second. That needs a real machine and a real update, and is the next step after merge.
Expect one more round of prompts
The first signed build moves the identity from a cdhash to a certificate, so existing grants no
longer match and macOS asks once more. That install looks exactly like the bug it fixes — the fix
is judged on the second signed install.
Known, separate: the bundle id is shared with upstream's build
Both
/Applications/T3 Code (Alpha).appand upstream'sT3 Code (Nightly).appreportCFBundleIdentifier = com.t3tools.t3code, and TCC stores one row per(service, bundle id). Soswitching between the two apps re-prompts no matter how well either is signed. Documented in the
runbook with the options; not fixed here, because giving the fork its own bundle id means editing
DESKTOP_APP_IDin an upstream-owned file — a real SEAMS row, and one more permission reset.🤖 Generated with Claude Code