Grux for Mac
Handle mail, calendars, meetings, and terminal work in one place, with commands you can undo.
- Source repo
- dotcomjack/grux
- Stars
- ★ 30
- Last updated
- 5d ago
- License
- MIT
- Primary language
- Swift
- FA score
- 67/100 · Some gaps
At a glance
- How it runs
- Works with
- Portable with changesClaude API
- Cost
- Free, no paid service needed
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- An independent developer wants to handle calendar, mail, and project tasks from one Mac window and run terminal commands that can be undone.
- Not a fit if
- Users who need to run on Intel Macs
- Teams that need a Windows or Linux desktop app
- Source review
- 67/100 · Some gaps
What does this agent do, and when should you use it?
Grux is a native AI assistant for Apple silicon Macs, organized around a Command Panel that opens feature panes alongside it. It runs through the Anthropic API or a local Ollama model and works with mail, calendars, contacts, notes, documents, meeting recordings and transcripts, projects, and tasks. Its shell applies path rules, command denials, rate limits, and audit logging, and snapshots commands before execution so they can be undone. Meetings use WhisperKit for on-device transcription, so raw audio is not uploaded; credentials are stored in macOS Keychain. Grux ships as a macOS app with a `grux` CLI for driving its features from a terminal.
A user enters requests in the Command Panel, where Grux can call 116 tools, access existing mail, calendar, contacts, notes, and documents, and open the relevant feature pane. Chat can use Anthropic or Ollama models, and its shell runs commands behind a path allowlist and command denylist; each command is snapshotted into a shadow git repository first and recorded in an audit log. Meetings can record microphone and system audio, transcribe it on device with WhisperKit, and file the transcript. The CLI supports setup with grux setup, configuration checks with grux status --json, and diagnostics with grux doctor; external MCP clients can read through a read-only MCP bridge.
- An independent developer wants to handle calendar, mail, and project tasks from one Mac window and run terminal commands that can be undone.
- A team that does not want to upload meeting recordings needs on-device transcription, speaker separation, and saved transcripts.
- A Mac user who wants a local model for private material can run Grux through Ollama without configuring a model key.
- An Anthropic API user wants Chat to use mail, contacts, and documents as work context.
- A developer using a terminal coding agent wants to inspect or drive Grux through its CLI or read-only MCP bridge.
How do you install or deploy this agent?
The prebuilt app targets Apple silicon Macs running macOS 14 or later. Download the DMG, drag Grux into Applications, and open it. You can also install the app and CLI with Homebrew. Building from source requires Xcode 16 or later. On first use, configure an Anthropic API key or run Ollama locally with a model ready.
How do you use this agent?
Install and open Grux, then follow first-run setup to choose a use, name, and model; macOS permissions are requested individually when a feature first needs them. You can also complete setup from a terminal with the command below. Once a model is configured, check its status or run diagnostics.
What are this agent's strengths and limitations?
- Works with real mail, calendar, contacts, notes, and documents on the Mac, without a Grux backend or hosted copy.
- Supports the Anthropic API and local Ollama models; a local model can be used without an API key.
- Shell commands are snapshotted before execution and guarded by path allowlists, command denials, rate limits, and audit logs.
- Meeting recordings are transcribed on device with WhisperKit, and raw audio is not uploaded.
- Includes a CLI and read-only MCP bridge for terminal agents to inspect and drive Grux.
- Requires macOS 14 or later and Apple silicon; the README explicitly says Intel Macs are unsupported.
- Using Anthropic-hosted models requires your own API key and direct provider charges.
- You must configure a model and grant macOS permissions feature by feature for access to mail, meetings, shell, and other capabilities.
- The MCP bridge is read-only; writes use Grux's Unix socket interface.
- Twelve Labs features are labelled rough around the edges; the README says Agents and Self-Upgrade have the most work left.
How does this agent compare with similar options?
The README names Raycast AI, LM Studio, Claude desktop, the ChatGPT desktop app, Osaurus, Msty, and Jan in comparison topics. Grux's distinction is that it is a native Mac agent that can act on mail, calendars, files, and shell commands; the README characterizes LM Studio as a way to run a model and Grux as an agent that acts.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Grux for Mac This agent | 67 · Some gaps | Desktop appFree | ★ 30 | 5d ago | Swift | Claude API |
| GAIA — Personal AI Assistant | 73 · Some gaps | Hosted serviceFreemium | ★ 308 | today | Python | — |
| TuriX | 34 · Major gaps | CLIFree + model costs | ★ 3.2k | 28d ago | Python | Claude.ai |
| OnlySwitch — All-in-One macOS Menu Bar Switcher | 54 · Major gaps | Desktop appFree + model costs | ★ 6k | 2d ago | Swift | — |
How does FollowAgents rate this agent?
Why each dimension lost points
The README describes on-demand, optional permissions and a filesystem path allowlist, denylist, limits, redaction, and audit log. It also acknowledges that the app is unsandboxed and can run real shell commands, so least privilege, confirmation, and rollback each score 2. Data flows are detailed for the Keychain, model providers, meeting audio, and local logs, earning 3. Direct dependencies are listed, but the supplied material does not establish their current vulnerability status, so dependency security scores 1. Security reporting channels and a maintainer email are given, but publisher identity is unverified, so source attribution scores 1.
The README, CI configuration, and launcher tests give concrete descriptions of tool counts, test floors, failure paths, and known CI gaps; some product claims cannot be independently checked from the supplied files, so self-consistency scores 2. Dependencies and the minimum toolchain are described, but availability and compatibility are not evidenced here, so dependency availability scores 2. The CLI offers status, doctor, why, and exit-code information, and tests cover several error messages; clear recovery for every failure is not established, so failure messages score 2.
The target environment is specifically Apple silicon on macOS 14 or later, with local Ollama and hosted-model scenarios described. The feature set is broad, but audience-specific guidance is limited, so audience and scenarios score 2. The permission table, feature tiers, and security boundaries describe capabilities and acknowledge the lack of sandboxing and rough Labs features, earning 2. Permissions are requested when needed and refusal disables the corresponding feature, but confirmation details for other high-impact actions are incomplete, so trigger precision scores 2. Platform, toolchain, and model choices are explained, but only Mac is supported, so environment fit scores 2.
The README has a contents list and sections for installation, permissions, feature tiers, and building; it is long and the supplied copy is truncated, so information architecture scores 2. DMG, Homebrew, CLI, checksum, and source-build steps are explicit, earning 3. Product version and feature names are described, but naming rules are not, so naming stability scores 2. There are many FAQ links and command examples, but the linked answers cannot be checked from the supplied material, so examples and FAQ score 2. The security policy documents limitations around redirects, DNS, and the redactor, and the README labels Labs as rough, earning 2. The MIT license text is complete, earning 3. The README identifies version 3.0 and CI and security files describe release support, but a full change history is absent from the supplied material, so versioning and changelog score 2. The security email, response timelines, and supported-version policy identify maintenance responsibilities; the solo-project context and unverified identity limit that evidence, so maintenance responsibility scores 2.
The CLI supports JSON reads and status, doctor, and why commands; launcher tests cover argument forwarding and terminal output. Actual task outcomes are not verified by this static review, so output usability scores 2. The unified interface, system integrations, and reusable Swift modules suggest useful value, balanced by the broad permissions and complexity, so marginal value scores 2. MIT licensing and local-model use reduce cost; hosted models require user-paid accounts, while hardware, permissions, and setup impose costs, so cost-benefit scores 2.
Many installation, security, and feature claims point to specific files, configuration, or test descriptions, but some important claims remain README assertions, so claim traceability scores 2. The README, CI, security policy, and launcher tests corroborate some claims; execution results and all implementation files are not supplied, so cross-source corroboration scores 2. The docs distinguish core features from Labs and acknowledge several limitations, but do not consistently label fact, commitment, and inference, so fact-inference separation scores 2.
- The app is not macOS-sandboxed and can access mail, calendars, the screen, and a shell; review the permission guide and SECURITY.md, and grant only needed permissions.
- Hosted model providers receive the content sent to them. A local model reduces that data flow, but local configuration and permissions still matter.
- A CI comment says four “never-publish” values were once recoverable from the public copy, without describing their nature or current status; the supplied static evidence is insufficient to assess the impact.