How it works

Anchors

For decades, an IDE bookmark was essentially a filename and a line number — fine until the line moves. Agentic Bookmarks brings two advanced anchor types built for agentic workflows and long-lived team curation, so a pin stays put through edits, refactors, and merges.

Video coming soon

Which one should I use?

Smart — the default. Tracked through metadata only, with no changes to your code. Works great in both local and shared repos. Pick this unless you have a reason not to.
Tag. Drops a tiny comment in the code, which makes it the least-breakable option — but it does touch your source, which not every repo or team wants. Best for shared landmarks where an inline marker is welcome.
Point is the legacy filename-and-line model, off by default — see below.

Bookmarks default to smart anchors, but you choose the anchor type per bookmarks file. A local scratch file can stay on smart while a shared, git-tracked file uses tag (or smart) — whatever fits how that file is used.

Smart anchor

Default

Context-aware, code-untouching.

A smart anchor stores a line cache plus a variable amount of surrounding context, and uses that context to re-find its line as code drifts around it. Matching is adaptive and loose on purpose: small edits in or near the line don't force the stored data to rewrite, which is what makes smart anchors team-friendly when checked into git.

Under the hood, dynamic context blocks and our anchor chain technique — refined through real-world testing — keep the anchor attached even as code shifts around the line it points at. No comment, no code change, no marker in your source.

Best for

Almost everything — local and shared, solo and team.

Tag anchor

The source of truth lives in the code.

A tag anchor places a small comment on the line — something like // @bookmark:abc123. Because the marker travels with the code, maintenance is the simplest of any type: if the line moves, the marker moves with it. It's the least-breakable anchor standard we offer.

It does require a discreet edit to your source, which not every team wants. In exchange, tag anchors are uniquely good for cross-referencing — a tag is a stable handle you can quote in docs, PR descriptions, or chat, and the bookmark on the other end stays in sync.

Best for

Shared landmarks where an inline marker is welcome.

Point anchor

The legacy baseline.

A raw filename and line number with a small content cache. Some tools try to keep it sticky by watching edits and applying offsets, but that approach has nothing to hold onto when an agent rewrites or moves large spans in a single pass.

We keep point anchors disabled by default and use them only for internal dev testing.

Status

Disabled by default — internal testing only.

Smart + tag, together, cover the shared case

The two reasons bookmarks historically stayed personal were they broke when teammates edited and the data file churned on every neighboring change. Smart anchors answer both at once — durable against ambient edits, and quiet enough on disk to live in the repo without producing merge noise. Tag anchors complement them when a team is happy to have a small inline marker do the work instead.

When an anchor drifts

Code can always outrun an anchor. When that happens, repair is a layered system — quick manual relocation, mechanical auto-repair using git history and context search, and agent-assisted repair via MCP for the cases automation can't resolve on its own. The combination is what makes “check bookmarks into git” a viable workflow rather than a fragile one.

← Local vs. shared bookmarks