@ironbee-ai/cli weekly downloads statistics

<h1 align="center"> <img src="https://ironbee.ai/ironbee-logo.svg" alt="IronBee" width="128" /><br /> IronBee CLI </h1> <p align="center"> <strong>The CLI for <a href="https://ironbee.ai">IronBee</a> — Verification and Intelligence Layer for Agentic Development</strong> </p> <p align="center"> <a href="https://www.npmjs.com/package/@ironbee-ai/cli"><img src="https://img.shields.io/npm/v/@ironbee-ai/cli.svg" alt="npm version" /></a> <a href="https://github.com/ironbee-ai/ironbee-cli/blob/main/LICENSE"><img src="https://img.shields.io/badge/license-Elastic%202.0-blue.svg" alt="license: Elastic License 2.0" /></a> </p>

---

IronBee ensures that AI agents verify their code changes before completing a task. When an agent edits code, it cannot finish until it exercises the affected paths through real tools — in the browser for frontend changes, against the wire protocol (HTTP / gRPC / GraphQL / WebSocket) for any-runtime backend changes, or via the Node.js V8 inspector for Node-specific backend changes — and submits a passing verdict.

No more "it should work" — every change is tested.

IronBee also tracks every verification cycle — coding time, fix time, pass/fail rates, problematic files — and links each activity to the pull request(s) and issues the work belongs to, so verification data is attributable to an issue rather than an opaque session id.

Powered by IronBee DevTools (@ironbee-ai/devtools), which runs in three modes from the same package:

• Browser mode (bdt_* tools, default-on): the agent navigates pages, clicks buttons, fills forms, takes screenshots, checks console errors.
• Backend mode (bedt_* tools, opt-in, runtime-agnostic): the agent drives real HTTP / gRPC / GraphQL / WebSocket calls against your backend, inspects logs, and queries databases — works for Node, Java, Python, Go, Rust, Ruby, .NET, PHP, Elixir, Kotlin, and Scala backends alike.
• Node mode (ndt_* tools, opt-in): the agent connects to a running Node process, sets V8 probes (tracepoint / logpoint / exceptionpoint) at the changed code paths, exercises them, and reads back snapshots or runtime logs.

A single Stop hook can drive multiple cycles in parallel — touching frontend, a backend protocol, and a Node runtime in the same change requires evidence for each before the task can complete.

Demo

https://github.com/user-attachments/assets/9d4e602b-6c05-4b48-89a8-3df429d10e00

Supported Clients

Client	Status
Claude Code	Supported
Cursor	Supported
Codex	Planned
OpenCode	Planned

Quick Start

Install IronBee globally

npm install -g @ironbee-ai/cli

Set up a project

cd your-project
ironbee install

This auto-detects your AI client and writes:

• Hook configuration (so the client calls IronBee automatically)
• Verification skill/rules (so the agent knows the workflow — covers every enabled cycle)
• MCP server entries from the same @ironbee-ai/devtools package (IronBee DevTools), per-cycle gated — only currently enabled cycles get an entry:
  • browser-devtools (PLATFORM=browser, bdt_ prefix) — registered on first install (browser is the default-on cycle); strip with ironbee browser disable
  • backend-devtools (PLATFORM=backend, bedt_ prefix) — only after ironbee backend enable
  • node-devtools (PLATFORM=node, ndt_ prefix) — only after ironbee node enable
• Permissions matching the registered entries (mcp__browser-devtools__*, plus mcp__backend-devtools__* and/or mcp__node-devtools__* once their cycles are enabled)

Optional: opt out of the browser cycle

ironbee browser disable

The browser cycle is the default-on cycle — every code-file edit (40+ extensions: .ts, .tsx, .css, .html, .py, .go, .java, …) requires browser-driven verification (navigate / screenshot / aria / console). Run browser disable for projects where you don't want browser-cycle enforcement (e.g. backend-only services where only backend enable / node enable apply). With browser off, an enabled node / python / backend cycle switches from its server-layout defaults to its language's broad glob (**/*.{ts,js,…} / **/*.py / multi-language) — browser's globs were the wide net, and without them a desktop app / CLI / library would match no cycle; install and <cycle> enable warn when an enabled cycle matches no tracked file. It writes browser.verifyPatterns: [] to override the legacy 40+ extension default; customizations of alwaysRequired / evidencePaths / additionalVerifyPatterns are preserved.

To re-enable: ironbee browser enable — strips the verifyPatterns: [] override so the code defaults (legacy 40+ extension list) flow back in at runtime. config.json stays minimal; the default list is NOT materialized into the file (it lives in code and tracks the CLI version automatically).

Optional: enable runtime-agnostic backend protocol verification

ironbee backend enable

Activates the backend protocol cycle — drives real HTTP / gRPC / GraphQL / WebSocket calls against your running backend service via the backend-devtools MCP (bedt_* tools) and verifies the responses. Works for any backend runtime: Node, Java, Python, Go, Rust, Ruby, .NET, PHP, Elixir, Kotlin, Scala. The command writes a minimal { "backend": {} } block to config — code defaults (multi-language paths covering server/**, api/**, routes/**, controllers/**, handlers/**, services/**; the broad multi-language **/*.{…} glob when the browser cycle is disabled) flow in at runtime.

To revert: ironbee backend disable (drops the block clean if no customizations / lower-layer override; otherwise hard-kills via verifyPatterns: []).

Optional: enable Node.js runtime debug verification

ironbee node enable
```…