cc-connect

cc-connect is a bridging tool that allows you to control local AI agents from any instant messaging platform. It connects AI agents running on your local machine to messaging apps like Feishu/Lark, DingTalk, Telegram, Slack, Discord, WeCom, and others.

By using cc-connect, you can perform tasks such as:

• Code Review: Inspect or modify code via chat.
• Research & Data Analysis: Run complex queries and analyze data.
• Automation: Execute commands and handle automation tasks directly from your mobile device, tablet, or any device with a chat app.

Essentially, it brings the power of your local CLI-based AI agents (like Kimi CLI) into your daily chat workflows, enabling you to work on local projects anywhere, anytime.

cc-connect is a multi-agent orchestration tool that connects AI agents to various chat platforms.

Key Features:

• Universal Agent Support: Supports 10+ agents including Claude Code, Codex, Cursor, Gemini, and any agent following the Agent Client Protocol (ACP).
• Platform Flexibility: Connects to 13+ platforms like Feishu, DingTalk, Telegram, Slack, Discord, and Weixin (personal).
• Multi-Agent Orchestration: Bind multiple bots in a group chat to allow them to communicate with each other.
• Chat Control: Manage sessions and models via slash commands (e.g., /model, /reasoning, /dir).
• Persistent Memory: Manage agent instruction files directly via /memory.
• Intelligent Scheduling: Set up cron jobs using natural language.
• Multimodal Support: Handles voice (STT/TTS) and images/screenshots.

The Slack platform implementation in cc-connect includes the following capabilities:

• App Mention Support: Handles @bot mentions in channels using AppMentionEvent and provides stripAppMentionText() to clean message text.
• Slash Command Support: Handles socketmode.EventTypeSlashCommand events, converting Slack /command inputs into engine commands (e.g., /btw, /new, /stop).
• Typing Indicators: Uses emoji reactions via StartTyping() to simulate typing. This includes an initial 'eyes' reaction, a 'clock' reaction after 2 minutes, and random emojis every 5 minutes, all of which are cleaned up upon completion.
• Security: Supports allow_from user allowlisting, token redaction in error messages, and old message filtering via core.IsOldMessage().

The Bridge Protocol allows external platform adapters written in any programming language to dynamically connect to cc-connect at runtime via WebSocket. This enables integration of platforms (like WeChat Official Accounts) without requiring Go code or recompiling the cc-connect binary.

BridgePlatform is the built-in implementation within cc-connect that:

1. Exposes a WebSocket endpoint for external adapters.
2. Converts incoming WebSocket messages into core.Platform interface calls.
3. Routes responses from the Engine back to the adapter through the same WebSocket connection.

Choose the connection mode based on your environment and complexity requirements:

Note: cc-connect includes an automatic reconnection mechanism for Long Connection mode.

To prevent invisible context degradation, cc-connect provides a way to track how much of the model's context window is being used. This is displayed as a percentage appended to every message relayed to the platform.

Implementation Details:

• SDK Token Counts (Primary): The system parses result events for input_tokens usage in processInteractiveEvents. It computes the percentage as: input_tokens / 200_000 * 100.
• Claude Self-Report (Secondary/Comparison): An instruction is added to the system prompt via --append-system-prompt asking Claude to append [ctx: ~XX%] to its responses. The system parses this value to compare against the SDK count.

Display Format: If token data is available, the indicator appears at the end of the message:

Here's the refactored auth module...
[ctx: 62%]

The system tracks and displays context window consumption to help users manage session size.

Context usage is calculated based on input tokens relative to a 200,000 token limit. The resulting percentage is appended to relayed messages (including tool use, thinking, and final results) in the format [ctx: XX%].

This allows users to monitor when they might need to run /compact to prevent session context loss.

Since the MAX public bot API does not sign deliveries, you should secure your webhook endpoint using one of these methods:

1. webhook_secret via Query Parameter: Add ?s=<secret> to your webhook_url. The bot verifies the s parameter.
2. webhook_secret via Header (Recommended): If using a reverse proxy like nginx, configure the proxy to inject the secret as an X-Webhook-Secret header. This keeps the secret out of access logs and URLs.
3. allow_from: Always restrict the bot to specific user IDs in production to prevent unauthorized interaction even if the webhook is reached.

location /webhook {
    proxy_pass http://127.0.0.1:8090;
    proxy_set_header X-Webhook-Secret "long-random-string-here";
    # ...
}

The /usage command follows a decoupled architecture between the command engine and the specific AI agents (like Codex or Gemini).

1. Command Layer: The core engine (core/engine.go) registers /usage. It does not contain provider-specific logic; it only detects if the active agent implements the UsageReporter interface.
2. Agent Capability Layer: Agents can optionally implement the UsageReporter interface by providing a GetUsage(context.Context) (*UsageReport, error) method. This allows the engine to request quota data without knowing the underlying provider's API.
3. Implementation: Each agent (e.g., agent/codex) is responsible for its own authentication, API calls, and mapping provider-specific JSON responses into the project's generic UsageReport format.

The project uses a generic UsageReport data model to ensure compatibility across different AI providers. A report includes:

• Identity: provider, account_id, and user/email (if available).
• Plan: plan_type (e.g., tier level).
• Rate Limits: Standard and/or code-review limits, including:
  • allowed (boolean)
  • limit_reached (boolean)
  • primary window and secondary window details.
• Window Details: For each quota window, the report tracks used percent, total window seconds, reset-after seconds, and a reset timestamp.
• Credits: has_credits, unlimited status, and current balance.