Jentrix open client

The command-line client and the official coding-agent plugins for Jentrix — open at the edge, governed at the centre. Everything that runs on your machine is in this repository; everything that decides authority (authorization, tenancy, audit, idempotency, concurrency, rate limits) is enforced by the hosted service on every request, whatever the client says.

| Package | What it is | | --- | --- | | @jentrix/cli (this directory) | The jentrix command: every MCP tool as a shell command (jentrix task list --board-id <id> --json), OAuth sign-in, connected-session commands, jentrix session doctor, and the jentrix-session-host bin the plugins' hooks call | | @jentrix/plugin-claude (plugins/claude) | The official Claude Code plugin: /jentrix-connect, /jentrix-align, /jentrix-plan, /jentrix-checkpoint, /jentrix-review, /jentrix-status, /jentrix-end and the trusted lifecycle hooks | | @jentrix/plugin-codex (plugins/codex) | The official Codex plugin: the same seven workflows as $jentrix-… skills, plus the hooks | | @jentrix/plugin-opencode (plugins/opencode) | The official OpenCode plugin: the same seven /jentrix-… commands registered in-process, session identity handed to every bash command, and the lifecycle/token-receipt ledger the session host reads | | @jentrix/plugin-pi (plugins/pi) | The official Pi package: the same seven /jentrix-… extension commands (injected as marked custom messages) and the same ledger |

The CLI depends on all four plugin packages with exact pins and materializes them into your provider — Claude Code and Codex with the hook commands pinned to absolute paths, OpenCode through one managed loader file, Pi through pi install. MIT licensed, DCO signed, no CLA.

Install — one command

npx --yes --package @jentrix/cli@latest jentrix setup

The same line works in bash, zsh, fish, PowerShell and cmd; it needs Node ≥ 20. jentrix setup checks the machine, installs the CLI globally, signs you in through the browser, installs the official plugin for every coding agent it finds (Claude Code, Codex, OpenCode, Pi), and leaves the checkout connected. It is preview-first: read the plan it prints, then confirm.

Without Node on the machine, the hosted bootstrap installs it first and runs the same command:

bash -c "$(curl -fsSL https://tm.jentrix.ai/install.sh)"     # macOS / Linux
irm https://tm.jentrix.ai/install.ps1 | iex                  # Windows PowerShell

Direct use, no setup

npm install -g @jentrix/cli
jentrix --version                  # version and bundled product-tool count
jentrix login                      # OAuth in the browser; or export STACKS_TOKEN=tm_…
jentrix whoami
jentrix task list --board-id <id> --json | jq .

# or run it without installing (the --package form is required: the package
# ships several executables, so a bare `npx @jentrix/cli` cannot pick one)
npx --yes --package @jentrix/cli jentrix --help

jentrix plugin install claude and jentrix plugin install codex install the official plugins on their own; jentrix session doctor reports what is installed, who owns each provider's jentrix marketplace, whether the hooks are pinned, and how this build's contract compares with the server's.

Connected work and task labels

Start Claude Code or Codex normally, then connect inside the provider:

jentrix folder align --workspace <workspace-slug>  # once per checkout
jentrix session connect --provider codex          # or claude
jentrix session align --task JEN-42
jentrix task project add --task JEN-42 --project <project-slug>

Sessions use the folder's workspace. Projects are optional task labels; ID-based label edits also work outside a bound checkout. Human task keys require a bound workspace and are checked against the returned identity. session claude also supports foreground launch; Codex uses connect only. Capture and skeleton preferences are preserved unless you explicitly change them.

session align and task context close their Related evidence block with a Beyond this card: line for a subject query with nine evidence kinds, the 25-hit ceiling, and a command to list everything on the card; fresh cards print the same recipe beneath their one-line summary.

The product CLI does not run Ops commands. An unreadable bundled tool manifest refuses raw tool calls with a reinstall instruction. See the exact migration refusals and remaining thin aliases in compatibility.

Where the contract lives

The CLI is built from a contract the service serves, not from a copy of its source:

GET https://tm.jentrix.ai/api/mcp/contract          the manifest: surface, apiRelease, digest, publicationState
GET https://tm.jentrix.ai/api/mcp/contract/bundle   the bundle: every tool's schema + the golden vectors

scripts/adopt-contract.mjs https://tm.jentrix.ai/api/mcp/contract verifies the digest and writes surface.json, contract-vectors.json and contract.json — the three files the command tree, the help goldens, the mirror test and jentrix --version derive from. The bundle this release adopted is checked in at docs/contract/mvp.json; the OAuth protocol contract is docs/contract/oauth.md. How versions, digests, drift and the 180/90-day support window work: docs/compatibility.md.

Documentation

• Creating and using AI agent plugins — the M1 baseline, custom workflows, host adapters, session evidence and shared infrastructure

• Testing AI agent plugins — deterministic checks, exact-package trials, installation, recovery and handoff evidence

• Compatibility and lifecycle — the four version domains, the six-step connection order, the support window

• Hooks and the trust model — what the hooks do, the absolute-path pin, the provider's trust step

• Writing a Claude Code plugin for Jentrix · Writing a Codex plugin for Jentrix — from a minimal acme-jentrix to distribution

• Forks and composition — compose beside the official plugin, or fork it under your own name; the coexistence matrix; the upstream comparison loop

• Releasing — the pack-once, publish-to-latest ritual (maintainers)

• Runbooks — contract digest mismatch, publish failure, compromised release, migration failure

• examples/acme-claude · examples/acme-codex — the two reference extensions; pnpm validate:examples checks them the way your CI would check yours

• In-app: install, connected sessions, the product tool catalog

Build and test

pnpm install
pnpm typecheck && pnpm test
CLI_PACK_SMOKE=1 pnpm test        # + cold install of the packed tarballs (what CI runs)
pnpm validate:examples
pnpm build                        # dist/: the two bins and the @jentrix/cli/core entry

See CONTRIBUTING.md (DCO sign-off, what is in scope), SECURITY.md (private reporting, severity targets), TRADEMARKS.md (reserved names, how to name a fork) and EXTRACTION.md (how this repository was created from the private source, and what was audited).

License

MIT © Jentrix — see LICENSE and NOTICE.