Plannotator v0.27.9 Download

Plannotator is an open-source platform designed to review and validate plans and code generated by AI coding agents.

The platform provides a centralized interface where developers can:

Review AI-generated plans
Annotate proposed actions
Approve or reject tasks
Inspect code changes
Provide structured feedback
Improve agent outputs
Maintain human oversight

Rather than replacing developers, Plannotator aims to keep humans involved in critical decision-making during AI-assisted development.

As AI coding agents become increasingly capable, developers face a growing challenge: ensuring that AI-generated plans and code changes align with project requirements before they are executed. Plannotator addresses this problem by acting as a review layer between developers and AI coding agents.

Instead of generating code itself, Plannotator focuses on making AI-driven development more transparent and controllable. It allows teams to review, annotate, approve, reject, and refine agent-generated plans and code changes before they affect a project.

Download Plannotator v0.27.9 - Software Mirrors
Plannotator v0.27.9 for Windows plannotator-paste-win32-arm64.exe \| 90.2 MB plannotator-paste-win32-x64.exe \| 93.92 MB plannotator-win32-arm64.exe \| 143.49 MB plannotator-win32-x64.exe \| 147.21 MB
Plannotator v0.27.9 for macOS plannotator-darwin-arm64 \| 114.22 MB plannotator-darwin-x64 \| 119.27 MB plannotator-paste-darwin-arm64 \| 60.51 MB plannotator-paste-darwin-x64 \| 65.97 MB
Plannotator v0.27.9 for Linux plannotator-linux-arm64 \| 142.6 MB plannotator-linux-x64 \| 143.5 MB plannotator-paste-linux-arm64 \| 89.35 MB plannotator-paste-linux-x64 \| 90.21 MB
Plannotator v0.27.9 for Other plannotator-0.27.9-release-sbom.cdx.json \| 1.6 MB
Plannotator v0.27.9 Release Notes: Follow @plannotator on X for updates Missed recent releases? v0.27.8: Pi keeps its prompt cache across plan transitions, thumbs-up returns to HTML annotation, embed picker seam v0.27.7: Pi host crash fix on Windows, Call Flow tree cap, jj fork-point base, plannotator knowledge skill + llms.txt v0.27.6: Live app annotation lands on Pi, one interaction model for HTML pages (same-day patch on v0.27.5) v0.27.5: Annotate your running app, Agent TUI placement, collapsed lockfiles, VS Code theme fix, Pi fixes v0.27.4: Portable Guided Review exports, guides.show share links, guide CLI, favicon switcher, jj Call Flow v0.27.3: Folder watcher freeze fix on large repos, first SBOM-attested release pipeline v0.27.2: Mobile plan and code review, Codex CLI 0.147 fix, folder annotate cold-start, configurable markdown extensions v0.27.1: Open-in-editor launch fix, file headers respect Viewed/Git-add visibility toggles v0.27.0: Call Flow analysis, --tailscale remote reviews, review panel remembers your view, Pi rebuild (breaking command rename), focus-mode shortcut v0.26.8: Placed comment markers on HTML pages, shift-click multi-select, live app annotation v0.26.7: Pinpoint targets any element on HTML pages, smarter hover labels, zero-scan hit testing v0.26.6: Fixed empty environment variables in sandboxed sessions (Bun 1.3.14 builds) What's New in v0.27.9 Eleven pull requests, one of them from @leoreisdias. Two threads run through the release. Browser-integrated agents can now read a plan or an annotate session and leave comments on it through WebMCP, instead of scraping the page. And the raw-HTML annotation surface gained a Refresh action along with a published set of seams so other applications can run that surface as Plannotator ships it. A Windows uninstall fix and a pre-release QA pass close it out. Browser agents can read your document and comment on it An agent that runs inside the browser, such as Codex's browser or Claude Code's browser, has until now had to work out what is on the page by reading the DOM. Plan review and every annotate surface (markdown, raw HTML, live app, folder) now register a small tool catalog on `document.modelContext`, the WebMCP surface those agents speak. The catalog is deliberately narrow. `read_document` returns the whole situation in one zero-argument call: the session, the document text windowed at 16k characters and cut at a block boundary, an outline with per-section comment counts, every comment with its quote and context, sibling documents, and a set of nudge codes. `add_comments` writes a batch, anchoring by an exact quote, by section, by reply, or as a document-level note, and is idempotent by request id. `update_comment`, `remove_comments`, `reveal` and `nudge_user` round it out, with `list_documents` in folder sessions. Three rules make this safe to ship without a consent dialog. Decisions stay with the human: no tool approves, denies, submits, closes, stages or marks anything viewed, and a test pins the catalog so none can be added quietly. An agent may edit or remove only the comments it created, which are stamped `browser-agent`; asking to touch a human's comment answers `forbidden`. And nothing is ever registered inside the sandboxed iframes, so a page you are annotating can neither see nor impersonate Plannotator's tools. Without the API there is no footprint at all. Feature detection is one `typeof` check per mount, and when `document.modelContext` is absent the catalog is never built and no indicator, banner, request or timer is created. That was verified rather than assumed: builds from main and from the branch served the same annotate session to a Chrome without WebMCP, and the rendered DOM (44,607 characters), the request lists, the console output and the timer counts came back identical on both sides. The nudges are what keep an agent in step with you. Every response carries codes computed from state the page already holds, so the agent learns on the call it was going to make anyway that you added a comment, that your composer is open, that the file changed on disk, or that the live app navigated to another page. A header indicator appears after the first tool call, and a Settings toggle turns the whole provider off and on. One product change comes with it. `Annotation` gains an optional `inReplyTo` field, so an agent can answer a comment you left. A reply inherits its parent's anchor, renders indented under it in the annotations panel, and exports nested under the parent as a `Replies:` block, which is what puts the exchange in front of the coding agent in order. Annotations without the field render and export byte for byte as before. Code review is phase 2 and is not in this release. #1393 by @backnotprop Refresh rendered HTML from disk Markdown annotate sessions pick up an agent's edits as soon as the file changes on disk. Rendered HTML sessions kept showing the snapshot they loaded at startup, so the review surface went stale the moment the agent rewrote the report you were reading. @leoreisdias added a Refresh action for local `.html` and `.htm` annotate sessions, next to Hide tools and reachable from the keyboard. It re-reads the document, remounts the sandboxed viewer, reapplies your annotations, and tells you how many anchors no longer match while keeping those comments in the panel. It is manual on purpose: this is the first checkpoint, and automatic filesystem-driven refresh waits until the restoration behavior has seen real use. URL sessions, archive views, markdown-converted HTML and non-HTML documents are unchanged, and HTML source saving stays off. Review turned up a share-link race that predated the feature. The share request context included the identity of the resolver, and that identity changes as a side effect of its own success, so the first short link created on an HTML session discarded its own result. That is fixed with a regression test. A browser verification run found two more: the singular toast read "1 annotation no longer match the HTML", and a browser reload after a refresh reverted the page to the startup snapshot because `/api/plan` never re-read disk while the draft annotations persisted against the replaced page. `/api/plan` and `/api/share-html` now share one root read on both server runtimes, so reload and refresh land on the same bytes. The version diff that a refresh used to cost you is back as well, recomputed rather than dropped. That fix arrived with the QA pass below. #1232 by @leoreisdias, with maintainer commits for the share race, the toast and the two-runtime root read The HTML annotation surface, packaged for hosts Applications built on `@plannotator/ui` were hand-rolling their own code around `HtmlViewer` to get the experience Plannotator ships. The Workspaces team asked for the seams to be published, and they now are. `HtmlSurfaceControls` gives a host the eye, the refresh and the pen with the exact markup, data attributes and aria state Plannotator's header uses, each control rendering only when its handler is passed. `useHtmlRefresh` publishes the refresh lifecycle with the backend behind a `fetchSnapshot` callback, so a host binds it to its own document store. `projectHostThreads` and `buildPersistedHtmlAnchor` in `@plannotator/core/html-anchor` project stored rows onto the annotations prop in the host's order, which is the marker numbering, and trim a composed comment's anchor for persistence within a byte budget. `AnnotationPanel` takes an `unanchoredIds` set and renders a small Unanchored chip on the matching cards. `HtmlViewer` takes `scrollBehavior` so a host can carry a reduced-motion preference across the iframe boundary, and `maxAdditionalTargets` for its own cap on shift-click targets. Every seam is additive and defaults to today's behavior, and Plannotator's own app passes the same defaults. The one deliberate change you will see in Plannotator is that chip: annotations a Refresh could not re-anchor now carry it in the panel as well as in the toast, and it clears on the next refresh that re-anchors them. The rest was held to a real-browser A/B over an annotate session driven identically on both builds, with header, chrome and overlay-marker captures matching after normalizing minted ids and the port. #1395 by @backnotprop Renderers that load when they are needed Mermaid, Graphviz, KaTeX and the identity dictionary used to ride every document read. They now load on demand, while Plannotator's own apps import eager entries as their first import and render exactly as before, typesetting math on the first commit with no frame of raw TeX. On the share portal the entry chunk drops from 1,831,133 to 1,211,620 gzip bytes, with the Graphviz engine and the Mermaid runtime becoming lazy chunks fetched only when a diagram is on the page. For a host that bundles by route, roughly a megabyte of renderer leaves the document-read closure. The raw-HTML viewer's 185 KB bridge script can also be served as a separately cached asset now. A host passes `bridgeScriptUrl` and gets one classic

