ToneGuard

A native, local-first macOS MVP that watches the focused accessibility text field, detects toxic language in real time, and shows a transparent highlight over the matching words. No text leaves the device.

Run

chmod +x Scripts/build-app.sh
pkill -x ToneGuard 2>/dev/null || true
Scripts/build-app.sh
open -n dist/ToneGuard.app

ToneGuard prompts for Accessibility permission immediately on launch. Grant it in System Settings → Privacy & Security → Accessibility; it will appear as ToneGuard because it runs as a native .app bundle. Click inside an editable field in another app and type a configured term such as idiot or hate.

swift run ToneGuard remains useful for development, but is not the recommended way to request Accessibility access because it does not launch a stable .app bundle identity.

Diagnostics

The menu-bar command Preview overlay (5 seconds) draws a large red rectangle without reading any other app. If it is not visible, the macOS overlay window is being blocked before text-range geometry is involved. Diagnostic metadata (never typed text) is also written to:

~/Library/Application Support/ToneGuard/Logs/toneguard.log

MVP controls

Choose Detection Settings from the menu-bar popover to enable categories, adjust sensitivity, or add local custom blocked words. A detection includes its category, confidence, and a short explanation. These settings are stored only in your local macOS user defaults.

ToneGuard also uses macOS's built-in, on-device NaturalLanguage sentiment model to flag strongly negative sentences that do not contain an exact blocked word. Those detections highlight the full sentence; direct rule matches remain word-level highlights.

Privacy

ToneGuard has no networking code or remote model calls: detection rules, custom words, and the system-provided sentiment model run only on the Mac. The main app must remain outside the restrictive App Sandbox because macOS uses that sandbox to block the cross-app Accessibility API ToneGuard needs. A production-grade network guarantee therefore requires a separately sandboxed, no-network helper or an outbound firewall policy; it cannot coexist with direct cross-app Accessibility in one sandboxed process.

Validation

The detector has unit tests in Tests/ToneGuardTests. Run them in Xcode (or with swift test on a full Xcode installation). Manual acceptance checks: grant Accessibility access to ToneGuard.app, then verify the terms idiot, shut up, and a custom blocked word in TextEdit, Notes, and a browser editor. Some apps intentionally do not expose text bounds through Accessibility; ToneGuard will continue monitoring without drawing an overlay in those editors.

Notes

• macOS only exposes text from apps that support the Accessibility API. Secure text fields and some third-party apps intentionally do not expose their contents.
• Terminal and iTerm transcripts are intentionally skipped in this MVP because macOS reports their entire scrollback as a single Accessibility text region.
• The MVP uses a small local rules engine, deliberately kept behind ToxicityDetector so it can be replaced by a bundled Core ML model later without changing the UI or accessibility pipeline.
• The Swift package makes it easy to develop without an Xcode project. For signing and distribution, open the folder in Xcode and use a Developer ID / sandbox configuration with the Accessibility entitlement workflow.