SHELL-06: Input Monitoring TCC denial HUD banner + System Settings deep link missing #88

Closed
opened 2026-05-12 19:31:42 +00:00 by KofTwentyTwo · 1 comment
KofTwentyTwo commented 2026-05-12 19:31:42 +00:00 (Migrated from github.com)

Summary

SHELL-06 requirement: "Input Monitoring TCC denial surfaces a HUD banner with System Settings deep link; local-monitor-only degraded mode falls back when global monitor is denied."

Today: Settings window shows Input Monitoring status with a System Settings deep link (`App/Settings/SettingsView.swift:189-220`), but there is no HUD banner that surfaces when global monitor silently no-ops on Input Monitoring denial. The user has to know to open Settings to discover the issue.

Per CLAUDE.md: "Global monitor silently no-ops on Input Monitoring denial — probe via `IOHIDRequestAccess(kIOHIDRequestTypeListenEvent)`, surface a HUD banner + System Settings deep link, and fall back to local-monitor-only degraded mode."

Evidence

  • `App/Settings/SettingsView.swift:189-220` — Settings UI exists; banner does not.
  • `packages/Shell/Sources/Shell/HIDAccessProbe.swift` — probe surface exists.
  • REQUIREMENTS.md SHELL-06: Pending.
  • No `BannerCoordinator.enqueue(.inputMonitoringDenied)` site in production.

Gap classification

"missing UI surface" — banner queue exists (`HUDBannerCoordinator`), probe exists, the producer/enqueue site is missing.

Recommended action

File standalone (no M-phase; v1 requirement gap). Pattern:

  1. Probe `IOHIDRequestAccess(kIOHIDRequestTypeListenEvent)` at `installShell`.
  2. If denied, enqueue a HUD banner via `bannerCoordinator?.enqueue(.inputMonitoringDenied(deepLink: ...))` with a system-settings deep-link action.
  3. Fall back to local-monitor-only mode (already supported by `NSEvent.addLocalMonitorForEvents`).
  4. Re-probe on app foreground; clear banner when re-granted.

Cross-references

  • REQUIREMENTS.md SHELL-06 (Pending)
  • CLAUDE.md "Hotkey hygiene" section
## Summary SHELL-06 requirement: \"Input Monitoring TCC denial surfaces a HUD banner with System Settings deep link; local-monitor-only degraded mode falls back when global monitor is denied.\" Today: Settings window shows Input Monitoring status with a System Settings deep link (\`App/Settings/SettingsView.swift:189-220\`), but there is no HUD banner that surfaces when global monitor silently no-ops on Input Monitoring denial. The user has to know to open Settings to discover the issue. Per CLAUDE.md: \"Global monitor **silently no-ops on Input Monitoring denial** — probe via \`IOHIDRequestAccess(kIOHIDRequestTypeListenEvent)\`, surface a HUD banner + System Settings deep link, and fall back to local-monitor-only degraded mode.\" ## Evidence - \`App/Settings/SettingsView.swift:189-220\` — Settings UI exists; banner does not. - \`packages/Shell/Sources/Shell/HIDAccessProbe.swift\` — probe surface exists. - REQUIREMENTS.md SHELL-06: Pending. - No \`BannerCoordinator.enqueue(.inputMonitoringDenied)\` site in production. ## Gap classification \"missing UI surface\" — banner queue exists (\`HUDBannerCoordinator\`), probe exists, the producer/enqueue site is missing. ## Recommended action File standalone (no M-phase; v1 requirement gap). Pattern: 1. Probe \`IOHIDRequestAccess(kIOHIDRequestTypeListenEvent)\` at \`installShell\`. 2. If denied, enqueue a HUD banner via \`bannerCoordinator?.enqueue(.inputMonitoringDenied(deepLink: ...))\` with a system-settings deep-link action. 3. Fall back to local-monitor-only mode (already supported by \`NSEvent.addLocalMonitorForEvents\`). 4. Re-probe on app foreground; clear banner when re-granted. ## Cross-references - REQUIREMENTS.md SHELL-06 (Pending) - CLAUDE.md \"Hotkey hygiene\" section
KofTwentyTwo commented 2026-05-13 11:52:15 +00:00 (Migrated from github.com)

Closed by v0.1 cluster merges on 2026-05-13. Develop now at a8c7f1a0.

Closed by v0.1 cluster merges on 2026-05-13. Develop now at `a8c7f1a0`.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: KofTwentyTwo/Jarvis#88