Branches and worktrees

cix is anchored to git rather than to a folder. The index knows which branch you're on, which commit it was built from, and which checkout you're working in — so the answers change when you switch branches, the way they should.

This is the part most code-search tools skip. Indexing a directory is easy; staying correct across branches is not.

The index is per branch

Queries are scoped to the branch your working tree is on. Read from a feature branch and you get that branch's picture, not main's.

That matters most when the two disagree. A function you deleted on your branch still exists on main, and an assistant that answers from main will confidently tell you about code you removed this morning.

An unindexed branch says so

If the branch you're on hasn't been indexed yet, cix does not quietly answer from a branch that has been.

It tells you the branch has no indexed snapshot, and says explicitly that it refused rather than answering from another branch. Your local results still come back — you get a partial answer with its coverage stated, instead of a complete-looking answer assembled from the wrong branch.

Even when a branch is indexed, cix checks that the snapshot it got back is labelled with the branch it asked for, and keeps the answer local if they disagree.

Worktrees stay on their own checkout

A git worktree shares its main checkout's remote, so the naive thing to do is treat it as the same project and read from the main checkout's files. cix doesn't. A worktree resolves to its own directory and its own branch.

So you can keep main open in one worktree and a feature branch in another, run an assistant in each, and neither reads the other's files.

Writes are scoped the same way: an edit made from a worktree is recorded against the branch that worktree is on.

Uncommitted work is visible

The index is built from committed code, which leaves a real gap while you're mid-change — the function your assistant reads can be the version from before your edit.

Two capabilities close it. One reads a file with the explicit intent of seeing your uncommitted version. The other makes every dirty and untracked file findable by symbol name, so work in progress shows up in search instead of being invisible until you commit.

See Understanding index state.

Answers carry the commit they came from

Every answer names the commit it was built from, and says whether it came from committed code or your working tree. When something looks wrong, that's the first thing to check — it usually turns out the index is a few commits behind rather than the answer being incorrect.

What this is good for

• Reviewing a branch — ask about the branch, get the branch.
• Parallel work in worktrees — one assistant per branch, no crosstalk.
• Long refactors — the further your branch diverges, the more the branch-scoping earns its place.
• Coming back to a branch — a structural summary of what changed since you last looked, anchored to commits rather than to a chat you no longer have.

Next: Working with collaborators.