Labels: bug, UX, good first issue, GSSoC 2026
Title: [Bug]: Daemon silently fails or produces cryptic logs when Accessibility permission is not granted — no user-facing guidance provided
Body:
Summary
When a user installs ClipWallet and launches it via clipwallet install without having granted Accessibility permission in System Settings, the daemon fails to intercept hotkeys. However, the failure mode is silent — the daemon continues running, logs no helpful error, and the user has no indication of what went wrong.
Steps to Reproduce
Install ClipWallet via the documented steps.
Skip the "Grant Accessibility Permission" step.
Run clipwallet install and clipwallet status.
Attempt to use any hotkey combination.
Observe: nothing happens; no error is shown in out.log that specifically tells the user to grant Accessibility access.
Expected Behaviour
On startup, the daemon should:
Check whether Accessibility permission is granted via the macOS AXIsProcessTrusted() API.
If not granted, emit a clear, human-readable warning in both out.log and stderr.
Optionally, open System Settings → Privacy & Security → Accessibility automatically, or print the exact path to navigate to.
Current Behaviour
The daemon starts but hotkeys silently fail. A new user would have no idea why their hotkeys are not working.
Proposed Fix
In the daemon startup code (likely in src/main.rs or the CGEventTap initialisation), add an early check:
rust
// Pseudo-code — actual API call via objc/core-foundation FFI
if !ax_is_process_trusted() {
eprintln!(
"[ClipWallet] ERROR: Accessibility permission not granted.\n
Hotkey interception will not function.\n
Please go to: System Settings → Privacy & Security → Accessibility\n
and add 'clipwallet' to the allowed list, then restart the daemon."
);
// Log to ~/.clipwallet/logs/err.log as well
}
This is a high-impact, low-risk change that will dramatically improve the new user experience and reduce support questions.
I would like to implement this fix. Please assign this issue to me.
Labels: bug, UX, good first issue, GSSoC 2026
Title: [Bug]: Daemon silently fails or produces cryptic logs when Accessibility permission is not granted — no user-facing guidance provided
Body:
Summary
When a user installs ClipWallet and launches it via clipwallet install without having granted Accessibility permission in System Settings, the daemon fails to intercept hotkeys. However, the failure mode is silent — the daemon continues running, logs no helpful error, and the user has no indication of what went wrong.
Steps to Reproduce
Install ClipWallet via the documented steps.
Skip the "Grant Accessibility Permission" step.
Run clipwallet install and clipwallet status.
Attempt to use any hotkey combination.
Observe: nothing happens; no error is shown in out.log that specifically tells the user to grant Accessibility access.
Expected Behaviour
On startup, the daemon should:
Check whether Accessibility permission is granted via the macOS AXIsProcessTrusted() API.
If not granted, emit a clear, human-readable warning in both out.log and stderr.
Optionally, open System Settings → Privacy & Security → Accessibility automatically, or print the exact path to navigate to.
Current Behaviour
The daemon starts but hotkeys silently fail. A new user would have no idea why their hotkeys are not working.
Proposed Fix
In the daemon startup code (likely in src/main.rs or the CGEventTap initialisation), add an early check:
rust
// Pseudo-code — actual API call via objc/core-foundation FFI
if !ax_is_process_trusted() {
eprintln!(
"[ClipWallet] ERROR: Accessibility permission not granted.\n
Hotkey interception will not function.\n
Please go to: System Settings → Privacy & Security → Accessibility\n
and add 'clipwallet' to the allowed list, then restart the daemon."
);
// Log to ~/.clipwallet/logs/err.log as well
}
This is a high-impact, low-risk change that will dramatically improve the new user experience and reduce support questions.
I would like to implement this fix. Please assign this issue to me.