IOSM CLI

The deciding trait is the granularity of consent. Approvals are scoped to a session or a single turn, so you can open a door for one action and have it close behind you, instead of the usual choice between confirming everything and confirming nothing. If you have ever clicked allow always out of fatigue and regretted it, that distinction is the product.

The cost is friction, and on a long task it accumulates. Pick it when you want to stay in the loop deliberately. Pick a more established terminal agent when you want throughput and will read the diff instead.

The risk is the second entrance. An RPC mode turns a local tool into something addressable by other programs, and the row pairs it with direct filesystem and shell work and no isolation layer. The permission engine decides what is allowed; it does not decide where an allowed command can reach, and those are different guarantees.

What it does right is deterministic resolution. Layered policies that resolve predictably are far better than the usual arrangement, where precedence is discovered by experiment and differs between modes.

1. Recording metrics and artifacts per run is the right primitive, because it makes a comparison between two runs possible at all. Most tools in this class retain a transcript and nothing else. 2. Repeatability and auditability follow from that record and are credible.

2. Benchmarking does not. A benchmark requires a fixed task set, a stated scaffold and a reported method, and none is published here, so the capability described is the ability to measure rather than any measurement. The distinction between an instrument and a result is not drawn in the documentation.

Those two numbers together are the whole diligence. Stars measure the pitch and installs measure the product, and when they diverge by that ratio the pitch is doing all the work. A single maintainer with no entity behind him is carrying a feature list that would occupy a small team.

Moat: none, and the ambition of the scope makes that worse rather than better, because breadth is expensive to maintain and cheap to copy. Likely path: the interesting policy work gets absorbed by a larger terminal agent. Position: watch it, do not commit to it.

Most tools in this category give me nothing to describe. This one at least has a policy model that can be written down, versioned and reasoned about, which is where a control starts even when it is not yet where one ends. That is worth an evaluation.

It stops there. No directory integration, no provisioning, no central audit trail across sixty machines, and nothing that runs unattended, so it never becomes a delivery step I can measure. The supplier is one person. Not yet, and I would want the policy files under our own version control before any pilot.

Permissive licence and readable source, so the fork is mine and I can fix what I dislike. MCP support means the servers already running on my machine become tools without me writing a bridge, which is the single feature that decides whether a new agent is worth configuring at all. Any provider, my key.

No local model support is the gap, and for a tool that markets control it is the one that stings, because control over policy is not control over where the tokens go. Global npm install for a runtime this ambitious is also a choice.