macOS: updates keep their permissions, and selection conversion works

[iga566-gh]

macOS: updates keep their permissions, and selection conversion works

This is the macOS cluster from a fork where I chased issue #42's tail to the end on an M1 Pro (macOS 26.5), with repeated clean-machine end-to-end runs — fresh TCC, fresh keychain, fresh app data: install → grant → update. 21 commits, each carrying its measurement in the message.

Updates and permissions

• The relaunch race from macOS: every self-update invalidates Accessibility and Input Monitoring, and "Ask macOS now" cannot restore them #42 is the Settings window surviving the swap. It is a subprocess of the same executable; it outlives the main process, so install.sh's open finds the app "already running" and merely activates the orphaned old-version window — the updated build never starts. The main process now takes every child window along on the update hand-off and on Quit, and the pane's new Restart button starts the bundle from a detached helper after the settings process exits, for the same reason.
• Whole-bundle replacement loses TCC grants even under a stable signature. Measured with the same identity on both sides: an in-place content change plus re-sign keeps Accessibility and Input Monitoring; the mv-aside-mv-in dance loses them. The installer now swaps Contents inside the bundle and never moves the .app itself (same rollback, Contents.old inside the bundle). The .app.new Spotlight sighting goes away with it.
• Grants can survive updates today, without a Developer ID. [updates].local_signing_identity names a keychain identity; the installer re-signs the swapped bundle with it, and TCC keys the grants to certificate + identifier. A Setup step creates the identity in one click — system LibreSSL, PEM-by-PEM import (security(1) refuses LibreSSL's PKCS#12), codesign pre-authorised, and the one-time keychain password prompt triggered right at the button, not mid-update where it reads as malware. With no identity configured, the installer drops the two stale TCC records after a successful swap instead, so the Ask buttons genuinely raise the system prompts right after an update.
• Smaller, same series: check_and_stage no longer discards a staged version ahead of the feed; the identity probe lists without -v (which hides self-signed identities and had the pane offering to create a duplicate); Ask always opens the exact Settings pane; on current macOS one Accessibility grant satisfies the Input Monitoring probe too, so the pane folds the second Ask into "covered by the grant above" while keeping the button for the older systems this project supports; a notifications Setup step points at the right pane and warns when Focus is silencing banners; the relaunch open retries once.

Selection conversion on macOS

• send_chord exists now, so the selection_support() gate is gone: modifiers travel as flags on the key events (how macOS matches menu shortcuts — nothing is left held), with an SC-1→Apple reverse keycode table that refuses what it cannot name, and the copy/paste chords pick Cmd on macOS in the one constant that owns them. Validated live: conversions both ways, clipboard restored.
• What it took to trust it: the tap watches caret-moving clicks now — the one listener of the three that didn't, so the switch-last stash lived out its full TTL and the hotkey backspaced through an active selection; transliterate_to refuses text with no letter the source layout owns (a wrong-direction press mangled exactly the characters sitting on different punctuation across layouts — a ю drifting through . to / and never back); backspaces are paced by their own tap echoes instead of a timer (Spotlight drops timer-paced deletes and keeps the word's first letter standing); the notification sender registers its bundle id exactly once before the first toast (otherwise mac-notification-sys resolves an app literally named use_default and macOS opens a modal application chooser; a second set_application is a hard error that kills every later toast); and [engine].hold_keys exposes the key gate as a config knob — default off, per the project's documented latency stance; the knob is the new part.

Windows and Linux paths are untouched. Tests extend the existing suites; all green (poltertype-update 49, poltertype-input 39, plus the app and core suites).

[vstrelnikof]

Merged, and shipped in v0.30.0. Thank you — twenty-one commits each carrying its own measurement is the kind of PR that can be reviewed honestly without the hardware, and the diagnosis in #42 that started it saved the work twice over.

Two changes on the way in, both mine, neither touching what the branch was for:

CI. NOTIFICATIONS_PANE_URL was declared without the #[cfg(target_os = "macos")] its two neighbours in the same file carry. Invisible on a Mac; everywhere else it is an unused constant and -D warnings makes that a build failure — which is exactly the shape the run had, check (macos-latest) green and Linux and Windows both red. Plus cargo fmt --all over twelve drifted spots.

The chord constants. COPY_CHORD and PASTE_CHORD grew a cfg!(target_os = "macos") in poltertype-core, and that crate holds no platform conditional of any kind — it is a rule the project checks with a grep, and it was still true right up to this branch. Your reasoning for keeping the split in the constants rather than in the emitters is right and is kept verbatim in the comment; only the address changed. They now live in poltertype-input, one of the crates allowed to know which OS it is on, and the engine re-exports them.

One thing your branch did not fix and v0.30.0 does, because it would have bitten the macOS selection path too: SystemClipboard opened an arboard handle per write and dropped it on return, and both X11 and Wayland serve the clipboard from the owning process — so every write destroyed itself. See #51.