feat(gui): macOS assistance-GUI backend (status item, consent, NSWindowSharingNone) (VA-55) #147
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/VA-55-macos-assistance-gui"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Implements VA-55 (VA-24 follow-up): the macOS assistance-GUI backend, bringing the tray/status-item, in-process consent dialog, operator-connected notification, and screen-capture opt-out to macOS. VA-24 shipped this for Linux and VA-56 for Windows; both deferred macOS because it cannot be built in the Linux CI sandbox (no macOS SDK).
What landed
GUI crate (
vervain-agent-gui):tray-icon's macOS NSStatusItem backend on the same in-winit-thread model as Windows (created + pumped on eframe's main thread, menu clicks via the globalMenuEventchannel).tray::build/refreshand the app's owned-tray logic are nowany(windows, macos). Shows connection state and a "Disconnect now" item.apply_capture_exclusiongains a macOS arm that reads the winitNSViewviaraw-window-handleand sends-[NSView window]then-[NSWindow setSharingType:]withNSWindowSharingNone(0) via rawobjc2messages, the peer of the WindowsWDA_EXCLUDEFROMCAPTUREpath. Retried per frame until the handle exists.any(windows, macos)(notify-rust posts it viaNSUserNotification).cfg(unix)UnixStream, so macOS reuses it.proto::default_socket_pathreturns/var/run/vervain-agent/assistance.sockon macOS (no/run).Daemon (
vervain-agent): theagent-guiplatform gates (gui_ipc module,assistancesubcommand + dispatch, IPC-server start, consent GUI path) now includemacos. The#[cfg(unix)]IPC server binds/hardens the unix socket unchanged.Dependencies
objc2pinned to winit 0.30's 0.5 line (already in the lock) so the messaged objects are the exact runtime objects winit created;raw-window-handlereused from the same 0.6 line. Bothapp-feature-gated, macOS target only. No new crate for the tray (tray-icon's macOS backend is already pulled).Validation
vervain-agent-gui --features appandvervain-agent --features agent-guicompile clean; workspace + guiclippy --deny warningsandfmtclean; gui unit tests pass (proto round-trips + the macOS socket-path assertion).NSWindowSharingNoneobjc2 message path was cross-checked foraarch64-apple-darwinin isolation (objc2 0.5.2) -msg_send![view, window]andmsg_send![window, setSharingType: 0]typecheck.mac-notification-sysbuilds Objective-C (needs the macOS SDK), same class of blocker asring. So AC#1 (builds on macOS with the feature) and the runtime ACs (tray, consent round-trip, disconnect, capture exclusion, stripped binary size < 20 MB) must be validated on the runner / a real Mac:agent-guiis off by default, so this is not part of the shipped release binary; happy to add a macOS CIcargo check --features agent-guistep as a follow-up to keep AC#1 enforced.Out of scope / follow-up noted
The desktop-tunnel key dispatch in
host/tunnel.rsstill routes macOS through anot(any(linux, windows))discard arm (a VA-93 gap for the tunnel keymap, unrelated to the GUI); flagged separately, not touched here.Acceptance criteria
vervain-agent-gui --features app/vervain-agent --features agent-guibuild wired for macOS (compile verified on a Mac pending, per gap above)host/consent.rsover IPC on macOSNSWindowSharingNone🤖 Generated with Claude Code