OpenTag: the open-source @agent mention gateway

TL;DR + the pipeline

• What it is. A local-first CLI gateway, not a hosted SaaS and not an MCP server. It normalizes an @mention from six platforms into one event, runs Codex or Claude Code against a bound project, and posts the result back to the thread.
• One install. npm install -g @opentag/cli@latest, then opentag setup. The wizard asks for a platform, an agent, a project, and credentials, then offers to run as a background service.
• The pitch is governance, not novelty. Every mention becomes an audited run — a context snapshot, a capability check, an approval gate, and a local ledger you can query with opentag status --run <id>.
• Watch the name. Three unrelated teams built a same-named “OpenTag” within about 72 hours in late June 2026. This guide covers amplifthq/opentag specifically — see the comparison before you copy commands from anywhere else.

npm install -g @opentag/cli@latest
opentag setup

What OpenTag actually does

The maintainers’ own demo is the clearest description: mention OpenTag in a Slack thread, approve the suggested action, and a real GitHub pull request comes back to that thread. Nothing about the request leaves the tools your team already uses — Slack for the conversation, GitHub for the code.

The validated version of that loop, straight from OpenTag’s own smoke tests: a GitHub issue comment tags OpenTag, OpenTag hands it to a local Claude Code process, Claude Code commits to a branch, opens a pull request, and OpenTag posts a callback on the original issue. Once setup finishes, try it directly in a bound repo’s issue thread:

@opentag fix the failing test in this PR

OpenTag replies with a receipt describing the fix it found. Reply apply 1 in the same thread, and only then does it push a branch and open the pull request.

Our take: the interesting design choice isn’t the mention parsing — every chat bot does that. It’s that applying is a separate, explicit step from proposing, and the receipt lives in the thread that started the request instead of a dashboard you have to remember to check.

Why it exists

The failure mode OpenTag targets is the copy-paste tax: pulling a GitHub issue, a pull request, or a Slack discussion into a separate AI chat window, re-explaining the context by hand, then pasting the result back. The work sits in one place; the agent sits in another. OpenTag’s launch post named this directly — the idea is that agents should “join the work where it already happens” instead of the reverse.

The deeper reasoning goes past convenience. OpenTag’s own design notes list the questions a team actually needs answered once an agent starts acting inside real workflows: who asked it to act, what context it saw and what was deliberately excluded, what permissions the run held, which executor handled it, and what can be audited later without flooding the human thread. That list reads like a governance checklist, not a chatbot feature list — which is the point.

Our take: that is a different pitch than “AI in your Slack.” Copilot-style chat tools already exist. OpenTag’s design centers the audit trail as much as the automation, which is why the project calls itself an Agent Work Protocol rather than a bot.

Mental model: the five pieces

Five named pieces, each with one job, chained in a fixed order. Understanding this order explains almost every behavior in the rest of this guide.

• Ingress adapter — normalizes a platform event (a Slack message, a GitHub comment, a Lark mention) into one common event shape. One adapter per platform; each ignores anything that isn’t an explicit mention.
• Dispatcher (opentagd) — the local coordination service. It validates scope, persists the run, manages leases so two runners can’t claim the same mention, and writes audit events.
• Runner — claims only the work it is explicitly bound to handle, local or hosted. Bindings map a channel or repo to a project; an unbound container is ignored, not guessed at.
• Executor — the coding agent doing the work: Codex, Claude Code, or the test-only Echo, running against the mapped local checkout.
• Receipt / callback — a compact reply posted back to the source thread, plus a quiet entry in the local audit ledger.

Our take: the piece worth noticing is that adapters never execute agent code and executors never talk to platforms directly. That boundary is what makes “executor-neutral” a real property instead of a slogan — swapping Claude Code for something else doesn’t touch the Slack or GitHub code at all.

Install & quick start

Requires Node.js 20 or newer. Global install is recommended so a background service points at a stable CLI path instead of a temporary npx location:

npm install -g @opentag/cli@latest
opentag setup

For a one-off terminal check without a global install:

npx @opentag/cli setup

opentag setup is a wizard that walks through six choices: CLI language, listen address, which coding agent to use, which local project to work on, which platform credentials to save, and how OpenTag should keep running. For scripted installs, skip the last prompt and go straight to the recommended background mode:

opentag setup --service

Background service mode uses a LaunchAgent on macOS and systemd --user on Linux. On other platforms, including Windows, use terminal mode with opentag start and keep that terminal open — there is no background-service path there yet.

