SideGuard: a pause button for AI coding agents

Let me start with the uncomfortable part.

AI coding tools are no longer just smarter autocomplete. That phase is already over.

Today, a coding agent can read your repository, edit files, run tests, install packages, open a browser, call an MCP server, query an internal tool, or touch something you connected three weeks ago and no longer remember clearly. This is exactly why these tools are useful. It is also exactly why they need a boundary.

I use Cursor and Claude Code every day. I like them. They save time, especially in large codebases where the boring part is not writing one function, but holding ten files in your head at the same time.

But every now and then, while an agent was working, I found myself looking at a command and thinking:

Did I actually ask for this?

Not in a dramatic Hollywood hacking sense. More like: "This is probably fine, but why is it doing that now?"

That small moment is the whole reason I built SideGuard.

Without the jargon

SideGuard is a local pause button for AI coding agents.

It sits between the assistant and your machine. When the agent wants to run a terminal command or call a tool, SideGuard stops the action first. You can approve it, deny it, or let a rule decide.

If nothing clearly allows the action, it does not run.

That sounds simple, but I think it is the missing layer in a lot of AI-assisted development.

Because there is a big difference between:

• "The assistant suggested a command."
• "The command actually ran on my machine."

We have learned to review code before merging it. We have learned to read infrastructure changes before applying them. But with agentic coding, we often let tools jump directly from suggestion to execution. SideGuard puts a small checkpoint in the middle.

Not a big enterprise ceremony. Just a clear "yes" or "no" before something touches your system.

I did not want this to become another cloud security dashboard either. SideGuard is local by design. The daemon runs on your machine. The policy is a YAML file on disk. The audit log is stored locally in SQLite.

Your keys stay with you. Your policy stays with you. Your history stays with you.

Daily use

Most of the time, SideGuard should feel almost boring.

You keep working in Cursor or Claude Code. When the assistant tries to run something, SideGuard either applies your policy or places the action in a queue. You look at it, approve it, deny it, or ask SideGuard to explain it in plain English.

For the terminal UI:

sideguard ui

Use the arrow keys, or j and k, to move through pending actions. Press a to approve and d to deny. It refreshes by itself, because nobody needs one more window to babysit.

On macOS, there is also a menu-bar tray. It is still experimental, but useful when you are not living inside a terminal pane. Pending items show up in a popover, and you can switch modes from there.

One detail I care about: notifications only notify. They do not approve anything for you.

There is also an optional Analyse action. If a command looks strange, SideGuard can ask an LLM to explain it in plain English. Today that can use OpenAI, Anthropic, or Ollama. It is optional, redacted, and loopback-first. More importantly, it does not make the decision. Your policy still makes the decision. You still make the decision.

Getting started on macOS or Linux is short:

curl -fsSL https://sideguard.io/setup.sh | sh
sideguard daemon start
sideguard install
sideguard clients reload

install wires the pieces together for Cursor and Claude Code. After installing or uninstalling, reload your AI client so it picks up the new configuration. sideguard clients reload prints the exact steps for each client.

If you only remember one thing, let it be this:

SideGuard gives you a local approval layer before coding agents touch your machine.

Now, for the people who will immediately ask: okay, but where is the trick?

Technical details

The first design decision was scope.

SideGuard is not trying to become a full endpoint security platform. It focuses on the agent execution path: the moment where an AI assistant tries to do something real.

In practice, that means two channels.

The first one is shell commands: anything the assistant tries to send to the terminal.

The second one is MCP tool calls. This is the part I think more people should pay attention to.

MCP gives agents access to real systems: databases, browsers, internal tools, cloud APIs, Kubernetes, ticketing systems, and whatever else you connect. If you only guard the shell, but leave MCP calls untouched, you have guarded the front door while leaving the side door open.

SideGuard wraps STDIO MCP servers so tool invocations go through the same approval path as shell commands. They are not treated as harmless metadata. They are part of the execution surface.

The policy is just YAML. You can allow patterns you trust, block patterns you never want, or keep everything manual so every request lands in a queue.

There are also global modes:

• ask queues everything that is not explicitly allowed or denied.
• auto lets low-risk actions pass, blocks clearly dangerous ones, and queues uncertain cases.
• auto-allow is useful for controlled development sessions where you want less friction.
• auto-deny is the panic button when you want the assistant to stop touching tools.

The mode lives in the daemon, so the CLI and the macOS menu-bar tray stay in sync. I usually think of auto as the practical mode. It reduces noise without turning the guard into decoration.

Every decision is recorded locally in SQLite. When something surprises you later, you can look back:

sideguard history --since 7d
sideguard history --denied

For scripts or automation you can work headlessly:

sideguard pending --json
sideguard approve <id>
sideguard deny <id> --reason "too risky"

There are a few trust-boundary details worth spelling out.

SideGuard is local-first. The daemon, policy files, and audit database live on your machine. Optional LLM analysis only runs when you ask for it, with redacted input, and it does not approve or deny anything. The policy remains the source of truth.

The implementation is deliberately boring. Under the hood, SideGuard is a single Go binary: daemon, CLI, hook bridge, MCP proxy, terminal UI, and, on macOS, the tray app. The model is hooks plus MCP wrapping, one local audit database, and policy files under ~/.sideguard.

That boringness is intentional. Security tooling that developers actually keep enabled needs to be understandable. If the guard itself becomes a black box, people will eventually disable it to get work done.

One small operational detail: commands like sideguard ui are auto-allowed by the hooks. Otherwise an agent could accidentally block the very tool you need to unblock it. If you still manage to get into a loop, approve from Terminal.app outside the IDE, or use a repo-scoped development policy while working on SideGuard itself.

If you are developing SideGuard inside Cursor, or working in any repository where the agent needs to run make, go test, or similar commands often, use sideguard policy init-dev or sideguard install --dev. That creates a relaxed policy only for that workspace. Your global rules for other projects stay strict.

Binaries and checksums are published on GitHub Releases. When a new version ships, the tray can remind you, or you can update from the CLI:

sideguard update apply --restart

What it is not

SideGuard is not an MCP antivirus. It is not a cloud security scanner. It does not read your whole disk, and it does not send every command to a remote service for judgement.

The promise is smaller, and I think more useful:

before an agent touches your machine, you get a clear chance to stop it.

If you want the full technical picture, ARCHITECTURE.md in the repository goes deeper than this note.

Links

• sideguard.io — landing page and install script
• GitHub — alisaitteke/sideguard — source, releases, roadmap

SideGuard is MIT licensed.

If you use coding agents every day and want a real pause button before commands hit your machine, I hope it helps. I am still learning what "safe enough" feels like in real workflows, so feedback, issues, and strange edge cases are very welcome.