Yes, if the application was built for it, and most are not. The blocker is never the commands, it is that a command line written for a human stops at a prompt an agent cannot see and answers in prose an agent cannot parse. Grux OS ships a command line where every command runs unattended, with a flag for every choice and JSON on every read, so nothing hangs. Every command can also print itself as a prompt instead of running, which hands the job to whichever coding agent you already use rather than making you translate it. There is also a read-only MCP bridge, so an agent that speaks that protocol can drive the same tools you do. Reads answer with the app closed, because they come from files on disk.
npx @dotcomjack/grux # finds Grux.app, puts `grux` on PATH, runs setup
# or link the binary by hand
ln -s /Applications/Grux.app/Contents/MacOS/grux-cli ~/.local/bin/gruxThe npm package is a dependency free shim that locates the binary and steps aside. There is one implementation of everything below and no second front door to drift.
| Command | What it does |
|---|---|
grux setup | The whole first run, unattended |
grux status --json | What is configured and what is missing |
grux doctor | What is wrong, and what to do about it |
grux why <feature> | Why a feature says it needs setup |
Reads come from files on disk, so grux status --json answers whether or not the window is open. Writes go over a Unix socket with 0600 permissions, which means Grux still opens no network port at any point. An agent can therefore inspect state cheaply and often without launching anything.
The MCP server is read only. Writes go over the Unix socket instead. That is a real limitation rather than a design principle, and making it bidirectional is named in the repository as contained work that would let any agent drive the whole app.
Four modules are library products and none of them imports AppKit or SwiftUI, so they build and test without the UI stack and you can depend on one without taking the other three.
| Module | What it is |
|---|---|
GruxShellCore | A PTY, the safety gates and the snapshot store |
GruxAgentCore | Orchestration |
GruxSetupCore | The capability and permission model |
GruxMCPCore | The read-only MCP server |
Adding a tool is two edits in one file, and a test pins the tool count at 116 so adding one turns the suite red until the pin moves on purpose. Adding a sidebar surface is one entry in the feature registry, which is also what drives the setup sheet, the permission table and the BETA badge.