Download Plannotator v0.27.9 - Software Mirrors

Plannotator v0.27.9 Release Notes:

Follow @plannotator on X for updates

Missed recent releases?

v0.27.8: Pi keeps its prompt cache across plan transitions, thumbs-up returns to HTML annotation, embed picker seam

v0.27.7: Pi host crash fix on Windows, Call Flow tree cap, jj fork-point base, plannotator knowledge skill + llms.txt

v0.27.6: Live app annotation lands on Pi, one interaction model for HTML pages (same-day patch on v0.27.5)

v0.27.5: Annotate your running app, Agent TUI placement, collapsed lockfiles, VS Code theme fix, Pi fixes

v0.27.4: Portable Guided Review exports, guides.show share links, guide CLI, favicon switcher, jj Call Flow

v0.27.3: Folder watcher freeze fix on large repos, first SBOM-attested release pipeline

v0.27.2: Mobile plan and code review, Codex CLI 0.147 fix, folder annotate cold-start, configurable markdown extensions

v0.27.1: Open-in-editor launch fix, file headers respect Viewed/Git-add visibility toggles

v0.27.0: Call Flow analysis, --tailscale remote reviews, review panel remembers your view, Pi rebuild (breaking command rename), focus-mode shortcut

v0.26.8: Placed comment markers on HTML pages, shift-click multi-select, live app annotation

