1.6.0

One addition for notes open in more than one pane: you can now keep a pane where it is while you click through threads in the sidebar.

Keeping a pane still: selecting a thread scrolled every pane showing the note

With a note open in two splits, selecting a thread in the sidebar scrolled its passage into view in both of them, including the one you were writing in. 1.5.0 settled which pane a thread opens in, but there was no way to stop a pane from following along.

Right-click in a pane and check Don't follow selected comments. That pane still highlights the passage when you select a thread, but it doesn't scroll to it, and clicking a card's quote to jump to the passage goes to one of the other panes instead. If every pane on the note has opted out, they're all fair game again, so a jump always has somewhere to land.

The option only appears when the note is open in more than one pane (or in a pane that's already opted out, so you can always turn it back off). It lasts until the pane is closed or Obsidian restarts. (#41)

1.5.0

Suggested edits now work over Local REST API and MCP the whole way through: a script or assistant can suggest an edit, and accept or decline one, where 1.4.0 only let it read them. Two fixes for notes open in more than one pane round it out. As with 1.4.0, the API features need Local REST API 5.3.0 or later.

At a glance

Features

• Suggesting edits over REST and MCP — a script could comment on a passage but not suggest replacing it
• Accepting and declining over REST and MCP — deciding a suggestion was Obsidian-only

Bug fixes

• Sidebar threads open in a predictable pane — which split moved came down to focus timing
• Re-anchoring from any pane — a selection in any pane but the first was ignored

---

Features

Suggesting edits over REST and MCP: a script could comment on a passage, but not suggest replacing it

The problem: suggested edits could be read, replied to, edited and deleted over the API, but not created. Worse, a POST that carried type: "suggestion" and an x_suggestion was answered with a 201 and quietly wrote a plain comment, so the caller had no way of knowing it hadn't gotten what it asked for.

What's new: POST …/comments/ and comments_add take an optional replacement. With it, the new thread is a suggested edit, written exactly as the sidebar would write it; text becomes its optional explanation, and an empty replacement suggests deleting the passage. It's anchored by quote and occurrence the same way a comment is.

{"quote": "the three options", "replacement": "these three options", "text": "Reads better", "author": "Claude"}

A body carrying type or x_suggestion is now refused with a 400 that points at replacement, rather than accepted and ignored. If you had a script sending those, it was already getting plain comments; now it'll hear about it.

Accepting and declining over REST and MCP: deciding a suggestion was Obsidian-only

The problem: even once a suggestion could be added from outside, there was no route for accepting or declining one, and PATCH refuses to resolve a suggestion's thread. Someone had to open Obsidian and press ✓ or ✗.

What's new: POST …/comments/<id>/accept and POST …/comments/<id>/decline, with the matching comments_accept and comments_decline MCP tools. Accepting replaces the passage with the suggestion's replacement and records it as accepted; declining records it and leaves the note alone. Both follow your resolved threads setting, keeping the suggestion as resolved history or removing its thread, and both return the suggestion as it's recorded now (or null if its thread was removed).

When the note is open in an editor, accepting edits it through that editor, so Undo works there just as it does after the sidebar's ✓. When it isn't open, the file is written directly. Either way, accepting changes nothing if the passage can't be found, appears more than once, or no longer reads the way it did when the suggestion was made; these are the same checks the sidebar makes. The text is checked again right before it's replaced, so an edit that lands in between makes the request fail rather than get overwritten.

Bug fixes

• With a note open in more than one pane, clicking a thread in the sidebar moved whichever pane happened to win on focus timing, usually the first one. The sidebar now sticks to the pane you last worked with comments in (where you last added a comment or suggestion, clicked a highlight, or showed a thread), so you can write in one split while clicking through threads in the other. (#35)
• "Re-anchor to selection" only saw a selection made in the first pane showing the note; select the new passage in any other and it asked you to make a selection first. It now uses whichever pane has one, preferring the pane you were just in. (#37)

1.4.0

Scripts and AI assistants can now read and write Sidemark comments through Local REST API, without touching a note's .review.yaml sidecar: as REST routes on every note, as MCP tools, and as a live stream of comment events. All of it needs Local REST API 5.3.0 or later; without it, Sidemark works exactly as it did in 1.3.1.

At a glance

Features

• Comments over REST — the only way for a script to comment on a note was to edit its sidecar YAML by hand
• Comments as MCP tools — an assistant connected to Local REST API's MCP server couldn't see or write comments
• Comment events — finding new comments meant re-reading every sidecar on a timer
• Comment routes in the OpenAPI spec — the new routes would have been missing from Local REST API's docs

---

Features

Comments over REST: a script could only comment by editing the sidecar

The problem: Sidemark keeps comments in a sidecar next to each note, in MRSF's YAML format. Anything outside Obsidian that wanted to leave a comment, reply to one, or resolve a thread had to read and rewrite that YAML itself, and get the anchoring fields (the quoted text, its position, its hash) right on its own. Nothing checked its work.

What's new: with Local REST API installed, every note has a comments sub-resource, at /vault/<note>/comments/ and /active/comments/:

Request	Does
GET …/comments/	Lists the note's threads, with where each one's passage is now. ?resolved=false or ?resolved=true filters them.
GET …/comments/<id>	Returns the comment and its thread.
POST …/comments/	Adds a comment on the passage you quote.
POST …/comments/<id>/replies	Adds a reply.
PATCH …/comments/<id>	Edits a comment, or resolves or reopens its thread.
DELETE …/comments/<id>	Deletes a thread, or a single reply.

curl -k -X POST -H "Authorization: Bearer <api key>" -H "Content-Type: application/json" \
  --data '{"text": "Consider a table here", "quote": "the three options", "author": "Claude"}' \
  "https://127.0.0.1:27124/vault/Projects/Plan.md/comments/"

A comment is anchored by quoting the passage it's about. A quote that isn't in the note is refused (422), and one that appears more than once is refused (409) with the number of matches until you add "occurrence" to pick one. An edit can carry "expected_text" so that it's refused if someone changed the comment first. Every write goes through the same code as the sidebar's, so requests queue behind your own edits, show up in the sidebar as they land, and are never written to a sidecar Sidemark can't parse.

Suggested edits are listed with the other threads but can only be accepted or declined in Obsidian, since that changes the note itself.

Comments as MCP tools: an assistant couldn't see or write comments

The problem: an AI assistant connected to Local REST API's MCP server could read and edit your notes, but a note's comments were invisible to it unless it went looking for the sidecar and edited the YAML.

What's new: the same six operations are MCP tools: comments_list, comments_get, comments_add, comments_reply, comments_update, and comments_delete. Each takes the note's vault path as path, and otherwise takes and returns what the REST routes do. A request the REST API would refuse comes back as a tool error with the same explanation, so the assistant can correct it and try again. A path that isn't an existing Markdown note is refused too, rather than creating a sidecar for a note that isn't there.

Describing these tools to the MCP server needs the zod library, which makes the plugin about 130 KB larger.

Comment events: finding new comments meant polling

The problem: a script that wanted to react to a new comment or reply had to re-read the note's comments on a timer and compare them with what it saw last time.

What's new: Sidemark's comment events can be followed through Local REST API's event streams: comment-added, comment-edited, comment-resolved, comment-reopened, and comment-deleted, subscribed to at POST /events/sidemark/<event>/. Each sends the note's path, the comment's id, its thread, and the comment's author, timestamp, and text.

Events come from comparing a note's comments before and after each change, not from the places Sidemark itself changes them. So a comment that arrives by sync, from the mrsf CLI, or from someone editing the YAML is reported exactly like one added in the sidebar. The one gap: the first outside change to a note whose comments Sidemark hasn't read yet since Obsidian started isn't reported, because there's nothing to compare it with. Every change after that is.

Comment routes in the OpenAPI spec: the new routes would have been undocumented

Local REST API serves an OpenAPI description of its routes at /openapi.yaml and /openapi.json, which documentation tools and client generators read. Sidemark's comment routes are described there now, under the Sidemark Comments tag, with their request bodies, responses, and every error they can send.

1.3.1

Comment text in the sidebar can be selected now, so you can copy a comment or quote part of one in your reply.

Obsidian sets user-select: none across its interface, and the sidebar never turned it back on, so dragging across a comment selected nothing — quoting someone meant retyping what they'd written. Comment text in an open thread, both the root comment and its replies, is now selectable.

A collapsed card isn't. Its text is a two-line faded preview, and the whole card is a click target that opens the thread, so a drag across it would fight with that. In an open thread, a drag that ends inside a card no longer scrolls the note to the thread's passage — a drag finishes with a click, and a click on a card means "show me this passage" — while a plain click still does. Double-clicking a comment opens it for editing, so double-click-to-select-a-word doesn't work there; drag or shift-click instead.

1.3.0

Sidemark now shows which comments you haven't read yet. That's most useful when someone else, or an AI assistant, is commenting on your notes. Selecting a thread also scrolls the note smoothly to its passage, and comments are shown in your note's text font.

At a glance

Features

• Unread comments — nothing showed which comments had arrived since you last looked
• Smooth scrolling to a thread's passage — selecting a thread left partly visible passages cut off, and jumped to the rest
• Comments in your text font — comments used the interface font, not the one you chose for notes
• A ⋯ menu in the sidebar's header — "Show resolved" was a text button

Bug fixes

• Code in comments ignored your monospace font

---

Features

Unread comments: nothing showed which comments had arrived since you last looked

The problem: Sidemark picks up changes to a sidecar as they happen, whether from sync, another device, or an AI assistant writing to it. But a new comment looked exactly like the ones you'd already read. The only way to find a new reply was to open every thread and compare it with what you remembered.

What's new: comments by other people that you haven't read yet are marked:

• A thread with unread comments shows a dot and a bold author name while it's collapsed. When only its replies are new, its badge says how many ("2 new").
• A count next to "Comments" in the sidebar's header says how many threads have something unread. Clicking it scrolls to the next unread thread that isn't already on screen and briefly outlines it, without opening it. The header now stays in place as the list scrolls, so the count is always visible.
• Opening a thread marks it read. A New line above the first new reply shows where you left off, and it stays until you close the thread.
• Each thread's ⋯ menu has Mark as unread, and the header's has Mark all as read.

Your own comments always count as read. So does every comment that existed before you updated, so you won't start with every thread marked new.

What you've read is kept in the plugin's settings (data.json), not in the sidecar, which is shared with everyone reviewing the note. So it's yours alone, and it syncs between your devices along with your plugin settings. If two devices change it before syncing, they're merged: a comment read on either device counts as read. Only threads with comments from other people are recorded, and entries are removed when their thread is resolved or deleted or their note goes away. So the record stays much smaller than the comments themselves.

Smooth scrolling to a thread's passage: partly visible passages stayed cut off

The problem: selecting a thread in the sidebar scrolled the note only as far as the first line of its passage. A passage cut off at the bottom of the editor stayed cut off. A longer one could have most of its lines out of view, and the scroll was an instant jump.

What's new: if the passage is already fully on screen, the note doesn't move. Otherwise the note scrolls smoothly until the passage sits in the middle of the editor, or until its first line is near the top if it's too tall to fit. If you scroll yourself or pick another thread partway through, the scroll stops following. With reduced motion turned on in your system settings, it jumps instead.

Comments in your text font: comments used the interface font

The sidebar used Obsidian's interface font for everything, including the comments. Comment text, the passage a comment quotes, a suggestion's change, and the boxes you write in now use the font from Appearance → Text font. That's the one your note uses, and it goes with 1.2.0's change to match the note's font size. Names, times, badges and buttons keep the interface font.

A ⋯ menu in the sidebar's header: "Show resolved" was a text button

The header's "Show resolved" / "Hide resolved" button is now a ⋯ menu in the same place, like the ones on each thread. Show resolved threads is in it, with a checkmark while resolved threads are shown, and so is the new Mark all as read.

Bug fixes

Code in comments ignored your monospace font

Obsidian applies the monospace font you choose only inside rendered notes, and a comment in the sidebar isn't one. So inline code and code blocks in comments were monospace only because of the browser's default style, in its generic monospace font. They now use the font from Appearance → Monospace font.

1.2.0

A comment made on the wrong passage can now be moved, the sidebar works at any width Obsidian allows, and an open thread reads at the same size as your note. This release needs Obsidian 1.13.1 or newer (see the end of these notes).

At a glance

Features

• Re-anchor a thread — a comment on the wrong passage couldn't be moved
• Open threads at your note's font size — comment text and text boxes were smaller than the note
• Settings reorganized — settings grouped by where they show up

Bug fixes

• Narrow sidebars — a card's buttons could end up outside the card, where they couldn't be clicked
• Comments written by Claude were given made-up times — replies could be listed above the comment they answer
• Growing text boxes grew a line early — an empty line appeared near the end of each line
• A new comment's card was always at the top — even when its passage was further down the note

---

Features

Re-anchor a thread: a comment on the wrong passage couldn't be moved

The problem: A thread stays attached to the passage it was created on. If you highlighted the wrong text when you started a comment, the only fix was to delete it and write it again. Moving a thread was only offered as a button on threads whose passage had been lost, and to use it you had to select the new text first. Clicking into the note to do that moved the cursor out of the thread's highlight, which deselected the thread, so its card collapsed and the button disappeared.

What's new: Every open thread's ⋯ menu has Re-anchor…. Choose it, select the new passage in the note, then click Re-anchor to selection on the card. The thread stays selected in the sidebar while you pick the text, however you move around the note. Cancel, Esc in the sidebar, or clicking another thread leaves it where it was. The button on threads with a lost passage now starts the same process.

Re-anchoring replaces the thread's original quote (selected_text) along with its position. That's the one case where Sidemark rewrites the quote, because you're telling it the original was wrong.

Open threads at your note's font size: comment text and text boxes were smaller than the note

The problem: Sidemark didn't set a size for comment text, so the sidebar used Obsidian's interface sizes: 15px for text and 13px for text boxes, against 16px for a note by default. Those sizes also ignore the font size slider under Appearance, so if you'd made your notes bigger, the gap got bigger with them.

What's new: A selected thread's text, its suggested change, and every text box (new comment, reply, edit) use your note's font size, and follow the slider like the note does. Unselected cards keep the smaller size, so the list stays compact.

Settings reorganized: settings are grouped by where they show up

The settings tab now uses Obsidian 1.13's settings API. Its sections are named for where each setting takes effect: In the note, In the sidebar, Resolving and deleting, and Tools. Nothing was added or removed, and your saved settings carry over as they are. This change is why the release needs Obsidian 1.13.1.

Bug fixes

Narrow sidebars: a card's buttons could end up outside the card

A card's header put the author, the time and the buttons on one line that couldn't shrink. Once that line was wider than the card, the buttons were drawn past the card's edge, where nothing scrolls, so they couldn't be clicked. At Obsidian's minimum sidebar width (200px) every card lost all of its buttons. An expanded suggestion also lost two of its three at the default width, and a card whose author name was an email address lost them at every width up to 500px.

A long name now shortens with an ellipsis. When the line doesn't fit, the time and badges move to a second line under the name and buttons. Each card switches layout based on its own width, measured against Obsidian's own stylesheet: at 200px through 500px, no button is cut off any more. Above about 340px the header looks exactly as it did before. (#14)

Comments written by Claude were given made-up times

The sidebar sorts a thread's replies by their timestamps. When the sidemark-comments skill had Claude write comments into the sidecar file itself (instead of through the mrsf tool), the time was estimated: rounded to the minute, padded with .000, and only roughly "now". So a reply could be listed above the comment it answered. The skill now tells Claude to run date -u right before writing and use the result exactly. If it can't read the clock at all, it uses one second after the thread's newest comment, which keeps the order right.

To get this, press Install skill again under Settings → Tools → Claude Code skill. The skill file is only written when you press that button, so updating the plugin doesn't update your installed copy. (#18)

Also fixed

• A text box that grows as you type grew a line early, leaving an empty line under the text for roughly the last dozen characters before each wrap. Measuring the box briefly gave it a scrollbar, which made the text narrower than it really is. The box is now measured at the width it's shown. (#21)
• The card for a new comment or suggestion was always placed at the top of the sidebar, then jumped to its real place once saved. It now starts where the saved thread will appear, based on where its passage is in the note, or on the order you've chosen in Sort threads by. (#20)

---

Requires Obsidian 1.13.1

The reorganized settings tab uses an API added in Obsidian 1.13, so Sidemark 1.2.0 needs Obsidian 1.13.1 or newer. If you're on an older Obsidian, the community plugin browser keeps offering you 1.1.0, which works as it always has. Nothing changes in your comments or sidecar files.

1.1.0

Two additions since 1.0.0, both about getting out of your way: the sidemark-comments skill for Claude Code now installs from Sidemark's settings panel instead of being copied in by hand, and the sidebar's text boxes size themselves to what you've written.

Features

Installing the Claude Code skill: the one piece of Sidemark you had to fetch yourself

The problem: Sidemark keeps comments in a sidecar so things other than Obsidian can take part in a review, and for Claude Code that means the sidemark-comments skill — without it, an assistant pointed at a .review.yaml has no idea what it's looking at. Getting the skill meant cloning coddingtonbear/skills, finding SKILL.md in it, and copying that file into ~/.claude/skills/sidemark-comments/ yourself. The plugin shipped everything else needed to use Sidemark; this was the exception.

What's new: Settings has a Claude Code section with an Install skill button. Pressing it writes ~/.claude/skills/sidemark-comments/SKILL.md, creating the directory if it isn't there and replacing that file if it is, and nothing else on your machine is touched. Claude Code picks the skill up on its next run.

It's a button rather than something the plugin does on install, because that path is outside your vault and a plugin has no business writing there on its own. It's desktop-only for the same reason — mobile Obsidian can't reach a home directory — so the section doesn't appear there.

Comment boxes that grow with their text: every box was two or three lines tall

The problem: The text boxes in the comment sidebar were a fixed height — a couple of lines each for a new comment, a reply, an edit to a comment, and a suggestion's replacement and explanation. Anything longer than a sentence or two scrolled inside a small box, so writing a paragraph meant either working through a keyhole or dragging the box's corner open first, on every box, every time.

What's new: The boxes fit themselves to their contents as you type, and shrink back as you delete. A box that opens with text already in it — editing an existing comment, or a replacement pre-filled with the passage you selected — starts at the size that text needs. Growth stops at 40% of the window height, past which the box scrolls as it used to, so a long comment can't push the rest of the card off screen. The resize handle still works if you want a particular size in the moment; the next keystroke fits the box to its text again.

1.0.0

Sidemark's first release: Google Docs-style comments and suggested edits for Obsidian, with the comments stored next to each note instead of inside it. Sidemark is an unofficial fork of Leon Pawelzik's Tandem Comments, whose editor and sidebar it builds on; what's different is where the comments live and what can read them.

At a glance

• Comments live in a sidecar file — notes no longer carry comment data
• A format other tools already speak — VS Code, the mrsf CLI and AI assistants read and write the same comments
• Suggested edits you can read in place — replacements and deletions shown word by word in the note, accepted or declined without leaving it
• Comments that keep up with your edits — highlights follow the text, and moved or deleted passages are flagged instead of lost
• A calmer comment panel — compact threads, one place for every decision, and selection that works in both directions
• Renames and deletes — a note's comments move and go to the trash with it
• Converting from Tandem Comments — existing tandem-comments blocks move into sidecars

---

Features

Sidecar storage: comment data lived inside the note

The problem: Commenting plugins for Obsidian generally store their data in the note itself, as hidden HTML, CriticMarkup, or (in Tandem Comments' case) a JSON block at the end of the file. The prose stays readable in Obsidian, but every other place the file goes (git diffs, publishing, sync, other editors, a search across your vault) sees the comment data too, and resolved discussions accumulate in the note unless they're deleted.

What's new: Comments are saved to a sidecar next to the note, Your Note.md.review.yaml, and the note itself is never modified to hold them. Resolved threads are kept there as history by default, since they no longer cost the note anything. When Sidemark writes a sidecar, the parts it didn't change keep their formatting and YAML comments, and a sidecar it can't fully parse is shown as an error and left alone rather than rewritten.

If you use Obsidian Sync, turn on syncing of "other file types" so the .review.yaml files travel with your notes.

A shared format: comments could only be read by the plugin that wrote them

The problem: Each commenting plugin has its own storage, so a review written in Obsidian stays in Obsidian, and an AI assistant or script that wants to take part has to learn that plugin's private format (or be handed an export).

What's new: Sidecars follow the Markdown Review Sidecar Format (MRSF, "Sidemark"), an open specification that other tools already implement: the Sidemark VS Code extension, the mrsf command-line tool, and the @mrsf/mcp server for AI assistants. Anything those tools write shows up in Obsidian immediately, and edits to the note or its sidecar made outside Obsidian (sync, git, an assistant) are picked up live. For example, from the vault root:

npx @mrsf/cli add "Projects/Plan.md" -a "Claude" -t "Consider a table here" -l 12 --selected-text "the three options"

Sidemark's own additions (context around each quote and suggested edits) live in x_ extension fields, which the spec requires other tools to preserve. Two deliberate deviations from the spec are documented in the README: comment text is rendered as Markdown (so [[wikilinks]] work), and resolving a thread resolves its replies too.

Suggested edits: proposing a change meant describing it in a comment

The problem: Without suggestions, proposing a rewording meant writing the new text into a comment and having the author copy it over by hand, and there was no way to see the proposed wording in the context of the note.

What's new:

• Replace or delete: select text, choose Suggest edit, and write the replacement. Leave it empty to suggest deleting the text.
• Shown in the note: open suggestions strike out only the words that would change and show the new words right after them, including inside tables. This only happens while the passage still reads as it did when the suggestion was made. The Show suggestions in the note setting turns it off.
• Decided from wherever you are: hover a suggestion for ✓/✕ buttons, use the ✓/✕ on its card, or bind Accept current suggestion, Decline current suggestion, Go to next suggestion and Go to previous suggestion to hotkeys. Accepting rewrites the passage in the note, and deleting a word between two spaces doesn't leave a double space behind.

A suggestion is only accepted when its passage still matches exactly and appears once; otherwise ✓ is dimmed and says why, and Re-anchor to selection points it at the right text. Undoing an accepted suggestion restores the note's text but leaves the suggestion marked accepted; reopen it from Show resolved to act on it again.

Anchoring: comments drifted or vanished when the text around them changed

The problem: A comment is only useful while it's attached to the text it's about, and that text is exactly what a review changes.

What's new: Highlights follow the text as you type (tables included), and their positions are saved to the sidecar as you go. Comments are anchored by their quoted text, with its position and a little surrounding context to tell identical quotes apart. When the commented text itself is edited, the card shows what it now reads while the sidecar keeps the reviewer's original selection. A comment whose passage was deleted is listed as orphaned rather than dropped, and Re-anchor to selection attaches it to new text.

The comment panel: every thread was shown in full, and decisions lived in different places

The problem: A note with a handful of discussions turns into a long panel of full threads and reply boxes, and in Tandem Comments resolving a comment and accepting a suggestion used different controls in different parts of the card.

What's new:

• Compact threads: only the selected thread is shown in full. The others show the author, a short time, a reply count and the start of the comment, and fade back while a thread is selected. Cards ease open and closed.
• One place for decisions: every card has the same controls in its top-right corner: ✓ resolves a comment or accepts a suggestion, ✕ declines a suggestion, ↺ reopens a resolved thread.
• Selection in both directions: clicking a highlight (or moving the cursor into it) selects its thread, and selecting a thread highlights its passage in the note without moving your cursor. Cards can also be selected from the keyboard.
• Comment text is Markdown, so [[wikilinks]] are clickable and show hover previews.

Renames and deletes: comments stored outside a note could be left behind

The problem: A sidecar is only useful if it stays with its note.

What's new: Renaming or moving a note (or a whole folder) moves its sidecar and updates the note path recorded inside it. Deleting a note moves its sidecar to the trash along with it, following your trash setting. If a renamed note's new path already has a sidecar, nothing is overwritten and you're told.

Converting from Tandem Comments: existing comments were in a different format

The problem: Comments written with Tandem Comments live in a tandem-comments block inside each note, which Sidemark doesn't read.

What's new: Settings → Migration → Convert tandem-comments blocks (also available as a command) moves every note's block into a sidecar: threads, replies, resolved state and suggestions included. Each note's block is removed only after its sidecar has been written and read back successfully; notes whose blocks can't be read are left untouched and reported, and re-running the conversion skips threads it has already copied.

---

Before you install

• Reading view shows no highlights yet; comments appear in the sidebar and in Live Preview and Source mode.
• Sidecars are always stored next to their notes. MRSF's sidecar_root setting isn't supported yet.
• Export is a command only (Export comments of active note). It writes <Note> – Comments.md next to the note, opens it, and replaces an earlier export each time.