Security & Kernel Isolation

• The Reality: The system-default Cmd+Tab switcher is handled deep within macOS's WindowServer process. The only reliable way for a third-party app to intercept Cmd+Tab keystrokes, prevent the native UI from appearing, and substitute custom behavior is by installing an active, intercepting CGEventTap (specifically a kCGHIDEventTap location tap). This is a fundamental OS limitation: no public API exists to override or block the built-in app switcher without it.
• The Implication: Because CGEventTap is required, WOS must request the Input Monitoring permission (and in many cases, it aligns with or prompts for Accessibility access in System Settings > Privacy & Security). This is the same permission required by many trusted third-party tools, including:
  • Remote desktop apps like AnyDesk and TeamViewer (for keyboard/mouse control),
  • Keyboard customizers like Karabiner-Elements,
  • Gesture and automation utilities like BetterTouchTool,
  • Productivity enhancers like Quicksilver, LaunchBar, Alfred or Raycast (for global hotkeys),
  • And automation platforms like Keyboard Maestro.

These apps all need low-level event access to deliver their core functionality.

The "Zero-Network" Kernel Guarantee

Rather than relying on generic app entitlements, WOS initializes its own kernel jail (Seatbelt profile) immediately upon startup. This is the same underlying technology that powers the macOS App Sandbox, but we've tuned it to allow the performance you expect while enforcing a hard network blackout.

This self-imposed jail enforces absolute network isolation at the kernel level:

• Hard Deny on Network Sockets: The WOS process is physically barred from opening any outbound or inbound connections by the XNU kernel.
• The "Switching Bridge": We punch a precise, auditable hole in this jail that allows only one thing: sending AppleEvents to verified browser bundles (Chrome, Firefox, Safari, etc.) for tab switching.

This is mandatory access control: even if the app reads sensitive data, it physically cannot exfiltrate it. No background phoning home, no secret telemetry, no remote leaks. Zero network access means zero exfiltration.

Every file WOS is allowed to write

There are exactly three writable directories. Each one is enumerated in main.swift and compiled into the binary at startup. Nothing else on disk is writable.

Path	What's in it	Authorizing rule
~/Documents/WOS-Exports/	Tab Therapy exports (.txt, .html, browser bookmarks)	2b
~/Library/Application Support/WOS/	recent_files.json (Recent Files history) and memory_bank.md (Memory Bank — user-saved Markdown snippets)	2b
~/Library/Preferences/ & ~/Library/Caches/com.agentic.wos/	NSUserDefaults (shortcut bindings, HUD prefs) and UDS socket files for the VS Code tab bridge	2c

Every file the WOS app ever creates is one of the above. None of them leave your machine — the network blackout makes that impossible.

WOS cannot:

• Write to your Desktop, Downloads, iCloud Drive, or any other folder — the kernel physically blocks it.
• Modify any file outside the paths above — including any document, photo, or browser profile.
• Write to system directories — no modification of /Applications, /Library, or any system path.

Memory Bank — the same rule, no new sandbox primitives

When we added Memory Bank we deliberately placed its Markdown file inside the existing ~/Library/Application Support/WOS/ directory rather than open a new path. Changing the kernel sandbox profile is delicate — every rule has to be justified, audited, and reproducible from the shipped binary — so adding a feature should reuse already-approved primitives whenever possible.

Result: the new "save snippet to wiki" capability shipped with zero changes to the SBPL profile. The same kernel rule that authorized recent_files.json in v0.1.853 authorizes memory_bank.md today. You can verify this against the running binary with one command — see "Verify It Yourself" below.

Read Access: What WOS Can See

WOS requires read access to function. Specifically, it reads:

• Application bundles (/Applications/) - to fetch app icons displayed in the switcher.
• System frameworks (/System/, /usr/lib/) - required by macOS for any app to run.
• User home directory (/Users/) - browser profile metadata (tab titles, URLs) via AppleScript.

The critical point: even though WOS can read browser metadata, it cannot exfiltrate it. With zero network access and only a single writable directory (which you can inspect at any time), there is no viable path for data to leave your machine.

Verify It Yourself

Try writing outside the allowed folder (this will be blocked by the kernel):

# WOS internally cannot do this — the kernel denies it:
# write to ~/Desktop/ → DENIED
# write to ~/Downloads/ → DENIED
# write to ~/Documents/anything-else/ → DENIED
# write to /Applications/ → DENIED
# write to ~/Library/Application Support/SomeoneElse/ → DENIED
#
# Only these are ALLOWED ✓
# ~/Documents/WOS-Exports/         (Tab Therapy exports)
# ~/Library/Application Support/WOS/ (recent_files.json, memory_bank.md)
# ~/Library/Preferences/           (NSUserDefaults — shortcut bindings, etc.)
# ~/Library/Caches/com.agentic.wos/ (UDS sockets, ephemeral caches)

Reproduce the file-write rules from the shipped binary:

