What it changes on your machine

Every file Repolane creates or edits, inside the workspace and outside it, and how to remove all of it.

In brief. This page lists every file Repolane creates or edits, inside the workspace and outside it, and how to remove all of it. The package lives where pipx or uv put it. Outside the workspace Repolane writes only to ~/.local/share/lane and ~/.claude/projects, and it asks before it changes anything under ~/.claude. It never touches your shell profile, global git config or global Claude settings. There is no lane uninstall; Undoing it is the manual sequence.

Repolane sits between you and every repo you own, so the whole list of what it touches fits on one page. The list is read from the scripts and checked by running them against a scratch home directory.

There are three places to know about: the package (Repolane’s own files, installed once per machine), the workspace (your folder, where nearly everything is written), and two folders in your home directory: ~/.local/share/lane and ~/.claude/projects. The last one is Claude Code’s own data folder, and several commands add to, link into or delete from it.

The package

pipx install repolane (or uv tool install repolane) puts the package in its own virtual environment and links its commands into ~/.local/bin: lane, the long names (lane-start, lane-run, lane-memory, …) and guard-check, 28 in all. That is pipx’s or uv’s doing, and pipx uninstall repolane (or uv tool uninstall repolane) removes it. Repolane never writes into the package’s folder at run time; lane upgrade replaces it.

Commands run through the lane scripts (including anything you start with lane run) inherit three environment variables from .repolane/env.sh: WS_HOME (the workspace’s path), NX_CACHE_DIRECTORY ($WS_HOME/.repolane/cache/nx) and NX_DAEMON=false. They only matter to Nx projects. env.sh is yours: Repolane writes it once, when the workspace is made.

Outside the workspace

The slug is the absolute path with every character other than a letter, digit or - turned into -. lane init --claude-home <dir> (or CLAUDE_HOME) changes where the symlinks are made. With no terminal and no --yes, lane init and lane add change nothing under ~/.claude and print the commands instead. A link you said no to is recorded in .repolane/declined.json and not offered again; lane doctor --fix offers it once more.

Keep the workspace at a plain path. Claude Code applies the same rule: for a folder named .boardshot, its own project folder is named …--boardshot…. A path with unusual characters is the likeliest place for a computed name to differ from Claude Code’s, which leaves a memory symlink pointing at a folder Claude Code is not using. Use letters and digits, with - or _ between words.

Two details that surprise people.

• If a real memory/ folder already existed at one of those ~/.claude/projects/… paths, lane init and lane add copy its notes into the workspace (nothing is overwritten), and then put the symlink in its place.
• lane init, lane add, lane done and the SessionEnd hook are the only things here that remove or rename anything in Claude Code’s own data.

What Repolane does not touch: your shell profile, your global ~/.claude/settings.json, your global git config, anything in /usr/local, and any checkout you adopted with lane add <path>. It does mark an adopted checkout as an “old checkout” in .repolane/registry/old-checkouts.json, which makes the guard refuse sessions access to that path. See Install.

lane init

Inside the folder it creates what is missing and keeps what is there.

Outside the workspace: the planes.json entry and the memory symlink (above).

lane add

Inside: .repolane/repos/<name>/ (a clone, or a copy of an existing checkout’s .git plus a few ignored files, see Install), an entry in .repolane/registry/repos.yaml, .repolane/registry/old-checkouts.json when you adopt a checkout, and .repolane/memory/<name>/MEMORY.md. If you ask it to deny candidate secret files, it also writes deny rules into .repolane/registry/rules.yaml. Outside: the memory symlink above.

lane start, lane with and lane resume

All three write the same set of things, inside the workspace:

• lanes/<id>/<repo>/: a git worktree per repo, on branch <id> (or the branch you named). The branch is created in .repolane/repos/<repo>, and its .git/worktrees/ records the worktree.
• .repolane/registry/lanes/<id>.md: the lane file.
• At the lane root: an empty anchor .git (so git does not claim the folder for a repo above it; it sets core.hooksPath to /dev/null and lane.anchor in that anchor repo only), a .gitignore of *, a CLAUDE.md that points at the lane file and memory, and <id>.code-workspace.
• .claude/settings.local.json in the lane root and in each worktree. They hold deny rules (the common secret file names, such as .env*, *.pem, *.key, *.p12, id_rsa, .netrc, .npmrc and service-account*.json; *credentials*.json and secrets.* are covered by the guard but not by this list), a short list of pre-approved read-only commands, additionalDirectories, autoMemoryDirectory and the lane hook … wiring. The workspace root gets one too, holding only additionalDirectories; its hooks are in .claude/settings.json.
• One line, .claude/settings.local.json, appended to the base clone’s .git/info/exclude (git’s shared exclude file for that repo), so the file never shows in git status.
• Symlinks for env files from the base clone into each worktree.
• lane.code-workspace at the workspace root, listing every active lane.

