OpenTag: A Slack-Native Gateway for Routing Team Threads to Local AI Agents
Open-source, channel-native agent gateway for Slack. Route team threads to Claude Code, Codex, OpenCode, Docker, HTTP agents, and custom CLIs with policy, approvals, memory, audit logs, and artifacts.
At a glance
- What is it?
- OpenTag puts agent runs inside Slack threads, with policy, approvals, versioned team knowledge and audit logs. It is an MVP that suits internal trials and runtime integration work, not hosted production use.
- Who is it for?
- Adopt OpenTag if your team already works in Slack threads and you want agent runs, approvals and artifacts visible to the whole channel rather than trapped in one person's terminal. Skip it if you need a hosted multi-tenant service, non-Slack channels, or hardened sandboxing today, because the README lists those as planned rather than delivered.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 68 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem OpenTag Targets: Agent Work That Dies in One Terminal
Most coding agents assume a single operator. You run the tool locally, read the output, and paste the useful part into a chat. The reasoning, the failed attempts, the approval decisions and the generated files stay on one machine. OpenTag is built for the opposite arrangement. The README describes it as bringing agents into "the place where team work already happens: Slack channels and threads." A teammate mentions @OpenTag in a thread, others add context while the run is in progress, risky actions can pause for approval, and the result remains visible to anyone with channel access. The intended audience is a team that already coordinates in Slack and wants agent output attached to the conversation that produced it, rather than to one engineer's shell history. The README lists concrete starting points: investigating a bug from a thread, asking the agent to check a thread and draft a fix plan, or summarizing why a deployment failed.
How Routing and Execution Actually Work
OpenTag is a gateway, not an agent. The Slack side handles mentions, thread replies, DMs, slash commands and approvals. Behind that sits a routing layer that dispatches work to a runtime adapter. The README names mock runs, Codex, Claude Code, OpenCode, Docker, HTTP agents and generic CLI agents as options. Two documents define the extension surface: docs/gateway-contract.md, described as the connector contract for future Discord and Teams support, and docs/runtime-adapter-templates.md, which covers generic CLI, HTTP and MCP-capable runtime templates. That split matters. The channel connector and the agent backend are separate contracts, so a new chat platform and a new agent runtime are independent additions. Per-channel behaviour is configured through what the README calls Channel Profiles and Access Bundles, which set the default runtime, the runtimes a channel is allowed to use, permitted users, approvers, instructions, memory and workspace roots. Team knowledge is a separate store with versioning: a correction produces a new active version, scoped to a workspace or private channel, carrying a source reference and revision history. The README states that every configured runtime reuses the latest active version, and that archive, restore and permanent deletion are supported. Storage is local, covering sessions, messages, approvals, runs, audit records and artifacts.
Getting It Running: Commands and the Setup Wizard
The only stated prerequisite is Node.js >=20.11.0. The README gives a short sequence. Install dependencies and run the smoke test with npm install followed by npm run smoke. To try the system without Slack at all, run npm run start:console, which the README describes as local console mode. For the Slack path, the sequence is npm link, then opentag init --project . --runtime mock --open-slack, then opentag setup launch, then opentag doctor --strict. The setup launch command starts a local daemon and opens a wizard at http://127.0.0.1:8787/setup that walks through agent selection, Slack manifest import, local token saving and final verification. Running opentag next prints the next setup step at any time, which is a reasonable affordance for a multi-stage install. In-channel commands visible in the README include /runtime codex-readonly explain the current project structure, /opentag sessions, /opentag approvals and /opentag status <session_id>. A sample Slack app manifest lives at examples/slack-app-manifest.yaml, and detailed installation instructions are in docs/user-guide/01-install.md. The README also points to docs/user-guide/05-troubleshooting.md, which suggests the maintainers expect the setup path to fail in specific ways rather than universally.
Limits the README States Plainly
OpenTag labels itself an MVP and says it is suitable for local trials, internal team experiments and runtime integration work. It states directly that it is not yet a hosted production SaaS. The planned improvements list is the honest part of the document: Slack OAuth installation, stronger multi-instance storage, a web admin UI, hardened sandboxing and more channel integrations. Read that list as the current gaps. Storage is local, so a multi-instance deployment is not supported yet, which constrains any team that wants more than one gateway process or a shared database behind it. Slack is the only channel integration shipped; the gateway contract exists for Discord and Teams, but the README frames those as future connectors. Sandboxing is described as planned, not hardened, so filesystem restrictions through workspace roots are a configuration boundary rather than an isolation guarantee. If your requirement is a managed service with tenant separation, or agent execution you would describe as sandboxed, OpenTag does not claim to meet it today.
Where It Sits Against a Plain CLI Agent
The obvious alternative is running Claude Code, Codex or OpenCode directly in a terminal. That approach is simpler, needs no daemon, no Slack app, no manifest import and no token storage, and it inherits whatever sandboxing and permission model the underlying agent already provides. OpenTag trades that simplicity for shared visibility and control. The difference is not which model answers the question; it is who can see the run, who can approve a write action, and whether the outcome survives the session. A terminal run leaves nothing for a teammate who joins the thread an hour later. OpenTag keeps sessions, approvals, artifacts and audit records in local storage, and lets a channel restrict who may invoke the agent and which runtimes are permitted. If your work is genuinely single-operator and the results are short-lived, the terminal is the better tool. OpenTag pays off when the run needs an audience, a decision trail, or a permission boundary that someone other than the operator can inspect.
Maintenance, Licensing and What the Repository Metadata Does Not Settle
The project is JavaScript, targets Node.js >=20.11.0, and the last push recorded in the repository metadata is 2026-07-10. No releases were retrieved, so there is no published version history to reason about upgrade paths from. That means installation is effectively from the repository, and upgrades follow the main branch. The README's own roadmap items (OAuth installation, multi-instance storage, web admin UI, hardened sandboxing) are the areas most likely to change shape, so pinning a commit is the safer posture for anything beyond a trial. On licensing, the two signals conflict. The repository metadata reports NOASSERTION, while the README badge and the license section both state Apache-2.0. The README text is truncated mid-sentence at "Apache-2.0. Se", so the license section cannot be read in full from the supplied material. Verify the LICENSE file in the repository before relying on either signal. This is not legal advice; if the licence terms matter to your organisation, read the file yourself.
Who Should Adopt OpenTag, and What to Check First
Adopt it if your team lives in Slack threads, you already run at least one local agent CLI, and you want runs, approvals and artifacts to be visible and reviewable by the channel rather than by one operator. The mock runtime and console mode make it cheap to evaluate the routing and policy model before wiring a real backend. Do not adopt it if you need a hosted multi-tenant service, non-Slack channels, or sandboxing you would defend in a security review; the README lists all three as planned or absent. Before committing, run opentag doctor --strict in the target environment, confirm which runtime adapter you will use by reading docs/runtime-adapter-templates.md, and check the LICENSE file directly given the metadata mismatch. The most useful early test is a single channel with a read-only runtime, an explicit approver list and a workspace root restriction, which exercises the policy path without exposing write access.
Editorial conclusion
Adopt OpenTag if your team already works in Slack threads and you want agent runs, approvals and artifacts visible to the whole channel rather than trapped in one person's terminal. Skip it if you need a hosted multi-tenant service, non-Slack channels, or hardened sandboxing today, because the README lists those as planned rather than delivered. Before committing, run opentag doctor --strict against your target environment, confirm which runtime adapter you will actually use, and check the LICENSE file directly, since the repository metadata reports NOASSERTION while the README badge and text say Apache-2.0.
Community notes