mrkeyoor.com_
Wed 09 Sept 17:43 UTC
LLM Toolsevaluationupdated 09 Sept 2026

cc-connect review

CC-Connect is a Go bridge that lets you operate local AI coding agents from chat services instead of staying at the development machine. It connects tools such as Claude Code, Cursor, Gemini CLI, and Kimi CLI to services including Slack, Discord, Telegram, Feishu/Lark, DingTalk, and WeCom.

trackingstars / 7d
Verdict

Our build succeeded in 11 seconds, but 7 of 93 tests failed. CC-Connect is a compelling shortcut if you genuinely need one local coding agent across several chat networks, and its active repository makes it worth a trial. Do not treat it as a drop-in production control plane yet: reproduce the test result, verify the license, and lock down who can trigger code changes or commands.

We ran it

Install✓ · 48s291 packages
Build✓ · 11s
Tests✗ · 190s86 passed · 7 failed of 93 (go test)
Repo653 files~225,860 lines of source · 19.8 MB · 3 CI workflows · tests dir

Answers from our run

Does cc-connect build from source?

Dependencies installed in 48 seconds (291 packages), and the build succeeded in 11 seconds. We cloned commit 4000b23 into a clean Debian container with 3 CPUs and no project-specific setup.

Do cc-connect's tests pass?

Not all of them: 86 of 93 passed and 7 failed when we ran the project's own test command (go test). Some failures need services or credentials a bare container does not have.

Who should not use cc-connect?

Anyone who cannot safely expose a local coding agent to remote messages

What are the alternatives to cc-connect?

Bolt for JavaScript, discord.js, Lark OpenAPI SDK for Go. Our build succeeded in 11 seconds, but 7 of 93 tests failed.

Setup3/5Installed and built quickly, but 7 of 93 tests failed
Docs3/5Clear purpose and platform list; operational detail remains unclear
Community4/515,433 stars and a same-day push, tempered by 574 open issues
Maturity3/5Recent v1.5.0 release, but our full test run did not pass

Who it’s for

Developers who want to check or continue local coding work from a phone
Teams already using Slack, Discord, Telegram, Feishu/Lark, DingTalk, or WeCom
Self-hosters willing to manage chat credentials and protect command access
Go teams that want one bridge instead of maintaining several platform bots

Who it’s NOT for

Anyone who cannot safely expose a local coding agent to remote messages
Teams requiring a clean test run before adoption, because 7 of 93 tests failed for us
Buyers who need a clearly verified license before deployment
People seeking a hosted, zero-configuration service rather than a self-managed bridge

Setup reality

On our box, installation succeeded in 48 seconds with 291 packages installed, and the build succeeded in 11 seconds, but the test step failed after 190 seconds: 86 of 93 tests passed and 7 failed. The final log lines show several platform and release-local packages passing before a bare FAIL, so they do not establish the cause of the failures. The README makes the product's reach easy to understand, but a real rollout still means configuring chat platforms, local agents, credentials, and access boundaries; budget time to investigate the failed tests before trusting it with a working directory.

It turns chat into a remote control for local coding agents

CC-Connect addresses a specific inconvenience: coding agents often run on a developer's machine while the developer is elsewhere. It puts a chat layer in front of that local work, letting messages reach Claude Code, Cursor, Gemini CLI, and Kimi CLI. Its 15,433 GitHub stars show substantial interest, but its value still depends on whether remote access to a live development environment is useful to you.

The breadth is the main attraction. The README names Feishu/Lark, DingTalk, Telegram, Slack, Discord, WeCom, and other messaging services, so one bridge can potentially replace several bots. It describes asking an agent to inspect or modify code, troubleshoot problems, run commands, and handle automation. Version 1.5.0 therefore sits on a path from an ordinary chat message to real changes on a development machine.

What happened when we ran it

We cloned commit 4000b23 into a fresh, unprivileged Debian container with 3 CPUs and 8 GB of RAM. The checkout contained 653 files, about 225,860 lines of source, and occupied 19.8 MB. Installation completed successfully in 48 seconds with 291 packages installed, and the build completed in 11 seconds. Fetching dependencies and compiling were direct under our measured conditions.

