macOS: every self-update invalidates Accessibility and Input Monitoring, and "Ask macOS now" cannot restore them

[iga566-gh]

On macOS every self-update costs the user both permissions, and the "Ask macOS now" button cannot bring them back.

Environment: MacBook Pro 14" (M1 Pro), macOS 26.5.2, PolterType installed to /Applications,
updated in place through Restart-to-update, 0.19.0 → 0.24.0.

What happened. After the update the Setup pane showed Needs you for both Accessibility and
Input Monitoring, while both were still switched on in System Settings — the entries were there,
listed and enabled. Pressing Ask macOS now did nothing: no system prompt appeared, for either
permission. Quitting and relaunching did not help. The only thing that worked was removing
PolterType from both lists with the minus button and adding it again.

Why it happens. The app is ad-hoc signed:

$ codesign -dv --verbose=2 /Applications/poltertype.app
Identifier=org.poltertype.app
Signature=adhoc
TeamIdentifier=not set

For an ad-hoc signed bundle, TCC keys the grant to the code directory hash, not to a stable
identity. The updater replaces the bundle, the hash changes, and the existing grant no longer
matches the running binary — so the app is denied while the toggle still reads "on". And because a
record for that bundle identifier already exists, macOS treats the permission as already decided
and suppresses the prompt, which is why the button appears dead: IOHIDRequestAccess and
AXIsProcessTrustedWithOptions only raise the dialog when there is no prior record.

Consequences as a user. Self-update is the feature that made the app pleasant to keep current —
and right now every update silently disarms it. The failure is quiet: the tray icon is there, the
toggles say "on", and nothing gets corrected until you notice and go re-grant by hand. With
releases landing twice a day this is a real tax.

What would fix it properly. Signing with a Developer ID and notarizing: TCC then keys the grant
to the team identifier plus bundle identifier, and it survives bundle replacement — which is exactly
how every other menu-bar utility manages to update without asking again. I understand that means a
paid Apple Developer account, so until that is possible, two smaller things would help a lot:

1. Detect the state and say it plainly. The app can tell "permission record exists but we are
   denied" from "no record at all". In the first case the Setup pane should not offer a button that
   cannot work; it should say: remove PolterType from this list, then press Ask again — and ideally
   open that exact pane.
2. Warn before updating. If the updater knows the bundle swap will invalidate the grants, the
   Restart-to-update button is the right place to say so.

Happy to test any of this on Apple Silicon — this machine reproduces it every time.

[vstrelnikof]

Your diagnosis is right, and it saved the work — v0.25.0 does both of
the smaller things you asked for.

IOHIDCheckAccess can tell "asked, and the answer is on record" from
"never asked", which is exactly the distinction the pane needed: a
recorded denial is now a state of its own that says to remove
PolterType from the list and add it back, with a button that opens that
pane, instead of offering an Ask that cannot raise a dialog.
AXIsProcessTrusted cannot answer that question at all, so
Accessibility follows Input Monitoring — TCC is asked for both at the
same moment, so a record for one means a record for the other. The
Updates card now says what an update will cost before you take it.

There is no Mac here, so all of that is compiled and not run. If you
would try it on the M1 Pro after the next update and say whether the
Setup pane tells you the right thing, I will close this on your word.
The Developer ID signature is the actual fix and is tracked — it needs
an Apple developer account we do not have yet.

[iga566-gh]

Tried it on the M1 Pro across two updates today, 0.24.0 → 0.26.0 → 0.28.0. The permissions were
invalidated again, exactly as before — that part needs the Developer ID and I did not expect
otherwise. Everything you shipped around it works: the Setup pane reports the recorded-denial state
instead of offering an Ask that cannot raise a dialog, and both buttons now behave — Check
again re-reads the real state, and Ask opens the correct System Settings pane straight away.
Removing PolterType from both lists and adding it back is still the fix, but it is now a guided
minute rather than a hunt.

So the two smaller things you shipped work as intended on this machine. Whether you close this or
keep it open for the signature is your call — the underlying cause is untouched, and every update
still costs both permissions.

One cosmetic thing seen during the swap, not worth its own issue: while install.sh runs, the
bundle exists as poltertype.app.new and Spotlight surfaces it under that name; the relaunched
window was also still the old version's until I quit and started it again. Nothing was left behind —
/Applications/poltertype.app is 0.28.0 and there is no .new on disk.

[vstrelnikof]

Thanks for running it across two updates — that is exactly the evidence the Setup pane changes needed.

Keeping this open. The cause is the missing Developer ID, not anything in the code: without it macOS identifies the app by the hash of its own bytes, so every update is new software to it. Closing would say we had solved it.

The poltertype.app.new note is worth its own look — the relaunched window being the old version means the swap and the relaunch raced, which is ours to fix rather than Apple's.

[vstrelnikof]

v0.30.0 ships your PR (#55) — thank you, it is a lot of careful work and it carried its measurements with it.

Two things from it land here. The relaunch race is fixed: the Settings window is a subprocess that outlived the swap, so open found the app already running and just activated the old window; child windows now come along on the update hand-off and on Quit. And the installer swaps Contents inside the bundle instead of moving the .app aside, which retires the poltertype.app.new Spotlight was surfacing.

[updates] local_signing_identity is the interim answer to the permissions themselves: name a keychain identity, the installer re-signs the swapped bundle with it, and TCC keys the grants to certificate plus identifier instead of to the bundle hash. Left empty, updates stay ad-hoc and the installer now clears the two stale TCC records after a swap, so Ask can raise a real prompt again.

Developer ID signing is coming soon — that is the actual fix, and it is what closes this issue. Keeping it open until then.