v0.26.7: Pinpoint targets any element on HTML pages, smarter hover labels, zero-scan hit testing

v0.26.6: Fixed empty environment variables in sandboxed sessions (Bun 1.3.14 builds)

What's New in v0.27.9

Eleven pull requests, one of them from @leoreisdias. Two threads run through the release. Browser-integrated agents can now read a plan or an annotate session and leave comments on it through WebMCP, instead of scraping the page. And the raw-HTML annotation surface gained a Refresh action along with a published set of seams so other applications can run that surface as Plannotator ships it. A Windows uninstall fix and a pre-release QA pass close it out.

Browser agents can read your document and comment on it

An agent that runs inside the browser, such as Codex's browser or Claude Code's browser, has until now had to work out what is on the page by reading the DOM. Plan review and every annotate surface (markdown, raw HTML, live app, folder) now register a small tool catalog on document.modelContext, the WebMCP surface those agents speak. The catalog is deliberately narrow. read_document returns the whole situation in one zero-argument call: the session, the document text windowed at 16k characters and cut at a block boundary, an outline with per-section comment counts, every comment with its quote and context, sibling documents, and a set of nudge codes. add_comments writes a batch, anchoring by an exact quote, by section, by reply, or as a document-level note, and is idempotent by request id. update_comment, remove_comments, reveal and nudge_user round it out, with list_documents in folder sessions. Three rules make this safe to ship without a consent dialog. Decisions stay with the human: no tool approves, denies, submits, closes, stages or marks anything viewed, and a test pins the catalog so none can be added quietly. An agent may edit or remove only the comments it created, which are stamped browser-agent; asking to touch a human's comment answers forbidden. And nothing is ever registered inside the sandboxed iframes, so a page you are annotating can neither see nor impersonate Plannotator's tools. Without the API there is no footprint at all. Feature detection is one typeof check per mount, and when document.modelContext is absent the catalog is never built and no indicator, banner, request or timer is created. That was verified rather than assumed: builds from main and from the branch served the same annotate session to a Chrome without WebMCP, and the rendered DOM (44,607 characters), the request lists, the console output and the timer counts came back identical on both sides. The nudges are what keep an agent in step with you. Every response carries codes computed from state the page already holds, so the agent learns on the call it was going to make anyway that you added a comment, that your composer is open, that the file changed on disk, or that the live app navigated to another page. A header indicator appears after the first tool call, and a Settings toggle turns the whole provider off and on. One product change comes with it. Annotation gains an optional inReplyTo field, so an agent can answer a comment you left. A reply inherits its parent's anchor, renders indented under it in the annotations panel, and exports nested under the parent as a Replies: block, which is what puts the exchange in front of the coding agent in order. Annotations without the field render and export byte for byte as before. Code review is phase 2 and is not in this release.

