Back to Home
· product · apexe
apexe
Governed CLI capability runtime built on apcore
apexe turns existing CLI tools into governed apcore modules. Every scan first identifies the binary's variant — bsd, gnu, apple, or busybox — then builds the flag set from help output, man pages, and curated overlays, tagging each flag with a confidence tier and the sources behind it. An always-on path guard bounds what a call may touch: system directories stay read-only, credential directories stay off-limits, and config.yaml can widen or narrow both. The same modules serve over MCP stdio, HTTP, or SSE, or as an A2A agent, behind fail-closed ACL, audit logging, preview for destructive commands, and retry and circuit-breaker middleware.
· 01
Features
01Variant-Aware Scanning: Probe every binary and classify it as bsd, gnu, apple, busybox, or unknown before scanning, so a BSD tool advertising GNU compatibility is never misread as GNU
02Curated Tool Overlays: 42 built-in overlays cover the 21-command POSIX core across BSD, GNU, and Apple variants, with authoritative and merge modes and mandatory provenance at confidence: verified
03Confidence-Tiered Flags: Every scanned flag records verified/high/medium/low confidence and its contributing sources, so consumers can tell a curated fact from a text-scraping guess
04Man Pages as a First-Class Source: Tier 2 contributes flags directly, not just descriptions to flags Tier 1 already found — on macOS that takes ls to 46 flags and curl to 257, with BSD DESCRIPTION-section option parsing alongside GNU OPTIONS
05Schema and Display Metadata: Derive JSON Schema types, formats, defaults, enums, required fields, positional args, aliases, and per-surface display data
06Single Scan Report: apexe scan --format json|yaml emits one ScanReport document with a flattened commands[] contract, and the scan cache is keyed by tool, variant, version, and scan format version, so an upgraded build never serves a pre-fix result from cache
07Always-On Path Guard: Every path-typed argument is resolved the way the kernel would see it — relative paths joined, symlinks followed, .. folded — then checked against two compiled-in baselines: system directories bind a module that can write, credential directories (~/.ssh, ~/.aws, ~/.gnupg, ~/.kube, ~/.docker, ~/.apexe) bind readers too. On by default on every surface with no off switch; allowed_paths and additional_denied_paths adjust the boundary and apexe policy --path reports the live verdict
08Governed Execution: Run scanned tools as apcore modules with live annotations, fail-closed ACL, ACL allow/deny audit logging, preview, and library approval store support; command executors such as env, xargs, timeout, and sudo are classified destructive, so a caller-supplied argv string is never judged as a reader's
09Availability Filtering: apexe serve and apexe a2a drop any module whose binary does not resolve on this machine, so a client is never offered a tool that fails every call with ModuleNotFound; apexe list --available-only applies the same check on demand
10Protocol Surfaces: Serve the same modules over MCP stdio, HTTP, or SSE, or publish them as an A2A agent; servers bind localhost by default, transport auth is available through the apcore library API, and an ACL or approval refusal over A2A reports the denial and its reason instead of a misleading Task not found
11Long-Running Flag Detection: Overlay-asserted long_running flags (e.g. tail -f) surface as x-apexe-long-running in the emitted JSON Schema, so an executor knows to bound the timeout
· 02
Get Started
Rust · Implementation
Rust 1.75+ implementation of the apexe scanner, executor, MCP server, and A2A agent runtime.
Install
$ cargo install apexeQuick Start
rust.rs# Scan an installed CLI tool
apexe scan git
# Inspect generated module bindings
apexe list
# Serve the scanned modules over MCP HTTP with the Explorer UI
apexe serve --transport http --port 8000 --explorer
# Or publish the same modules as an A2A agent
apexe a2a --url http://127.0.0.1:8000 --explorer· related
