Distillation

Date: July 21, 2026

• 🟡 (11:33) Tool result: GitHub Actions runner-images announcements confirmed: Xcode 26.6 becomes default on macOS 26 Tahoe runner image on 2026-07-21; macos-latest label switches to macos-26 in June 2026; macOS 14 Sonoma runners begin deprecation July 6, fully unsupported by Nov 2, 2026.
• 🟡 (11:33) Tool result: macos-26 runner image details — OS macOS 26.4 (build 25E246), Kernel Darwin 25.4.0, Image Version 20260715.0248.1, Node.js 24.18.0, Xcode Command Line Tools 26.6.0.0.1781586589.
• 🟡 [root-cause-found] (11:33) Assistant finalized diagnosis: failing CI run dated 2026-07-21 is the exact day macos-latest's default Xcode flipped to 26.6. Chain: (1) macos-latest silently rolled from macOS 15/Xcode 16 (last green run 2026-06-24) to macOS 26/Xcode 26.6; (2) Xcode 26's notarytool now emits plain-text "Error: inv..." instead of JSON on submit failure; (3) electron-builder 24.13.3's bundled @electron/notarize@2.2.1 does a raw JSON.parse(stdout) and crashes with SyntaxError instead of surfacing Apple's real error message; (4) user's own scripts/notarize.cjs (using newer @electron/notarize 2.5.0) is dead code — electron-builder notarizes internally via its own bundled 2.2.1, never calling the user's script.
• 🟡 (11:34) [decision-made] User answered clarifying question "How do you want to fix the macos-latest → macOS 26 notarization break?" = "Upgrade electron-builder toolchain" (chosen direction going forward).
• 🟡 (11:34) Assistant noted newer @electron/notarize only omits --issuer if appleApiIssuer is not passed, but user's workflow always sets APPLE_API_ISSUER and electron-builder throws if it's missing — relevant only if key turns out to be an Individual key.
• 🟡 (11:34) Tool result: packages/spotlight/package.json (spotlight app) key details — name @spotlightjs/spotlight, version 4.11.6, type module, engines node>=20. devDependencies include electron-builder@^24.13.3, @electron/notarize@^2.5.0, electron@^39.8.5, electron-store@^10.0.1, electron-updater@^6.6.2, typescript/vite/vitest via catalog. Scripts include build:mac using ./electron-builder.cjs.
• 🔴 (11:35) User stated their Apple API key is a Team key (not Individual) — confirmed answer to assistant's question, replacing prior unknown.
• 🟡 (11:35) Assistant revised analysis after Team-key confirmation: Individual-key --issuer omission logic (in @electron/notarize 3.x) is not needed since Team keys still pass --issuer normally; question shifts to what electron-builder 26.15.7 vs 27-alpha actually bundles.
• 🟡 (11:35) Tool result: npm dist-tags for electron-builder — latest: 26.15.3, next: 27.0.0-alpha.5, v26: 26.15.7. Recent versions listed 26.3.0 through 26.15.7 and 27.0.0-alpha.0 through alpha.5.
• 🟡 [root-cause-found] (11:36) Tool result/code inspection: @electron/notarize@2.5.0 (bundled by electron-builder 26.15.7) wraps notarytool JSON.parse in try/catch (notarytool.js lines 138-141) and throws "Failed to notarize via notarytool. Failed with unexpected result: \n\n${rawOut}" instead of crashing with an unhandled SyntaxError — meaning upgrading to electron-builder 26.15.7 would at least surface Apple's real error message. Only electron-builder 27 (alpha) bundles @electron/notarize@3.1.1 (the Individual-key/Xcode-26-aware version), which is not required since the key is confirmed Team type.
• 🟡 (11:36) Tool result: osx-sign@1.3.3 (bundled by electron-builder 26.15.7) exposes dist/cjs/index.js — confirmed CJS-safe, ruling out repeat of the prior osx-sign@1.0.5 exports-map breakage previously noted by the user.
• 🟡 [ruled-out-hypothesis] (11:37) Assistant searched GitHub electron/notarize issues for "notarytool invalid Xcode 26" — only 2 old closed/unrelated issues (#88 "--keychain argument not necessary", #26 "Successful notarization but app no longer launches"), no matching upstream reports found; low relevance signal.
• 🟡 (11:37) Assistant's current leading hypothesis: with a confirmed valid Team key, Xcode 26's notarytool may be stricter about PEM/key format than before; user's CI pipeline extracts the key via jq .private_key -r > /tmp/apple_key.pem, which could produce a malformed PEM (e.g. unexpanded \n) that old notarytool tolerated but new notarytool rejects with "Error: invalid private key" / "Error: invalid key".
• 🟡 (11:37) Assistant wrote a draft plan file recording the diagnosis and open item (tool confirmed "Wrote file successfully"; no path specified in output).
• 🟡 (11:37) Assistant reiterated request for the user to paste the base64-encoded Apple API key bundle, to decode only into /tmp/opencode/ (never the repo) and verify: presence/match of issuer_id, key_id, private_key fields; that the PEM parses as a valid P-256 key via openssl ec/pkcs8; that key_id matches 3RC4SAF8T6 and issuer matches 69a6de81-... .
• 🟡 (11:37) Assistant presented user with two options: (1) hold for the key bundle to diagnose the exact PEM/format issue before making changes, or (2) proceed now to finalize the electron-builder 26.15.7 upgrade plan and let the next CI run reveal Apple's real underlying error message.