strings /Applications/WOS.app/Contents/MacOS/WOS | grep -E "Application Support/WOS|WOS-Exports|Library/Preferences|Library/Caches"

Monitor sandbox denials in real-time:

log stream --predicate 'sender == "Sandbox" AND eventMessage CONTAINS "WOS" AND eventMessage CONTAINS "deny"'

Inspect what WOS has actually written (these are the only files it ever creates):

ls -la ~/Documents/WOS-Exports/  ~/Library/Application\ Support/WOS/

Dual-Layer Privacy Guard

• Metadata Privacy: WOS natively respects "Transient" and "Concealed" markers from apps like 1Password, Bitwarden, and Apple Keychain. If an app tells the OS "this is a secret," WOS never even reads it.
• Entropy & Shape Detection: For "raw" copies from a terminal or source code, WOS scans for high-entropy tokens (API keys, JWTs) and common secret prefixes (password=, bearer , api_key=).
• Zero Storage: These detections happen in real-time. If a secret is detected, it is immediately discarded before touching the history database or the UI.
• Jump to File Isolation: The `Cmd+Shift+G` selection retrieval uses a transient "Copy Trick" that is isolated from the long-term clipboard monitor. Captured text is used only for path detection and is never indexed or stored in your history.

(version 1)
(deny default)

;; 1. ALLOW: Critical System Access
(allow file-read*
       (subpath "/Applications")
       (subpath "/System")
       (subpath "/usr")
       (subpath "/private/var/db/dyld"))

;; 1b. ALLOW: Subprocess-spawn fundamentals (so osascript children
;; complete dyld init).
(allow file-read*
       (literal "/")
       (subpath "/dev")
       (subpath "/etc")
       (subpath "/var")
       (subpath "/private/var")
       (subpath "/private/etc")
       (subpath "/Library"))

;; 2. ALLOW: User-Specific Read Access (Browsers + Icons)
(allow file-read*
       (subpath "/Users"))

;; 2b. ALLOW: Write access — the only two filesystem locations WOS writes to.
;;     ~/Documents/WOS-Exports           → Tab Therapy exports
;;     ~/Library/Application Support/WOS → recent_files.json (Recent Files)
;;                                         memory_bank.md     (Memory Bank)
(allow file-write*
       (subpath "$HOME/Documents/WOS-Exports")
       (subpath "$HOME/Library/Application Support/WOS"))

;; 2c. ALLOW: NSUserDefaults / cfprefsd + caches for our own bundle only.
(allow user-preference-read user-preference-write
       (preference-domain "com.agentic.wos"))
(allow file-write*
       (subpath "$HOME/Library/Preferences")
       (subpath "$HOME/Library/Caches/com.agentic.wos"))

;; 3. ALLOW: "The Automation Bridge"
(allow appleevent-send)

;; 3b. ALLOW: LaunchServices "open application" (lsopen)
;; Without this, Quick Search's App Launcher cannot cold-launch a
;; non-running app. Strictly local IPC — does not undermine (deny network*).
;; Gatekeeper, notarization, and quarantine still gate every launched app.
(allow lsopen)

;; 4. ALLOW: UI Elements & Graphics
(allow iokit-open)
(allow mach-lookup)
(allow mach-register)
(allow sysctl-read)
(allow signal (target self))
(allow process-exec)
(allow process-fork)

;; 5. DENY: Network Blackout
(deny network*)

A note on (allow lsopen)

This rule lets WOS ask launchservicesd to open another app — exactly what happens when you press Enter on an "App Launcher" result in Quick Search. It is the narrowest primitive Apple's sandbox profile language offers for that capability, and it does not weaken the headline guarantees:

• Network blackout intact. lsopen is local IPC, not a network primitive. (deny network*) still prevents WOS from opening any socket.
• Gatekeeper / notarization still gate launches. launchservicesd enforces these before honouring an open request — WOS cannot launch an unsigned or unnotarized binary through this path.
• Launched apps don't inherit WOS's sandbox. They start fresh under launchd with their own (or no) profile. WOS's sandbox does not leak to children.
• No privilege escalation. Launched apps run as the same user, with the same TCC/Authorization state. lsopen cannot request root.

A compromised WOS could already script every running app via (allow appleevent-send); (allow lsopen) only adds the ability to ask for new app launches — and only ones LaunchServices itself approves.

However, no single boundary is 100% impervious to every conceivable leak forever. Sophisticated (and typically highly targeted or resource-intensive) side channels could theoretically still exist:

• Local-only covert channels: e.g., subtly modulating disk writes, file timestamps, CPU usage patterns, or other observable local artifacts that another malicious process on the same machine could monitor and decode to extract small amounts of data over time.
• Inter-process leaks within allowed sandbox boundaries: if the sandbox profile inadvertently permitted risky Mach ports, XPC connections, or shared memory regions that could shuttle data to a non-network-capable but colluding local process (WOS maintains an extremely minimal profile to reduce this risk).
• Sandbox escape prerequisite: if an attacker first exploits a separate vulnerability to break out of the sandbox (via kernel bugs, misconfigurations, or exploit chains), then standard exfiltration paths could reopen. Historical macOS sandbox escapes have occurred.

