GolemBot: put Cursor, Claude Code, OpenCode or Codex behind Slack, Telegram and Feishu

What GolemBot actually solves, and for whom

Cursor, Claude Code, OpenCode and Codex already reason about code, run scripts and read files. What they do not do is sit in a group chat. GolemBot's premise, stated in the README, is that these agents are "stuck in an IDE or a terminal window", and the project's job is to give them a body: a process that listens on Slack, Telegram, Discord, Feishu, DingTalk, WeCom, WeChat or plain HTTP and forwards messages into the agent CLI. The README puts it bluntly: "No AI framework, no prompt engineering, the agent you already have is the brain."

The audience is narrower than the tagline suggests. This is for teams that have already picked a Coding Agent and want it available as a teammate, and for developers embedding an agent into a Node.js product. It is not for someone shopping for an agent: GolemBot ships no reasoning loop of its own, so if you have no engine installed and authenticated, there is nothing to route to.

The gateway, the adapters, and where provider routing sits

The architecture diagram in the README shows one flow. Channel adapters and an HTTP service feed a Gateway Service, which calls createAssistant(), which dispatches to one of four engines: Cursor, Claude Code, OpenCode or Codex. Beneath the engines sits provider routing, with OpenRouter, MiniMax and DeepSeek named as examples. So a single config block can route Claude Code through OpenRouter or run Codex on MiniMax, per the README, with no code change.

Two details matter here. First, the HTTP service is a first-class channel, not a debugging afterthought: the README documents a POST /abort endpoint for cancelling a running task without clearing session history, and the Dockerfile exposes port 3000 with golembot gateway as the container command. Second, custom adapters are an extension point rather than a plugin marketplace; the README mentions writing one to plug in email or GitHub Issues, but the repository's examples directory contains e2e scripts for the four engines and IM formatting tests, not a worked custom-adapter sample.

Installing GolemBot and getting a first reply

The package is published to npm as golembot and the README requires Node.js 18 or later. Global install first:

npm install -g golembot

Then create a directory for the assistant and run the guided setup. The README marks onboard as the recommended path and init as the manual equivalent, where -e selects the engine and -n names the bot:

golembot onboard
# or manually:
golembot init -e claude-code -n my-bot

Before any of this works headlessly you need credentials. The repository's .env.example lists CURSOR_API_KEY for the Cursor engine and ANTHROPIC_API_KEY for Claude Code, with the comment that the Cursor key comes from Cursor Settings under API Keys or from agent auth token. Copy the template and fill it in:

cp .env.example .env

With that in place, the README gives two ways to talk to the bot. golembot run opens a REPL for a local conversation, and golembot gateway starts the IM channels, the HTTP service and a built-in Dashboard. If a task hangs, the README documents /stop in the REPL or in IM, assistant.cancel(sessionKey?) in code, and POST /abort over HTTP. Running more than one bot, golembot fleet ls lists them and golembot fleet serve aggregates their dashboards.

Embedding it in a Node.js service in five lines

The README's second use case is embedding, and the example is short enough to quote in full. createAssistant takes a directory, and bot.chat returns an async iterator of events that you filter by type:

import { createAssistant } from 'golembot';
const bot = createAssistant({ dir: './my-agent' });

for await (const event of bot.chat('Analyze last month sales data')) {
  if (event.type === 'text') process.stdout.write(event.content);
}

The README says this suits Slack bots, internal tools, SaaS products and customer support, and that anything speaking Node.js can host it. The package.json confirms the shape: type is module, main points at ./dist/index.js, and exports expose only the root entry, so this is an ESM-only library and a CommonJS consumer will need a dynamic import. The README does not document the full event union beyond the text type shown, so treat event handling as something to inspect in the source before designing around it.

Where GolemBot is the wrong tool

GolemBot delegates the hard part. Anything the underlying CLI does badly, GolemBot does badly, and the README is explicit that there is no prompt engineering layer to compensate. If your problem is that your agent gives poor answers, this project does not address it.

The operational surface is also real. A gateway process holds live connections to Slack, Telegram, Discord, Feishu, DingTalk, WeCom and WeChat simultaneously, and the Dockerfile runs it with restart: unless-stopped in the supplied compose file, which suggests the authors expect restarts. The README does not document what happens to an in-flight task when the process dies, nor does it describe per-user session isolation, so a shared bot in a busy group chat is a design question you have to answer yourself. And because the engines are external CLIs, a breaking change upstream lands in your deployment rather than in a version bump you control.

How it differs from wiring an LLM API yourself

The README's own comparison table sets GolemBot against "traditional AI frameworks", and the honest reading is that they solve different problems. A framework such as LangChain-style tool wiring gives you control over the reasoning loop, the tool schemas and the prompts, at the cost of building chains, retrieval and evaluation yourself. GolemBot gives you none of that control and none of that work: the agent CLI is the brain, and GolemBot is the transport.

The practical difference shows up when you change something. Swapping engines in GolemBot is, per the README, one line in config, and swapping LLM providers is a config block; the README claims "zero code changes". In a self-built stack the equivalent change touches your tool definitions and prompt templates. The trade is that GolemBot's capabilities are bounded by whatever the four supported CLIs expose, and the README's engine comparison table is truncated in the published file, so the per-engine feature matrix is not something you can read off the README alone.

Maintenance, releases and the MIT licence

The repository is not archived and the last push was on 2026-09-05, the same day as release v0.49.2. Two earlier releases, v0.49.1 and v0.49.0, landed on 2026-08-18 and 2026-08-16, so the version number is moving in small increments rather than sitting still. Release automation is visible in the repository layout: .releaserc.json and a release script pointing at semantic-release, with husky hooks in .husky/ and Biome for linting and formatting.

Upgrade cost is dominated by the external engines, not by GolemBot's own version. The package depends on commander and is published as ESM, so a major Node.js or engine CLI change is the realistic breakage vector. The licence is MIT, stated in both the README badge and package.json, which permits commercial embedding; that is a statement about the licence text, not legal advice, and the four agent CLIs you route through carry their own separate terms that GolemBot does not govern.

Editorial conclusion

Adopt it if you already trust one of the four Coding Agent CLIs and want that same agent reachable from Slack, Telegram, Feishu or an HTTP endpoint without writing a framework. Skip it if you need per-user isolation, a hosted multi-tenant service, or an agent whose behaviour you control at the prompt level, since GolemBot deliberately does not touch prompting. Before committing, verify two things on your own machine: that your chosen engine authenticates headlessly with the key named in .env.example, and that golem.yaml on your branch actually accepts the engine and provider keys the README shows, because the README does not document the full config schema.

Frequently asked questions

Official sources

1. 0xranx/golembot on GitHub
2. License: MIT
3. Project website
4. README
5. Releases