# golembot, four coding agents on seven chat platforms with every sandbox switched off

> GolemBot is not a model wrapper. It launches a coding agent you already have as a child process and connects its standard streams to a chat platform, so a colleague can mention the bot in a group chat and the agent writes code on the machine it is installed on. The readme's own comparison table lists the launch flags for all four supported agents, and three of those four lines are flags whose entire purpose is to disable the agent's permission checks. The documentation is candid about it, which is not the same as the design being a good idea for a shared channel.

**0xranx/golembot** — Any Agent × Any Provider × Anywhere. Connect Cursor, Claude Code, OpenCode, or Codex to Slack, Telegram, Discord, Feishu, DingTalk, WeCom, WeChat — with any LLM provider.

- Repository: https://github.com/0xranx/golembot
- Website: https://0xranx.github.io/golembot/
- Stars: 321 · Forks: 45
- Language: TypeScript
- License: MIT
- Published: 2026-09-15 · Updated: 2026-09-15 · Language: en
- Canonical page: https://hysenlabs.com/projects/0xranx-golembot

## Every engine is launched with its permission checks turned off

The readme contains a table comparing the four supported coding agents, and one of its columns is a list of flags to disable safety. Cursor is started with a force flag, a trust flag, and its sandbox disabled. Claude Code is started with a flag whose name is a warning. OpenCode takes a permission configuration. Codex is documented twice, once for its default and once for the settings that change it.

Then there is this, in its own paragraph: if you run Codex, GolemBot defaults to an unrestricted mode, and you should set a different value if you want to keep Codex sandboxed. Four finer settings are available underneath that one, covering the sandbox, approvals, search, and extra directories.

So the default posture of the tool, stated by the tool, is a coding agent with no sandbox, reachable by anyone who can post a message in a connected chat channel. The readme does not present this as a risk to manage. It presents it in a table whose other rows are about session resumption and API keys, and the row above it is about what the tool saves you building.

## The service token ships commented out and the abort endpoint does not

The gateway starts three things at once according to the quick start: the chat integrations, an HTTP service, and a dashboard. The HTTP service has a bearer token, and the environment template in the repository shows what the project thinks of it:

```bash
CURSOR_API_KEY=
ANTHROPIC_API_KEY=
# GOLEM_TOKEN=
```

The token line is commented out and described as optional, with a note that it is generated automatically during tests. So out of the box the control plane has no credential.

Three ways to cancel a running task are documented, and they are worth reading together. There is a command for the interactive prompt and the same command over chat. There is a method you call in code, and it takes an optional session key. And there is an HTTP endpoint whose job is to stop the current task without clearing the session's history.

That third one is the one to think about. An unauthenticated endpoint that cancels work but preserves the transcript is an unusual thing to expose by default, and the readme's framing, that a long task can be stopped without losing your session, presents it as a convenience rather than as a capability to protect.

## Skills land in a different directory for each of the four engines

The same table that lists the permission flags also lists where each engine expects its skills, and the four answers share no path. One wants a directory under a cursor-specific folder. One wants a directory under a different vendor's folder plus a markdown file at the root. One wants a third vendor's folder plus a JSON file. The fourth wants a single markdown file at the workspace root and nothing else.

So a project that supports more than one engine needs up to four parallel layouts, and GolemBot's job is to write the right one. The repository root shows what that looks like from the inside: a directory for one of the vendors, a markdown file for the second vendor, and a third markdown file at the root. This project configures itself for three agents at once.

The published package adds two more directories on top. The manifest's file list ships the build output, a skills directory, and a templates directory, excluding the test folder from the build output with an explicit negation. Installing the package therefore drops a skills folder and a templates folder at the root of the project you are working in, next to whatever the agent's own CLI wants to put there. That negation in the file list is the fingerprint of a whitelist that has already leaked once.

## Provider freedom has one hard protocol exception

The pitch is any agent with any provider, and the readme names five to make it concrete: two aggregators and three model vendors. For three of the four engines that claim holds without qualification, and the readme's own table says so by naming the environment variable each one reads.

The fourth is different. OpenCode's key is described as depending on the provider, because OpenCode is the engine that does not have an opinion about which service it talks to. Codex is the one with a constraint, and the constraint is stated in a paragraph rather than a table: route it through a custom provider and that provider has to implement a particular response protocol. Providers that only expose the two other common endpoint shapes will fail.

Fail is the whole of the error documentation. There is no message quoted, no exit code, no suggestion to check a log. For a user who has followed the readme's provider list, configured a key, and picked an engine, this is the paragraph that decides whether the afternoon goes well, and it sits below a table about session resumption.

## The capability argument rests entirely on the CLI you already installed

The strongest claim in the readme is a single table row: when the agent gets smarter, the assistant gets smarter, with no code changes. It is a real architectural advantage and it is the reason the project exists. The tool does not implement an agent; it starts one and reads its output, so a model release or a new agent feature arrives without the bridge changing.

The cost is that the bridge is a set of command line flags and a stream of events, and both belong to programs this project does not control. The readme promises that the event interface is identical across all four engines so switching requires no code change, and it presents that as a guarantee. It is a guarantee about the wrapper, not about the four command line programs underneath it.

