cc-connect: run Claude Code, Cursor and Codex from Feishu, Slack or Telegram

The problem cc-connect solves for developers who run agents locally

Coding agents such as Claude Code, Cursor, Gemini CLI and Codex run on a developer's own machine, which is where the code and the credentials live. That is also the constraint: the session is tied to a terminal on that machine. If you step away from the desk, the agent stops being reachable, and the usual workarounds (a public tunnel, a VPS, a remote shell) either expose the machine or add infrastructure you then have to maintain.

cc-connect takes a different route. It runs as a local process that connects outbound to a messaging platform, so the chat app becomes the control surface and the agent keeps running where the code is. The README states that no public IP is required for most platforms, which is the practical difference from exposing a web endpoint yourself. The intended user is a developer or small team that already has an agent installed and configured locally, and wants to check on a build, ask for a fix, or start a task from a phone or another machine without opening a port.

Architecture: a Go binary between the agent CLI and the chat platform

The repository is a Go module, github.com/chenhg5/cc-connect, built from ./cmd/cc-connect. The layout separates the concerns: agent/ holds the agent integrations, platform/ holds the messaging integrations, core/ and daemon/ hold the running process, config/ and config.example.toml hold configuration, and web/ is an optional component that the Makefile treats as an extra build tag. The go.mod file shows the concrete dependencies for each side. On the platform side there are official SDKs: github.com/larksuite/oapi-sdk-go/v3 for Feishu/Lark, github.com/open-dingtalk/dingtalk-stream-sdk-go for DingTalk, github.com/slack-go/slack, github.com/go-telegram/bot, github.com/bwmarrin/discordgo, and github.com/line/line-bot-sdk-go/v8.

Two details in that dependency list say something about how it runs. The DingTalk integration uses a stream SDK rather than a webhook handler, which matches the claim that most platforms do not need an inbound public address. And the build depends on github.com/creack/pty, a pseudo-terminal library, alongside Bubble Tea and Lip Gloss from Charm. That points to the agent side being driven through a terminal session rather than a bespoke API for each agent, which is a reasonable way to cover many CLI tools at once but also means behaviour is tied to how each tool renders and accepts input in a PTY.

Configuration is TOML, parsed with github.com/BurntSushi/toml, and there is a config.example.toml at the repository root plus provider-presets.json and skill-presets.json for preset data. State appears to use SQLite through modernc.org/sqlite, a pure-Go driver with no cgo requirement, and github.com/robfig/cron/v3 is present for scheduled work. The Makefile also carries build tags for selective compilation, which is the most interesting architectural choice here: you are not obliged to ship every agent and every platform in one binary.

Installing cc-connect and running a first session

The repository ships INSTALL.md at the top level, and that is where the project points readers for setup; the README itself does not carry the install steps. There is also an npm package, cc-connect, referenced by the npm downloads badge and the npm/ directory, so a Node-based install path exists alongside building from source.

If you build from source, the Makefile is the entry point. The default build includes every agent and every platform, which produces a large binary. The Makefile documents the selective form in a comment, and the same comment shows how to exclude integrations instead:

make build AGENTS=claudecode PLATFORMS_INCLUDE=feishu,telegram
make build EXCLUDE=discord,dingtalk,qq,qqbot,line

The first command compiles a binary containing only the Claude Code agent and the Feishu and Telegram platforms. The second keeps everything except the listed platforms. Both accept comma-separated values, and the Makefile computes the exclusion tags from whatever you pass. If you mistype an agent or platform name, it will simply be treated as excluded, so check the ALL_AGENTS and ALL_PLATFORMS lists in the Makefile before you build.

After a build, configuration comes from TOML. The repository provides config.example.toml as the template, and the config/ directory holds the configuration package. Copy the example, fill in the credentials for the platform you selected, and point the agent entry at the CLI you want to drive. The example file is the authoritative list of keys; the README does not restate them, so treat the file itself as the reference rather than any snippet you find elsewhere.

For a first real use, pick one agent and one platform, build with AGENTS and PLATFORMS_INCLUDE set to just those two, start the binary, and send a message from the chat app. What you should see is the agent's output arriving as messages in the conversation. The Makefile also exposes a VERSION variable pinned to v1.5.1-beta.1, which is stamped into the binary along with the commit and build time via ldflags, so a locally built binary reports the version it was built from.

Where cc-connect is the wrong tool

The most obvious limitation is the release channel. The newest tag in the repository is v1.5.1-beta.1, dated 2026-08-28, and the stable tag before it is v1.5.0 from 2026-08-16. If your policy is to run only stable releases, you are one version behind whatever the maintainers are currently iterating on, and the beta line is where recent work is landing.

The second limitation is the security model. Bridging a coding agent, which can read and modify a local repository and run commands, into a chat platform means anyone who can post in that conversation can potentially direct the agent. The README describes the transport and the platform list but does not lay out an authorization or permission model, and there is no mention of how per-user access is scoped. That is not a reason to avoid the project, but it is a reason to treat the chat channel as a privileged interface and to verify the configuration yourself before pointing it at a machine with credentials on it.

Third, the licence. The README carries an MIT badge linking to the LICENSE file, but the repository metadata available here does not state a licence identifier, so confirm the LICENSE file directly if licence terms matter to your organisation.

Finally, the PTY-based approach that makes broad agent coverage possible also sets a ceiling. Agents whose interfaces change, or that expect a specific terminal, may behave differently than they do in an interactive shell. The README does not document a compatibility matrix per agent version.

How cc-connect differs from a self-hosted agent server

The natural alternative is running the agent itself as a network service: a server process with an HTTP or WebSocket API that you reach over a tunnel or a VPN. Projects in that space generally assume you will host something with an inbound endpoint and manage its authentication. cc-connect inverts that. It is a local process that dials out to a chat platform, and for most of the supported platforms the README states no public IP is required. The trade-off is that you inherit the chat platform's identity and access model instead of defining your own, and you depend on that platform's SDK and availability.

A second alternative is a general-purpose remote shell or terminal multiplexer, which gives you the raw session rather than a chat abstraction. That is more flexible and less structured: you get the terminal, but you also get no message formatting, no per-platform adapters, and no preset configuration for agents. cc-connect's value is the adapter layer, and the build tags let you compile only the adapters you actually use.

Maintenance, release cadence and upgrade cost

The repository is not archived, and the last push was on 2026-09-20. The recent tag history shows three releases between 2026-08-16 and 2026-08-28, two of them betas, which suggests active iteration with a stable tag roughly every few weeks. There is a CHANGELOG.md at the root and a changelogs/ directory, so upgrade notes have a home; the README does not document a rollback procedure, so plan upgrades by keeping the previous binary and its config.

Upgrade cost is mostly a function of how you built the binary. Because the Makefile supports build tags, a minimal build (one agent, one platform) has a small dependency surface to re-verify, while a default build pulls in every platform SDK in go.mod: Feishu, DingTalk, Slack, Telegram, Discord, LINE, and the rest. The module targets Go 1.25.0, so your toolchain needs to be at least that new to build from source. If you install through npm, the npm/ directory is the relevant path and the Go toolchain requirement does not apply to you.

On licensing, the README displays an MIT badge pointing at the LICENSE file, which for most teams means permissive use with attribution. That is a statement about what the repository shows, not legal advice; read the LICENSE file and the licence terms of each platform SDK you compile in, since those are separate agreements.

Editorial conclusion

Adopt cc-connect if you already run at least one supported agent locally and want to reach it from a chat app you already use, particularly on Feishu, DingTalk or Telegram where the README says no public IP is required. Skip it if you need a documented security model or a stable release channel, because the latest tag is v1.5.1-beta.1. Before committing, read INSTALL.md, run make build with only the AGENTS and PLATFORMS_INCLUDE you need, and confirm that the platform you plan to use is listed under ALL_PLATFORMS in the Makefile.

Frequently asked questions

Official sources

1. chenhg5/cc-connect on GitHub
2. Issues
3. README
4. Releases