What it does
Tuff treats the things a coding agent loads (skills, tools, MCP servers, hooks and policies) as files in your project and manages them much like packages. You declare a capability once in a tuff.toml manifest, and Tuff writes it in the format each supported agent reads, including Claude Code, Codex, Cursor and OpenCode, recording everything in a tuff.lock file. It keeps the source, version, scope and a clean install baseline for every capability, so intentional edits are visible and accidental drift is not silent. A check command can fail CI when tracked capabilities are not in the expected state. Capabilities can come from a local directory, a Git repository, an OCI registry or the built-in MCP catalog, and project-scoped ones take precedence over global ones. Tuff can also bundle capabilities into a versioned pack published through OCI. An optional Tuff Console, which your team runs on its own server, shows what each project runs, what changed and which policy rules are not enforced. Where a harness cannot enforce a policy rule yet, the install is refused instead of assuming the rule applies. Install is through uv, brew, pip, cargo or a script.
Capabilities
- One tuff.toml manifest emitted per agent, including Claude Code, Codex, Cursor and OpenCode
- tuff.lock records source, version, scope and the clean install baseline
- Drift detection and CI checks that fail when tracked capabilities change unexpectedly
- Installs from local directories, Git, OCI registries or the built-in MCP catalog
- Packs: versioned bundles of capabilities published and pinned through OCI
- Self-hosted Tuff Console shows what every project runs, plus a CLI report of every installed capability, its source and policy status
When to use it
- Your team uses several coding agents and wants a single source of truth for their skills, hooks and MCP servers
- You want CI to catch unreviewed edits to agent configuration
- You want to ship a reviewed bundle of capabilities with your own agent runtime