#1393 by @backnotprop

Refresh rendered HTML from disk

Markdown annotate sessions pick up an agent's edits as soon as the file changes on disk. Rendered HTML sessions kept showing the snapshot they loaded at startup, so the review surface went stale the moment the agent rewrote the report you were reading. @leoreisdias added a Refresh action for local .html and .htm annotate sessions, next to Hide tools and reachable from the keyboard. It re-reads the document, remounts the sandboxed viewer, reapplies your annotations, and tells you how many anchors no longer match while keeping those comments in the panel. It is manual on purpose: this is the first checkpoint, and automatic filesystem-driven refresh waits until the restoration behavior has seen real use. URL sessions, archive views, markdown-converted HTML and non-HTML documents are unchanged, and HTML source saving stays off. Review turned up a share-link race that predated the feature. The share request context included the identity of the resolver, and that identity changes as a side effect of its own success, so the first short link created on an HTML session discarded its own result. That is fixed with a regression test. A browser verification run found two more: the singular toast read "1 annotation no longer match the HTML", and a browser reload after a refresh reverted the page to the startup snapshot because /api/plan never re-read disk while the draft annotations persisted against the replaced page. /api/plan and /api/share-html now share one root read on both server runtimes, so reload and refresh land on the same bytes. The version diff that a refresh used to cost you is back as well, recomputed rather than dropped. That fix arrived with the QA pass below.

#1232 by @leoreisdias, with maintainer commits for the share race, the toast and the two-runtime root read

The HTML annotation surface, packaged for hosts

Applications built on @plannotator/ui were hand-rolling their own code around HtmlViewer to get the experience Plannotator ships. The Workspaces team asked for the seams to be published, and they now are. HtmlSurfaceControls gives a host the eye, the refresh and the pen with the exact markup, data attributes and aria state Plannotator's header uses, each control rendering only when its handler is passed. useHtmlRefresh publishes the refresh lifecycle with the backend behind a fetchSnapshot callback, so a host binds it to its own document store. projectHostThreads and buildPersistedHtmlAnchor in @plannotator/core/html-anchor project stored rows onto the annotations prop in the host's order, which is the marker numbering, and trim a composed comment's anchor for persistence within a byte budget. AnnotationPanel takes an unanchoredIds set and renders a small Unanchored chip on the matching cards. HtmlViewer takes scrollBehavior so a host can carry a reduced-motion preference across the iframe boundary, and maxAdditionalTargets for its own cap on shift-click targets. Every seam is additive and defaults to today's behavior, and Plannotator's own app passes the same defaults. The one deliberate change you will see in Plannotator is that chip: annotations a Refresh could not re-anchor now carry it in the panel as well as in the toast, and it clears on the next refresh that re-anchors them. The rest was held to a real-browser A/B over an annotate session driven identically on both builds, with header, chrome and overlay-marker captures matching after normalizing minted ids and the port.

#1395 by @backnotprop

Renderers that load when they are needed

Mermaid, Graphviz, KaTeX and the identity dictionary used to ride every document read. They now load on demand, while Plannotator's own apps import eager entries as their first import and render exactly as before, typesetting math on the first commit with no frame of raw TeX. On the share portal the entry chunk drops from 1,831,133 to 1,211,620 gzip bytes, with the Graphviz engine and the Mermaid runtime becoming lazy chunks fetched only when a diagram is on the page. For a host that bundles by route, roughly a megabyte of renderer leaves the document-read closure. The raw-HTML viewer's 185 KB bridge script can also be served as a separately cached asset now. A host passes bridgeScriptUrl and gets one classic

Software Mirrors - Blog

Download Plannotator v0.27.9 - Software Mirrors

Plannotator v0.27.9 for Windows

Plannotator v0.27.9 for macOS

Plannotator v0.27.9 for Linux