Tactus: Agent Skills Inside a Browser Extension

The gap Tactus fills: agents that cannot see your tab

Most chat assistants live in a separate tab or a desktop window. To use one on a page you are reading, you copy text out, paste it in, and paste the answer back. Tactus makes the page itself the context. The README describes page extraction through Readability plus Turndown, which converts the main article body to Markdown before it reaches the model, and a selection quote feature that sends just the highlighted passage. The extension is built for people who already have an API key and are willing to configure a provider: Anthropic, Gemini, or any OpenAI-compatible endpoint. It is not a hosted service. There is no account, and the README states that all data is saved locally and nothing is uploaded to any server. The target user is an engineer or researcher who wants an agent that can read the current tab, run a prepared script against it, and call outside tools, without moving the work into a vendor's cloud workspace.

How a skill actually runs: SKILL.md, scripts, and the trust prompt

A skill is a folder with a SKILL.md file at its root, plus any scripts and resource files the skill needs. Import happens from the Skills area of the settings page, where you select that folder. The README's description of the mechanism is that triggering a skill injects prompt content for a specific scenario, and that common workflows can be packaged as scripts rather than left to the model to perform step by step. The stated benefit is speed and token efficiency: a script does the repetitive part, the model decides when to invoke it. Execution is the part worth pausing on. Skills run JavaScript inside pages, and the README says the first execution of a script requires user confirmation, with an option to trust it permanently. That is a reasonable default, but it is a one-time gate per script. Once you tick permanent trust, later edits to the same skill folder are not described as re-triggering the prompt. Treat the trust dialog as the moment you are reading the code, not as a formality. The ReAct loop on top of this is standard: the model decides when to call a tool, and the README notes the page extraction tool is skipped when a skill script already supplies the content.

Getting it running: npm scripts, unpacked builds, and the two limits that matter

The fastest path is a store install, but building from source is documented and short. Clone the repository, then run npm install. Development mode is npm run dev for Chrome and npm run dev:firefox for Firefox. Production builds are npm run build and npm run build:firefox. For a manual Chrome or Edge install, the README says to extract tactus.zip to a permanent directory, open chrome://extensions/, enable Developer mode, click Load unpacked, and select the extracted tactus folder. The Firefox route is a temporary debug install: run npm run build:firefox, open about:debugging#/runtime/this-firefox, click Load Temporary Add-on, and pick .output/firefox-mv2/manifest.json. Note the manifest version: the Firefox output is MV2. Temporary add-ons in Firefox do not survive a restart, so that path is for evaluation rather than daily use. After install, add a provider (name, API URL, key), fetch the model list, and enable vision per model if you need screenshots and charts. Two settings deserve attention before you use the agent in anger. Web Content Char Limit caps how much extracted page text reaches the model, and Tool Call Limit caps tool calls per conversation to prevent loops. Both are your cost and safety controls. The README also mentions smart Base URL handling that appends /v1/chat/completions automatically, with an endpoint preview under the input field. Verify that preview against your provider's documentation, because a wrong path is the most common cause of a first request failing.

MCP over HTTP: what you get, and what the transport choice rules out

Tactus connects to external tool servers over the Model Context Protocol, and the README is explicit that this is HTTP MCP. It supports adding and managing multiple servers, fetching available tools dynamically, and three authentication modes: none for public services, Bearer token, and OAuth 2.1 with auto-refresh. The transport restriction is the real constraint. Servers that only expose stdio, which is how many local MCP servers are shipped, are not usable here without an HTTP bridge in front of them. That is a design consequence of living in a browser extension, where spawning child processes is not an option, but it narrows the ecosystem you can draw on. The dynamic tool discovery is convenient and also a small risk surface: whatever a server advertises becomes callable by the model, and the README does not describe per-tool allowlists. If you connect a server with write operations, the only stated guardrail is the Tool Call Limit. Bearer tokens and OAuth credentials are stored wherever the extension keeps its configuration, which the README describes as local; it does not describe encryption at rest.

Where Tactus is the wrong tool

The privacy claim is local storage, not isolation. Skills and files live in IndexedDB, sessions are stored locally with pagination, and messages can be edited and regenerated. That is fine for one person on one machine. It is a poor fit for a team that needs shared, versioned skill libraries, because there is no described sync, export, or signing mechanism for skills. Every user imports folders by hand, and every user sees the trust prompt for the first run of each script. If you need an audit trail of which script ran against which page, Tactus does not describe producing one. The second mismatch is the provider model. Tactus is bring-your-own-key. There is no bundled inference, so the extension is only as capable as the model you point it at, and your key sits in the browser profile. On a shared or managed machine, that is a conversation to have before installing. Finally, the page extraction pipeline assumes readable article structure. The README offers a raw extraction mode for specific websites that should skip Readability, which is an admission that the default fails on some sites. You will be maintaining that list yourself.

How it differs from a self-hosted agent framework

The obvious comparison is a self-hosted agent runtime such as an MCP client paired with a scripting layer, running on your machine rather than in a browser. The difference is where the page lives. A local runtime reaches the web through a headless browser or HTTP fetches, so it sees a rendered approximation, often without your session cookies, and it cannot act on the tab you are already logged into. Tactus inverts that: the extension runs inside the page's own context, which is why selection quoting and in-page script execution are possible at all. The cost of the inversion is everything a server process gives you for free. No stdio MCP servers, no process isolation for skill scripts, no central log, no scheduled runs. If your task is batch processing a thousand URLs, a local runtime is the better shape. If your task is reading a page you are on, running a script against its DOM, and asking a model about the result without leaving the tab, Tactus is built for exactly that and the alternatives require more plumbing.

Maintenance, licensing, and what to check before you commit

Tactus is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual requirements around preserving notices and stating changes. That is a permissive licence, and it is a better fit for internal tooling than a copyleft one would be. It is not legal advice; if you redistribute a modified build, read the licence text yourself. On maintenance, the release history shows v1.3.1 in March 2026, v1.3.2 later that month, and v1.3.3 in April 2026, with the last push to main in May 2026. That is a steady cadence over a short window, and the version numbers suggest incremental work rather than a rewrite. The upgrade cost is low if you install from a store, since updates arrive automatically. If you build from source, you own the rebuild and the re-import of skills after a schema change, and the README does not describe a skills migration path. One detail in the build instructions is worth flagging: the README tells contributors to use the Professional style inside the .claude/skills/design-style skill for UI work, which means the project's own skill format is used to develop the project. That is a fair signal that the format is stable enough to dogfood, and it is also the best example to read if you want to see a real SKILL.md before writing your own.

Editorial conclusion

Adopt Tactus if you already hold an API key for Anthropic, Gemini, or an OpenAI-compatible endpoint and you want the agent to work on the page you are looking at, with skill scripts you can read before they run. Skip it if you need an auditable, centrally managed deployment, since skills live in the browser's IndexedDB and there is no organisation-level policy layer described in the README. Before installing, open one skill folder, read its SKILL.md and its JavaScript, and check the Tool Call Limit and Web Content Char Limit settings, because those two numbers decide both your token bill and the blast radius of a runaway loop.

Official sources

1. Castor6/tactus on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases