MetaBot and the shift from terminal to chat for coding agents

An agent you talk to instead of a terminal you attach to

MetaBot is infrastructure for a supervised, self-improving agent organization, and the shipping edition is the personal one: a self-hosted workbench that runs on your own machine with no dependency on enterprise SSO, OIDC, VPN or an employee directory.

The product idea is simple to state. You already pay for native subscriptions to Claude Code and Kimi Code, or you have a Codex CLI, and you already live in a chat app. MetaBot connects the two: you message a bot in Feishu or Lark, Telegram, Slack, WeChat or the browser console, and a real coding engine does the work on your machine. The demo screenshots follow that arc, showing a team being summoned from the Feishu mobile app, work being assigned, agent progress being followed, and a pull request being merged.

The description calls it infrastructure for a supervised, self-improving agent organization, and the individual pieces are visible in the capability list. Agent Teams create dedicated teammates with persistent task and run state. MetaMemory retrieves knowledge across sessions and can sync to a Feishu knowledge base. T5T and Goal provide persistent project checkpoints and supervised multi-round execution. There is a task scheduler, an Agent Bus communication layer, a skill hub, and CLI access, all sharing one token and one navigation surface in the Core Console.

The supervision part is concrete rather than aspirational. The Core Console chat shows streaming replies, tool executions and output files in one page, and you can answer an agent's interactive questions, stop a run, and dictate input through the browser or the Bridge speech-to-text path. Writes and long tasks are things you watch and approve, which is what separates this from running a headless agent on a server.

The audience is a person or a small team with a machine to run it on. The personal edition explicitly has no user directory, which is both its selling point and its limit.

Codex and Kimi Code as engines, Claude Code as a compatibility path

The engine design is the part of MetaBot that most affects whether it works for you, and it has changed recently. Codex is the default engine and Kimi Code is a first-class optional one. Claude Code is retained for compatibility so that existing Claude bots and workspaces keep running.

The integration styles differ, and the difference matters. Codex is driven through `codex exec --json` and `codex exec resume`, with authentication either through `codex login` or an OpenAI-compatible API configuration. The open source Codex adapter currently uses `codex exec`; the Codex app-server and in-flight steering from Feishu for Codex and Kimi are stated to be opened later once the base chain is complete.

Kimi Code 0.27 and later is reached through the official local Server API, same origin as the Kimi web front end, and authenticates with `kimi login`. That path carries persistent sessions, atomic snapshots, question interaction, stop and resume, tools, sub-agents and Goal.

The Claude compatibility path goes through the Claude CLI and the Agent SDK compatibility route, authenticating with `claude login` or an Anthropic-compatible API. The README is explicit about what it means in the open source edition: existing Claude sessions, skills and workspaces keep working, and the capabilities list for that engine is about continuity rather than new reach.

One design decision is worth calling out because it will save you a configuration headache. Each engine keeps its own workspace conventions, and MetaBot does not force one on the other:

| Content | Codex | Kimi Code | Claude compatible | | --- | --- | --- | --- | | Workspace notes | `AGENTS.md` | `AGENTS.md` | `CLAUDE.md` compatible entry | | Skills | `.codex/skills/` | `.agents/skills/` | `.claude/skills/` | | Subscription state | Codex profile | `~/.kimi-code/` | Claude credentials |

The installer mirrors the built-in MetaBot skills into the current engine path while keeping skills you have already modified locally. Each bot picks its engine in `bots.json`, and when the field is omitted the default is `codex`.

One bridge process, many bots with their own engines

The multi-bot model is the part that makes MetaBot an organization rather than a single assistant. A single Bridge process can mix engines and workspaces, and every bot owns its own channel credentials, engine, working directory and session, while still being able to collaborate through Agent Teams and the Agent Bus.

The configuration file is `bots.json`, and the shipped example is small enough to read in one go:

{
  "feishuBots": [
    {
      "name": "codex-dev",
      "engine": "codex",
      "feishuAppId": "cli_xxx",
      "feishuAppSecret": "...",
      "defaultWorkingDirectory": "/home/me/project-a"
    }
  ]
}

A second bot in the same file can point at a different engine, a different directory and a different app, which is what makes the review pattern possible: a development bot on Codex working in one project, a reviewer bot on Kimi working in another. The `defaultWorkingDirectory` field is the isolation boundary per bot, and the per-engine option for Kimi, such as enabling thinking, sits alongside it.

The Slack variant of the same entry uses a bot token and a signing secret instead of a Feishu app id and secret, with the same engine and working directory fields. There is also a Lark international detail: if the app was created in the international Lark console, the corresponding `feishuBots` entry adds `"larkDomain": "lark"`, and the API and WebSocket then use the international domains, while the domestic Feishu domains remain the default when the field is absent.

Pointing the project at a config file is a one line environment change, and when `BOTS_CONFIG` is set the single-bot channel variables are ignored:

BOTS_CONFIG=./bots.json

That switch is the recommended mode in the configuration template, and the repository ships a matching `bots.example.json` for the file format.

Installing on your own machine and checking the services

Installation is a single command that pipes a release script into a shell, and the README says the signed installer takes about five minutes to deploy the full personal edition, meaning the local Core, the token-only Web UI, the IM Bridge, the CLI, the skills and the PM2 services:

curl -fsSL https://github.com/xvirobotics/metabot/releases/latest/download/install.sh | bash

The prerequisites are Node.js 22.19 or newer, Git, and credentials for at least one engine and one chat channel. The engines are installed and logged into separately, in their own terminal, so you can use a native subscription rather than an API key:

npm install -g @openai/codex
codex login

npm install -g @moonshot-ai/kimi-code@latest   # Kimi Code 0.27+
kimi login

After that, the flow is: run the installer, choose an engine and log in, connect a channel following the guided steps for Feishu or Lark, Telegram or WeChat, and if you want Slack, configure the Events API through the Slack guide. Then verify the services and open the console:

metabot status
metabot health

The local Core and personal console default to `http://localhost:9200`. You paste the token from `~/.metabot-core/token` and pick a bot. There is only one Web front end now, the Core Console, and the old Bridge entry at `http://localhost:9100/web/` redirects to `http://localhost:9200/chat` instead of being built or maintained separately.

The security posture of the local install is worth stating. The installer generates a Bearer token, saves it with `0600` permissions to `~/.metabot-core/token`, and does not write it to logs. Core data lives under `~/.metabot-core/` by default and Bridge state under `~/.metabot/`. Release assets have their checksums verified before extraction. The default install directory is `~/metabot`, overridable with `METABOT_HOME=/opt/metabot bash install.sh`, and setting `METABOT_INSTALL_CORE=0` still lets you connect to an existing external Core. Source checkouts and release installs keep separate update paths, and `metabot update` does not guess between them.

Channel plumbing differs more than the docs admit

The transport story is where the real integration work lives, and the transport is different for every channel.

Feishu and Lark use a long-lived WebSocket connection. Telegram and WeChat use long polling. Slack uses the Events API, which needs an endpoint at `/api/slack/events/<botName>` that Slack can reach, protected by an HTTPS reverse proxy. That last one is the only channel in the list that requires public ingress, and it is also the one where the deployment docs have the most to say about certificates and proxy configuration.

Routing inside a group chat is a per-bot, per-group policy. In a Feishu group, an ordinary message is routed only to the bot that was mentioned accurately. The group owner can set a reply mode per bot and per group with `@Bot /group-reply ...`, choosing mention-only or reply to all messages. Bare commands and commands that mention only other bots are ignored, and in mention-only mode a file that was not attached to the mention is kept for the next `@Bot` instruction rather than being consumed.

The WeChat route is the least settled. It connects a personal WeChat account through ClawBot, and the channel table marks it as currently in limited testing, which in practice means you should not build a critical workflow on it yet.

The web console is the fallback for everything, reachable at `http://localhost:9200`, and it covers browser chat plus the Core, Memory, Teams and settings surfaces. The Agent Teams, Memory, Skills, T5T, Teams and CLI Access pages all share the same token and the same navigation, so the console is the control surface and the chat apps are the remote control.