Nothing in the table records which version of any agent the flags were written against. A flag renamed, a subcommand moved, an output line changed, and the integration fails at the point of use with whatever error the CLI produced. The argument that you get the agent's improvements for free and the risk that you get its breaking changes for free are the same fact.

## Publishing runs the build and none of the tests

There is a test runner, a watch mode, a coverage-free test script, and six end-to-end scripts, one per engine plus a headless variant and a launcher variant. Every one of them is a manifest entry a contributor can run.

The publish hook runs the build. That is its whole contents. So the gate before a version reaches the registry compiles the TypeScript and executes nothing, not the unit suite and not any of the six end-to-end scripts that exist specifically to drive real agents against real chat platforms.

The release itself is delegated to a tool that derives versions from commits, and a configuration file for it sits in the root alongside a changelog. The three published tags tell you what that produces: each is titled with nothing but its own version number, so the notes carry no description of anything. The tags are 0.49.2 in early September 2026, 0.50.0 later that month, and 0.51.0 a few days after that, with two minor bumps in three weeks.

A minor bump per release means a reader cannot tell a feature from a breaking change by looking at the version, and the default branch was pushed on 29 September 2026, four days after the newest tag.

## The container runs the published package inside the host project

There is a container path in the repository and the readme does not mention it. The image is built from a slim Node base, installs the package globally, sets a working directory, copies the build context in, and runs a production-only install if a manifest is present in what it copied:

```dockerfile
FROM node:22-slim
RUN npm install -g golembot
WORKDIR /assistant
EXPOSE 3000
CMD ["golembot", "gateway"]
```

The compose file then bind mounts the host project onto that working directory, publishes one port, loads a local environment file, sets production mode, and restarts the container unless it is stopped. Put together, the container runs the globally installed published build while the host project is mounted as the agent's workspace, which means the agent's file operations act on the host directory and the permission flags from the engine table apply to it.

The environment file it loads is the one whose token line is commented out, and the same file describes both of its API keys as being required for tests rather than for running the gateway. So the container path inherits a disabled service token and a test-framed key template, and a reader has to derive all of that from three files the front page does not link to.

## The architecture diagram stops in the middle of a word

The one diagram that explains how seven chat platforms reach four coding agents is a block of drawn characters that ends mid-word, at the start of the line describing provider routing. The rest of the diagram is present and correct as far as it goes: channels at the top, custom adapters for sources the project does not ship, a gateway service, the assistant factory in the middle, and the four engines fanned out below.

The two dashboard screenshots are worse. Both are centred paragraphs containing nothing at all, in the sections describing the built-in dashboard and the aggregated fleet dashboard, so the two features the readme describes in prose have no picture.

What is left carrying the argument is the video, hosted as a user attachment rather than in the repository, and the nine-row comparison table. The table is worth reading as a document in its own right, because it is the project's persuasion and every cell in the right-hand column is a claim about what you would otherwise have to build. Rows like the one contrasting a directory listing against an opaque pipeline, and the one about a built-in scheduler, are assertions about alternatives rather than measurements of this project, and no row cites anything.

## Conclusion

Use golembot on a machine you control, on a channel where everyone in it already has the equivalent of shell access, and treat the permission flags as the first thing to change rather than the last. Four checks before you start a gateway. That the engine you pick is not running with its sandbox off, because the readme's own table shows three of the four being launched that way and names one engine whose default is unrestricted with a safer mode available behind a setting. That the HTTP service has a bearer token set, because the environment template ships that line commented out. That you know which directory the skills land in for your engine, since the four supported agents want four different layouts. And that you pin the agent CLI, because the integration is a set of command line flags with no version recorded against them.

## FAQ

### What is golembot and how does it work?

GolemBot connects a coding agent you already have, such as Cursor, Claude Code, OpenCode, or Codex, to chat platforms including Slack, Telegram, Discord, Feishu, DingTalk, WeCom, and WeChat, plus an HTTP service. It launches the agent as a child process and routes messages to it, so the agent runs on the machine where GolemBot is installed rather than behind a model API.

### How do I install golembot and get a bot running?

Install the package globally, create a directory, then run the guided setup. The manual path initialises a bot for a chosen engine and name, starts an interactive session, or starts a gateway that brings up the chat integrations, an HTTP service, and a dashboard. A fleet command lists running bots, and a skill command searches a community skill catalogue.

### Does golembot run coding agents inside a sandbox?

Not by default. The readme's engine table lists a force flag, a trust flag, and a disabled sandbox for one engine, a skip-permissions flag for another, and states that for Codex GolemBot defaults to an unrestricted mode with a safer mode available as a setting, alongside finer settings for the sandbox, approvals, search, and extra directories.

### Which model providers can golembot use with each engine?

The readme names two aggregators and three model vendors, and says any LangChain style chat model is not required since the engine is the brain. Three engines read a named environment variable for their key. Routing Codex through a custom provider is the exception: that provider must support the OpenAI Responses API, and providers exposing only the chat completions or messages endpoint shapes will fail.

## Sources

- [0xranx/golembot on GitHub](https://github.com/0xranx/golembot)
- [License: MIT](https://github.com/0xranx/golembot/blob/main/LICENSE)
- [Project website](https://0xranx.github.io/golembot/)
- [README](https://github.com/0xranx/golembot/blob/main/README.md)
- [Releases](https://github.com/0xranx/golembot/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/0xranx-golembot