lane resume <id> also runs git worktree prune in every base clone before recreating anything.

What the hooks write inside the workspace

All under .repolane/cache/: last-session-start.json (the raw SessionStart input, overwritten each time), sessions/<id>.json (per-session state the guard reads back), transcript-moves.log (the SessionEnd rename log) and memory-inbox/ (drafts waiting for lane note file). In a lane, .touched is appended to by the PostToolUse hook. The first lane command or hook after the installed version changes writes .repolane/REPOLANE.md, LANE.md and version again. A session can write to the cache itself; see the security model.

lane park and lane done

lane park commits every dirty worktree of the lane and edits the lane file. It stages by explicit literal path and leaves out files whose name says secret (the guard’s list), which stay on disk and are named in its output; everything else that is not git-ignored is committed, including a credential under an ordinary name. lane done removes each worktree and then the lane folder (so files git ignores, such as build output, go with it; a real ignored or untracked secret-named file blocks the finish unless you pass --discard-ignored), optionally deletes branches (--delete-branches), optionally deletes Claude’s saved sessions for each worktree, and moves the lane file to .repolane/registry/lanes/done/.

Undoing it

There is no lane uninstall command. Run these in order.

1. Get your work out first. The worktrees under lanes/ are real git worktrees with real branches. Push anything you care about, or lane done <id> each lane. lane done refuses to archive one that is dirty, unpushed, or holds a secret-named file the deletion would destroy; a local-only repo (no origin) counts as having nothing to push (see Troubleshooting).

2. Unlink the memory folders. From inside the workspace. Each is a symlink, so removing it never deletes what it points at. Copy .repolane/memory/ somewhere first if you want the notes:

cp -R .repolane/memory ~/memory-backup     # optional
for l in ~/.claude/projects/*/memory; do
  [ -L "$l" ] || continue
  case "$(readlink "$l")" in "$PWD"/.repolane/memory|"$PWD"/.repolane/memory/*) rm "$l" ;; esac
done

This leaves the ~/.claude/projects/<slug>/ folders themselves, which hold your Claude Code conversations. They are Claude Code’s data and yours to keep or delete, and some of them may be empty.

The case compares each link’s target with $PWD, as a string. If you reach the folder through a symlinked path (macOS’s /tmp is one, and so is anything under a symlinked home), the link target and $PWD can spell the same place differently and the loop silently matches nothing. Run cd "$(pwd -P)" first, or print readlink ~/.claude/projects/*/memory and remove the ones that point into this folder by hand.

3. Delete the workspace, or keep it. rm -rf on it takes the base clones, the worktrees, the lane files and the hook configuration with it. If you made it a git repo of your own and pushed it, that remote is not touched. To keep your notes but stop using Repolane in that folder, delete only lanes/ and .repolane/repos/ and take the lane hook entries out of .claude/settings.json and the import line out of CLAUDE.md.

4. Remove the package and the registry.

pipx uninstall repolane        # or: uv tool uninstall repolane
rm -rf ~/.local/share/lane     # the list of workspaces, and any lane migrate backups

Deleting ~/.local/share/lane forgets every workspace on the machine (they stay on disk) and deletes the backups lane migrate wrote, so keep a backup you may still want to undo from. To forget just one workspace, run lane upgrade after deleting that folder: it reports the missing folder and asks whether to drop it from the registry.

If you remove the package but keep a workspace, Claude Code sessions started there have hooks that call a lane that is no longer on your PATH: every hook fails, and Claude Code runs the tools unguarded. Take the lane hook entries out of .claude/settings.json (step 3), or reinstall.

Repos you adopted from a checkout you already had are unaffected: lane add <path> copies the git database and never writes to the original.

If you only want the rules off and everything else left alone, you do not need to uninstall anything. See what to do when a rule blocks you.