The complete test step did not pass. It ran for 190 seconds, with 86 of 93 tests passing and 7 failing, then exited with status 1. The log tail shows successful packages for Webex, WeCom, Weibo, Weixin, WPS AgentSpace, WPS Xiezuo, Yuanbao, and 4 release-local groups before the final FAIL. It omits the failed names and errors, so assigning a cause would be speculation. Our build worked, but our test gate stayed red.

The repository does show investment in verification. We found 3 CI workflow files and a dedicated tests directory. There was no Dockerfile in the 653-file checkout, so the project does not provide that route to reproducible deployment. Our lab was containerized, but that is not a project-maintained runtime image.

Multi-platform coverage is the strongest reason to choose it

CC-Connect's platform list promises to absorb repeated integration work behind one Go codebase. The passing tail in our run names 7 distinct platform packages, evidence that the breadth appears in code and tests rather than only a feature graphic. For a team spanning Slack and Asia-focused workplace platforms, that consolidation is unusually attractive.

The local-agent angle is equally important. This is presented as a bridge to existing coding workflows and local project state, not a general chat bot framework. The README says users can continue work away from the machine and ask the agent to inspect or modify code. It is more immediately useful than a low-level SDK if the operator understands the risks of remote commands. Its Go implementation also built in 11 seconds in our environment.

The rough edges matter because the bridge can change code

Remote command access demands a higher standard than a read-only notification bot. A mistaken authorization rule, broad chat membership, or leaked credential can expose source code and shell commands. The excerpt shows many destinations, but not enough evidence to grade tenant isolation, command approval, audit logging, or safe defaults. Before production use, test those controls with the exact platform and agent, especially where more than 1 person can message the bot.

Licensing also needs a manual check. The README displays an MIT badge and links to a LICENSE file, yet the supplied metadata reports the license as unknown. That may be a detection problem, but a badge is not legal certainty. Confirm the license text and dependency obligations before company deployment. Documentation is also hard to call excellent: the goal is clear, but 7 failed tests leave an unresolved setup question.

Activity is strong, while the issue queue deserves attention

The latest release, v1.5.0, arrived on August 16, 2026, and the repository was pushed again on September 9, 2026, the day of this review. That argues against calling it abandoned. One release date cannot establish long-term cadence, but recent tagged and untagged activity is positive, alongside 15,433 stars.

The counterweight is 574 open issues. A large user base creates reports and requests, so the number alone does not prove poor maintenance, and no response-time or closure-rate data was supplied. Still, search those 574 items for the exact platform-agent pair you need. Community interest and same-day code activity look healthy, but support predictability remains unproven.

It belongs inside a guarded developer environment

In a real stack, CC-Connect fits between approved messaging accounts and coding agents near checked-out repositories. Use strict bot membership, least-privilege tokens, separate operating-system credentials, and recoverable version-control history. Begin with 1 non-critical project and a narrow command set, then inspect logs and failure behavior before widening access. It should complement CI and deployment controls, not bypass them.

Choose CC-Connect when multi-network coverage is required and you accept operating a shared bridge. Choose Bolt for JavaScript, discord.js, or the Lark Go SDK when 1 platform matters more and you want to own the command surface. On our box, the 48-second install and 11-second build earned a serious trial, while 7 failed tests prevented an unqualified recommendation.

Alternatives

ProjectWhat it isPick it when
Bolt for JavaScriptAn official-style framework for building a custom Slack app in JavaScript.Pick this instead when Slack is your only chat surface and you want full control over every command and permission.
discord.jsA JavaScript library for building directly against the Discord API.Pick this instead when Discord is the target and a purpose-built bot is preferable to a multi-platform agent bridge.
Lark OpenAPI SDK for GoA Go SDK for creating a custom Feishu/Lark integration.Pick this instead when Feishu/Lark is the only required platform and your team can build the AI-agent wiring itself.

What people are saying

  1. [github-trending] chenhg5/cc-connect

Sources

  1. CC-Connect GitHub repository
  2. CC-Connect releases
  3. CC-Connect CI workflow

More llm tools reviews

no-ai-slop · distilly · gpt4free · openai-agents-python · notfair-plugin · freecad-mcp · the whole board →