Where the container and the documentation disagree

The Dockerfile and the README do not agree on the runtime, and this is the clearest defect in the project. The documented prerequisite is Node.js 22.19 or newer, and the package badge says the same. Both stages of the Dockerfile are built on node:20-slim, and the runtime stage installs the Claude Code CLI with `npm install -g @anthropic-ai/claude-code` and starts the server with `node dist/index.js` on port 9100.

A container image that runs Node 20 while the project asks for Node 22.19 will install, and it may well work for the paths it exercises, but it is not the environment the documentation describes, and it is the environment a Docker user will actually get.

The compose file adds more context and more caveats. The service builds from the local Dockerfile, publishes `${API_PORT:-9100}:9100`, loads `.env`, and enables a memory sidecar through `META_MEMORY_URL`, `MEMORY_ENABLED`, `MEMORY_PORT` and `MEMORY_DATABASE_DIR`. Named volumes persist the memory database and the Claude configuration, and the working directory is mounted at `/workspace` from `CLAUDE_DEFAULT_WORKING_DIRECTORY`, with the comment that you should run `claude login` inside the container first. The compose file is also still written around Claude Code, with a `claude-config` volume and a Claude CLI install, while the README's primary engines are now Codex and Kimi Code.

The cost side has a control worth using, and it comes from the configuration template. The environment file carries `CLAUDE_DEFAULT_WORKING_DIRECTORY` alongside commented limits for `CLAUDE_MAX_TURNS=50` and `CLAUDE_MAX_BUDGET_USD=1.0`, and a `CLAUDE_MODEL` setting. For a system where a chat message can start a long agent run, a turn cap and a budget cap are the difference between a demo and a production deployment.

The other trap in the template is the Codex key handling. The comments state that `CODEX_API_KEY` is normalized to `OPENAI_API_KEY` for the Codex child process, and that `CODEX_BASE_URL` is passed as `-c openai_base_url="..."`, so anyone wiring a self-hosted or proxy endpoint needs to read those two lines carefully.

MIT, an active repository, and a version that tracks the engines

MetaBot is MIT licensed, with the text in the LICENSE file, and the repository is not archived. The last push was on 2026-09-15, and the release line moved quickly around it: v1.3.0 on 2026-07-24, v1.3.1 on 2026-09-11 and v1.3.2 on 2026-09-15, which is also the version recorded in the package manifest.

The package is a TypeScript monorepo with npm workspaces covering the CLI, the core CLI, MetaMemory, the skill hub, the server and the web UI, with the source under src/ and tests under tests/ run by vitest. There is a spike/ directory that suggests the project is still probing its own architecture, a scripts/ directory with the release packing script, an ecosystem.config.cjs for PM2, mkdocs.yml for the documentation site, and both install.sh and install.ps1 for the two platform installers, plus uninstall.sh and setup.sh. The commit history shows both GitHub Actions and a GitLab CI configuration, and a gitleaks.toml is present, which is a sensible inclusion for a project that handles tokens.

The upgrade cost for an adopter is therefore the engine surface, not the code. Each engine adapter tracks an upstream CLI that changes on its own schedule, and the README is candid that the Codex adapter currently uses `codex exec` while app-server support and in-flight steering are still to come. When an upstream CLI changes its output format or authentication, the adapter in this repository has to follow.

Licence wise the project is simple, MIT with no commercial rider mentioned in the files shown, and the token model keeps the credentials on your own machine. The documentation itself is bilingual, with an English README and a Chinese one, and a documentation site that has separate Chinese and English paths.

Editorial conclusion

MetaBot fits an individual or a small team that wants a coding agent reachable from a phone, with per-bot engines, working directories and credentials held on their own machine. It does not fit a team that needs multi-tenant isolation, an audited server deployment, or Node 22 in a container. Before adopting it, read the Docker file against the documented Node.js >= 22.19 requirement, and set CLAUDE_MAX_BUDGET_USD before letting a chat message trigger a long run.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. xvirobotics/metabot on GitHub