1. Tap Scoping and Key Discarding

We publicly document our CGEventTap filter logic. By filtering inside the synchronous C-level callback and dropping anything that isn't 0x30 (Tab) or 0x37 (Command), we ensure alphanumeric keys never reach Swift's higher-level logic.

2. Reproducible Builds

Proving that the binary you download is byte-for-byte identical to the open-source code on GitHub. This eliminates the "supply chain" trust variable.

3. Zero-Trust Verification Method: "Proof-of-Behavior" (PoB) Protocol

• Runtime Auditor: Separate binary (switcher-auditor) runs outside sandbox, monitors main app via osquery + EndpointSecurity framework (macOS 13+).
• Syscall Whitelist: Auditor enforces exact syscalls (e.g., CGWindowListCopyWindowInfo OK; CGEventCreateKeyboardEvent BLOCK/ALERT).
• Cryptographic Proof:
  • Main app generates Merkle proofs of executed functions (using libbpftrace or eBPF for traces).
  • Signs with app's hardware-bound key (Secure Enclave/TPM).
  • Auditor verifies + posts to user-controlled blockchain/notary (e.g., Apple Notary + IPFS).
• User Ritual: On launch, scan QR code with iPhone which verifies notary proof. This shows "Zero logs emitted (proof #abc123)".
• Falsifiable Test: Built-in "poison pill". Type a fake password in test mode and the auditor proves no network/AX events fired.

Unlike App Store apps that rely on entitlements (like com.apple.security.network.client), WOS uses a custom kernel Seatbelt profile applied at startup via sandbox_init(). This is a fundamentally different, and more transparent, approach:

• Fully human-readable - the profile is a plaintext SBPL string embedded directly in the source code (main.swift).
• Published openly - reproduced in full on this page and on GitHub. No reverse-engineering needed.
• Verifiable in the binary - you can extract and inspect the profile string from the compiled app.
• Not entitlement-based - entitlement checks (like codesign --entitlements) won't show the sandbox rules because WOS bypasses that system entirely in favor of a stricter, self-imposed kernel jail.

1. Confirm Sandboxing is Active

• Activity Monitor (quickest GUI check):
  • Launch WOS, then open Activity Monitor.
  • Go to View > Columns and enable the Sandbox column.
  • Find the WOS process - the Sandbox column should show Yes.
• Extract the sandbox profile from the binary (proves the SBPL code is embedded):

  strings "/Applications/WOS.app/Contents/MacOS/WOS" | grep -A 30 "(version 1)"

  This prints the exact Seatbelt profile baked into the binary. Compare it with the source code on GitHub — they should be identical.

2. Verifiable Network Blockade (Most Direct Method)

You can verify the kernel-level blocking of the WOS process by checking its network state in real-time or by auditing the binary headers for network linkages.

Check binary network linkages (should return nothing):

otool -L "/Applications/WOS.app/Contents/MacOS/WOS" | grep Network

Observe the process in real-time (should show 0 sockets):

lsof -p $(pgrep WOS) -i

• What to look for:
  • The first command should be empty (no network libraries linked).
  • The second command (run while app is active) should return zero rows or only a local IPC listener if applicable, but never any TCP or UDP outbound connections.

3. Verifiable Filesystem Write Restriction

Verify that WOS can only write to its designated export directory:

Check what files WOS has ever written:

ls -la ~/Documents/WOS-Exports/

Watch for sandbox write denials in real-time:

log stream --predicate 'sender == "Sandbox" AND eventMessage CONTAINS "deny" AND eventMessage CONTAINS "file-write"'

If WOS ever attempts to write outside ~/Documents/WOS-Exports/, the kernel will deny it and this command will show the violation in real-time.

4. View Sandbox Violations or Runtime Behavior

• Console.app (for logs of denials):
  • Open Console (in /Applications/Utilities/).
  • In the search bar, type sandbox WOS.
  • Look for deny entries → These show what the sandbox blocked (e.g., socket operations, file writes).
• Real-time monitoring in Terminal:

  log stream --predicate 'sender == "Sandbox" AND eventMessage CONTAINS "WOS"'

5. Advanced: Inspect the Raw Seatbelt Profile

Unlike App Store apps that inherit from a compiled system profile you can't easily read, WOS's Seatbelt profile is a plaintext SBPL string you can inspect directly. The full profile is published above on this page, and you can extract it from the binary:

strings "/Applications/WOS.app/Contents/MacOS/WOS" | grep -A 30 "(version 1)"

Compare the output with the source code in main.swift on GitHub - they should match exactly. If they don't, that's a red flag.