Repo Review: JodusNodus/opencode-chrome-annotation

Review note: This analysis is based on repository metadata, documentation, and selected source files. It is not a full security audit. Confidence: medium.

Quick facts

GitHub: JodusNodus/opencode-chrome-annotation

Primary language: TypeScript

Stars: 32

License: GPL-3.0-only

Last updated: 2026-04-30T13:49:08Z

Documentation signal: good

Test signal: limited

Maintenance signal: active

What it is

OpenCode Chrome Annotation connects a Chrome or Chromium extension to a local OpenCode plugin. The workflow is aimed at a very specific annoyance in AI-assisted frontend work: explaining a visual UI problem to a coding agent without manually describing every DOM detail. You connect a tab to an OpenCode session, select an element on the page, write an instruction, and submit page metadata plus a screenshot to the local OpenCode process.

The repository is small and focused. GitHub reports TypeScript as the primary language, 32 stars, no forks, one open issue, and recent activity on April 30, 2026. The package is versioned as 1.0.2 on npm metadata, the Chrome extension manifest is version 1.0.1, and the project is licensed GPL-3.0-only.

Architecture and stack

The architecture is a two-part local bridge. The OpenCode plugin in src/plugin.ts starts a local HTTP server on a bounded localhost port range, exposes status, session, claim, unclaim, and annotation endpoints, and converts submitted annotations into prompts for the active OpenCode session. The Chrome extension discovers those local plugin instances by probing localhost ports, lets the user choose a session, and routes annotation payloads to the selected instance.

The extension side uses Chrome Extension Manifest V3 with tabs, activeTab, scripting, and storage permissions, plus localhost host permissions. It includes background orchestration, a session picker, connection monitoring, claims storage, and an annotation picker. The build story is straightforward: Bun builds the plugin, a custom script builds the extension output, TypeScript handles typechecking, and a zip script prepares the Chrome Web Store upload package.

What looks strong

The strongest part is product fit. Browser-to-agent feedback loops are awkward today: screenshots lose DOM context, DOM dumps lose visual context, and textual issue reports are often ambiguous. This project packages the useful middle ground: user intent, selected element metadata, page URL/title, viewport details, and a screenshot. That is exactly the kind of context a coding agent needs to make a targeted UI change.

The local-first design is also sensible. The README and privacy policy both emphasize that annotation payloads go to the user’s own local OpenCode setup, not to an extension-controlled remote backend. The plugin writes screenshot files to a local temporary directory and sends the generated prompt through OpenCode rather than introducing a hosted relay service.

The code is more structured than a quick demo. There are separate modules for server API calls, session picking, connection monitoring, claims storage, overlays, annotation picking, logging, and shared types. The plugin also accounts for multiple OpenCode instances by scanning a bounded port range and tracking tab claims with a time-to-live.

Tradeoffs and risks

The obvious tradeoff is maturity. This is a brand-new project with no GitHub releases, low adoption signals, and what appears to be a manual end-to-end testing path. The package scripts include typechecking and extension validation, but I did not see a dedicated automated test suite. For a browser extension that coordinates permissions, injected UI, screenshots, localhost discovery, and agent calls, regression coverage will matter if the project grows.

The extension permission model deserves careful attention. The manifest asks for tabs, activeTab, scripting, storage, localhost access, and dynamic origin access when annotating a site. Those permissions are reasonable for the workflow, but users should understand that submitted annotations may include page URL, title, selected text, element metadata, and screenshots. The local-only privacy posture reduces risk, but it does not make sensitive-page capture risk-free.

There is also operational coupling to OpenCode and browser APIs. The project depends on the OpenCode plugin API, local HTTP behavior, Chrome extension APIs, and a Chrome Web Store install path. Changes in any of those interfaces could break the flow, so adopters should expect some churn while the integration matures.

Who should try it

This is worth trying if you use OpenCode for frontend or browser-facing work and often need to point at a specific UI element while asking for a code change. It looks especially useful for personal projects, internal tools, design polish passes, bug triage, and small teams that already trust a local coding-agent workflow.

I would be more cautious in regulated or high-sensitivity browsing environments until the project has more adoption, clearer threat modeling, and more automated test coverage. For those cases, the local-only architecture is a good start, but teams still need policy around what pages can be annotated and what screenshots can be sent to an agent session.

Bottom line

OpenCode Chrome Annotation is a sharp, narrowly scoped developer-tooling idea: make UI feedback concrete by sending browser annotations straight into OpenCode. The repository is young, but the architecture is coherent, the README is clear, and the local-first privacy model fits the problem better than a remote relay would.

My read: promising and worth watching, especially for OpenCode users who do frequent frontend work. I would treat it as early-stage tooling rather than mature infrastructure today, but the core workflow is useful enough that a small amount of polish, tests, and release hygiene could make it a genuinely handy part of an agentic coding setup.

Limitations

I reviewed public repository metadata, README content, package and extension manifests, the privacy policy, and key TypeScript source files, but did not install the Chrome extension or run an end-to-end OpenCode session.

The project is very new, created in April 2026, with low star and fork counts, no GitHub releases, and one open issue at review time, so maturity signals are limited.

The browser-extension workflow touches page metadata and screenshots, so users should evaluate the local-only privacy model and extension permissions before relying on it for sensitive pages.