# OpenTag: A Slack-Native Gateway for Routing Team Threads to Local AI Agents > 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. **linxidnju/OpenTag** — 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. - Repository: https://github.com/linxidnju/OpenTag - Stars: 502 · Forks: 0 - Language: JavaScript - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/linxidnju-opentag ## 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 . 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. ## 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. ## FAQ ### What does OpenTag actually do? It lets a team mention @OpenTag in a Slack channel or thread, discuss the task in that thread while the agent runs, approve risky actions when asked, and keep the outcome visible to everyone with access to the channel. Sessions, decisions, outputs and generated artifacts are recorded. ### What do I need to install OpenTag? Node.js 20.11.0 or newer. Then run npm install and npm run smoke to exercise the mock runtime, or npm run start:console to try the gateway locally without Slack at all. For the Slack gateway the documented sequence is npm link, opentag init, opentag setup launch and opentag doctor --strict. ### Which agent runtimes does OpenTag support? Mock runs, Codex, Claude Code, OpenCode, Docker-based agents, HTTP agents and generic CLI agents. A runtime can be the channel default or chosen per request with a slash command such as /runtime codex-readonly, and templates for generic CLI, HTTP and MCP-capable adapters are provided. ### Can I install the OpenTag Slack app with OAuth? Not yet. Slack OAuth installation is listed among the planned improvements, so setup today means importing a Slack app manifest and saving a token locally through the setup wizard served at http://127.0.0.1:8787/setup. ### Is OpenTag ready for production use? The README calls it an MVP suitable for local trials, internal team experiments and runtime integration work, and states it is not yet a hosted production SaaS. Planned work includes Slack OAuth installation, stronger multi-instance storage, a web admin interface, hardened sandboxing and more channel integrations. ## Sources - [Issues](https://github.com/linxidnju/OpenTag/issues) - [linxidnju/OpenTag on GitHub](https://github.com/linxidnju/OpenTag) - [README](https://github.com/linxidnju/OpenTag/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/linxidnju-opentag