Once running, mention it from any connected platform:

@opentag investigate this

Config lives at ~/.config/opentag/config.json; runtime state and isolated worktrees default to ~/.local/state/opentag. To remove everything:

npm uninstall -g @opentag/cli
rm -rf ~/.config/opentag ~/.local/state/opentag

Platforms & executors

Six platforms ship in the opentag setup flow today, each with its own setup guide and a recommended first path:

Executors are narrower on purpose:

If you are choosing between Codex and Claude Code as your team’s default coding agent in the first place, our Claude Code vs Codex CLI comparison covers model access, pricing, and sandboxing side by side.

One honest wrinkle we found: OpenTag’s own marketing site, opentag.im, shows Discord, Microsoft Teams, and Google Chat under “coming soon” and doesn’t list GitLab at all. The GitHub repository disagrees — both docs/platforms/discord.en.md and docs/platforms/gitlab.en.md are complete, step-by-step setup guides, and issues asking for Discord (#32) and GitLab (#54) support are both closed as shipped. Trust the repo’s docs over the landing page for a project moving this fast.

The executor list is also narrower than “executor-neutral” framing might suggest. A request to add a third real executor, Hermes, was filed and closed without landing (issue #34) — the adapter contract is public, but only Codex and Claude Code ship as working integrations today.

Approvals & source-thread receipts

When an agent proposes a change, OpenTag renders a compact receipt in the source thread showing what will change and whether it is ready to apply. The apply action only appears once the dispatcher confirms a bound adapter can actually execute it — otherwise the receipt shows setup or attention needed instead of failing silently.

Applying is always a separate, explicit reply in the same thread — something like apply 1 or continue 1 — not a default outcome of the mention itself. That single design choice is what turns “an agent read my thread” into “an agent asked permission in my thread,” and it is the mechanism the “governed” part of OpenTag’s tagline refers to.

Our take: putting the approval prompt and the result in the same thread as the original ask is a small UX decision with an outsized effect — nobody has to context-switch to a dashboard to say yes.

Audit trail & local-first privacy

Every run keeps a local agent work ledger: the source event, the admission decision, a context packet snapshot, an executor capability snapshot, produced artifacts, callback delivery, and the final outcome. None of that floods the human thread — it stays queryable through opentag status --run <run_id> and opentag doctor.

On privacy specifically: there is no OpenTag cloud service in the local CLI flow. Platform credentials are stored on your machine with private file permissions, Codex and Claude Code run against your local checkout, and platform APIs receive only the messages needed to acknowledge, reply, and apply an action you approved.

Worth being precise about, for an MCP-focused audience: OpenTag is not an MCP server and does not implement the Model Context Protocol. It speaks its own protocol for routing mentions to agent CLIs. If what you actually want is to aggregate several MCP servers behind one endpoint, that is a different tool in a different layer — see our MetaMCP guide for that use case, and What is the Model Context Protocol? if the distinction between a tool protocol and a mention gateway is still fuzzy.

Three teams, one name

Search “OpenTag GitHub” today and you will find three unrelated, independently created projects, all shipped within about 72 hours of each other in late June 2026. None is a fork of another — different orgs, different codebases, same premise and the same name.

The CopilotKit implementation is the one that picked up Hacker News coverage — “OpenTag: An open-source alternative to Claude in Slack” and a Show HN post the next day, both pointing at github.com/CopilotKit/OpenTag, not the implementation this guide covers. If you arrived here from an HN link, double-check which repo you are actually installing.

This guide is anchored on amplifthq/opentag because it has the broadest platform coverage of the three and the most explicit audit/governance design — the framing this whole article has been describing. If Slack-only with a wider executor list fits your team better, linxidnju’s Apache-2.0 build is worth a look; if a managed hosted option matters more than local-first, CopilotKit’s is the one to watch.

Our take: this isn’t plagiarism or confusion — it is three teams independently deciding that “tag an agent into the thread” was an obvious enough idea to build, in the same two-week window, under the same name. That convergence is itself a signal worth taking seriously.

What we got wrong

Three things we assumed while researching this piece that turned out to be wrong, in the interest of saving you the same detour.

• We assumed “OpenTag” meant one project. It doesn’t. A plain web search mixes results from three unrelated repos with different licenses, different install commands, and different feature sets. We nearly cited a CopilotKit tweet as being about amplifthq’s implementation before checking the linked repo — always confirm the org before you copy a command.
• We expected Discord to be unshipped, based on the landing page. opentag.im still marks it “coming soon.” The actual repository had a complete Discord setup guide and a closed feature-request issue confirming it works. For a project shipping daily, the marketing site lagged the real code by at least a week.
• We read “executor-neutral” as “bring any agent today.” The adapter contract genuinely is open — we verified it in docs/adapter-authoring.md— but the working executor list is exactly two: Codex and Claude Code. A community request for a third was closed without merging.

Doing it right vs. doing it wrong

Gotchas, from the issue tracker

• npm install can fail before OpenTag even starts. The project ships its own troubleshooting runbook for ENOTFOUND, EAI_AGAIN, and fetch failed errors during npm install -g @opentag/cli — a sign registry/proxy hiccups are common enough on first install to warrant documented tooling.
• No background service on Windows yet. The recommended always-on mode uses a macOS LaunchAgent or Linux systemd --user unit. Everywhere else, including Windows, you run opentag start in a terminal you have to keep open.
• Two executors, not “any agent.” Codex and Claude Code are it. Echo doesn’t call a real model, and the one community request for a third (Hermes) closed without landing.
• Coverage gaps are visible in open issues. A LINE Messenger request (#65) is open and unaddressed; a WeChat request (#30) is open too. If your team’s primary chat platform isn’t one of the current six, you are filing an issue, not installing today.
• The name collision is a real installation risk. Three different repos, three different licenses, three different command sets. Confirm the org — amplifthq, linxidnju, or CopilotKit — before running install commands from any tutorial, including this one.

Who this is for

This is for you if your team already discusses work in Slack or GitHub threads and wants an agent to join that conversation instead of opening a separate chat tab; if you need an approval gate and an audit trail before an agent’s suggested change becomes real; or if your team has already standardized on Codex or Claude Code as its coding agent.

This is less urgent if you’re a solo developer who already runs Claude Code or Codex directly in a terminal — the mention-gateway layer adds setup cost with no team thread to route from. It’s also not the fit if you want a zero-ops hosted SaaS today (that is on OpenTag’s own roadmap, not shipped, and closer to what CopilotKit’s managed service is aiming at), or if you need an executor beyond Codex or Claude Code out of the box. For a broader comparison of terminal coding agents that OpenTag can route to, see our Goose vs Cline vs Aider vs Claude Code vs OpenCode roundup, and wire the agent side up directly at mcp.directory/clients/claude-code.

Community signal

The launch tweet reads like the product brief in miniature — local execution, an auditable dispatch layer, and an explicit “early v0” framing:

A third-party reaction picked up on the same design detail we called out above — the adapter contract being public from day one:

We could not find loud public criticism of OpenTag yet — the project is barely two weeks old at the time of writing, and most GitHub issues are feature requests rather than complaints. The most concrete critical signal we found is structural, not opinion: the Windows background-service gap and the two-executor ceiling described above are real limits, confirmed directly in the project’s own docs and issue tracker, not community speculation.

The verdict

FAQ

Glossary

Sources

Primary — amplifthq/opentag

• github.com/amplifthq/opentag — README, issue tracker, license (MIT, TypeScript, @opentag/cli on npm)
• opentag.im — product site and architecture summary
• docs/adapter-authoring.md — the adapter contract referenced above
• docs/agent-work-protocol.md — the governance design doc quoted in “Why it exists”
• skills/opentag/SKILL.md — the project’s own agent-readable setup skill, source for the Codex Default-mode gotcha and the npm troubleshooting runbook

Comparison implementations (same name, different projects)

• github.com/linxidnju/OpenTag (Apache-2.0, JavaScript)
• github.com/CopilotKit/OpenTag (MIT, TypeScript, built on @copilotkit/bot)

Community

• @MeredithCheng22, June 24 2026 — launch tweet
• @heynavtoor, June 25 2026 — adapter-contract reaction
• r/SideProject — launch post
• Hacker News — “OpenTag: An open-source alternative to Claude in Slack” · Show HN follow-up (both about the CopilotKit implementation)

Related reading on mcp.directory

• Claude Code vs Codex CLI (2026)
• Goose vs Cline vs Aider vs Claude Code vs OpenCode (2026)
• What is the Model Context Protocol?
• MetaMCP: Self-Hosted MCP Gateway