Report Secure Keyboard Entry as itself, not as an Input Monitoring denial - #9
Merged
Conversation
… the cause Secure Keyboard Entry produces the same kIOReturnNotPermitted as a revoked Input Monitoring grant, and both paths blamed Input Monitoring — sending people to a settings pane where the switch was already on (issue #2). - PermissionProbe.secureInput(): IsSecureEventInputEnabled plus the holder pid the window server records on IOConsoleUsers, resolved to an app name. A dead holder is named as a stale claim with the logout remedy. - CodexError.accessDenied text is now neutral; attribution happens where the error surfaces, probe in hand. - publishDeviceStatus: new secureInputBlocked device status on the open path, checked after the grant (the durable problem wins). - The paint-failure log names Secure Input and its holder on the write path — the mid-session engage the periodic poll never covered. Hardware-validated on a Codex Micro: paint succeeds normally, fails with the neutral text while a scratch process holds Secure Input — open succeeded, write refused, the exact uncovered path from the report. Fixes #2 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…h that is not there hookCommandPath appended Contents/MacOS to bundleURL, which is the .app for an installed copy but the enclosing folder for a bare swift-build executable — so a debug build's Repair wired every session to a path that does not exist, silently, since the helper exits 0 by design. Now the path derives from executableURL's parent (correct in both layouts), audit checks existence before path equality (stalePath could never fire for our own path), and install refuses a command that is not an executable file. Co-Authored-By: Claude Fable 5 <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 free
to 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.
Fixes #2.
When another process holds Secure Keyboard Entry, the pad's key events stop arriving and the app blamed Input Monitoring — a permission that was in fact granted, sending the user to reset the wrong thing (issue #2's five-hour trail).
PermissionProbe.secureInput()readsIsSecureEventInputEnabled()plus the holder pid the window server records in the IORegistry, resolved to an app name (NSRunningApplication, with apsfallback for CLI processes).DeviceStatusgains a dedicated case so the popover and log say "Secure Keyboard Entry is on (held by )" instead of misreporting a granted permission as denied.accessDeniednow disambiguate first.Hardware-validated on the pad: probe verified against a real Secure Input holder, paint round-trip confirmed while engaged. 470/470 tests after rebasing onto current main.
🤖 Generated with Claude Code