Which package do I want?
All three packages use the same underlying library, so all three enforce the same safety guards. The only difference is how you call in.
| If you… | Install this |
|---|---|
| Run an AI coding agent (Claude Code, Cursor, VS Code, OpenCode) and want it to manage worktrees safely | iso-code-mcp |
Want a wt command in your terminal or shell scripts | iso-code-cli |
| Are writing a Rust tool that needs to create, list, or delete worktrees | iso-code |
Prerequisites
- Rust 1.75+ — if you don't have it:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh - Git 2.20+ — 2.36 or newer gets you the fastest
porcelain -zpaths - macOS or Linux — Windows works via junctions but is still tier-2
That's it. No daemons, no background service, no database.
1Path A — Agent user (MCP)
Install the server:
cargo install iso-code-mcp
Then point your agent at it. Pick the config that matches your tool:
Claude Code
// ~/.claude.json
{
"mcpServers": {
"iso-code": {
"command": "iso-code-mcp",
"args": []
}
}
}
Cursor
// .cursor/mcp.json
{
"mcpServers": {
"iso-code": { "command": "iso-code-mcp" }
}
}
VS Code
// .vscode/mcp.json
{
"servers": {
"iso-code": { "type": "stdio", "command": "iso-code-mcp" }
}
}
OpenCode
// opencode.json
{
"mcp": {
"servers": {
"iso-code": { "type": "local", "command": ["iso-code-mcp"] }
}
}
}
Restart your agent. Now ask it:
"Create a worktree for a new branch called feature/try-isocode, then delete it."
The agent will use worktree_create and worktree_delete for that prompt. The full tool set is worktree_list, worktree_status (branch, state, disk usage per worktree), worktree_create, worktree_delete, and worktree_gc — every call goes through the same safety guards as the library and CLI.
2Path B — CLI user (wt)
Install the CLI:
cargo install iso-code-cli
Then run a full lifecycle against a repo you already have:
cd /path/to/your/repo # List — should show just your main worktree wt list # Create — makes a new worktree one level up wt create feature/try-isocode ../try-isocode # Verify it exists wt list # Clean it up — runs the 5-step unmerged-commit check first wt delete ../try-isocode
That's the whole lifecycle. The commands you'll use day-to-day are list, create, delete, and gc (run with --run to actually evict; default is a dry-run preview).
3Path C — Rust library
Add the crate:
cargo add iso-code
Minimal program:
use iso_code::{Manager, Config, CreateOptions, DeleteOptions};
fn main() -> Result<(), Box<dyn std::error::Error>> {
let mgr = Manager::new("/path/to/your/repo", Config::default())?;
let (handle, _) = mgr.create(
"feature/try-isocode",
"/tmp/try-isocode",
CreateOptions::default(),
)?;
for wt in mgr.list()? {
println!("{:?}", wt);
}
mgr.delete(&handle, DeleteOptions::default())?;
Ok(())
}
Build and run it with cargo run. Same safety guards, same state file on disk — the CLI and MCP server are thin wrappers around exactly this API.
What just happened
That last delete call — whichever path you took — ran these checks before removing anything:
- Unmerged-commit check — five comparisons against the branch's upstream. If any commit isn't in the upstream, delete refuses unless you pass
force: true. - Symlink-safe recursion — if the worktree has a pnpm
node_moduleswith thousands of symlinks into a shared global store, those symlinks are removed without following into the store itself. - Atomic state update —
state.jsonis written to a temp file, fsynced, then renamed. If your machine crashes mid-delete, you're left either fully in or fully out, never half. - Git reconciliation — next
listcomparesgit worktree list --porcelainagainststate.jsonand corrects any drift. Git is always authoritative.
None of this needed configuration. Safe by default is the whole point.
wt delete against it. You'll get unmerged commits on 'your-branch': N commit(s) not in upstream — use force to override, and the worktree directory stays on disk.
Where to go next
- Safety guarantees — the full list of what iso-code protects against
- Command reference — every
wtsubcommand with flags - docs.rs/iso-code — full Rust API
- Test methodology — how v0.1.1 was validated against five real-world repos
- FAQ — common questions, answered
- GitHub — source, issues, releases