How to Connect Your Cline Agent to Slack, Telegram, and WhatsApp (May 2026)

The Cline CLI connector system bridges your local agent session to Telegram, Slack, WhatsApp, Discord, or Google Chat. You send a task from your phone, the agent runs it on your machine, and tool-call approvals come back to the same chat thread. The bridge runs as a local process alongside your agent; no separate server required for Telegram, which uses polling mode.

Run cline connect telegram -m <BOT_USERNAME> -k <BOT_TOKEN> and the bridge is up in under ten seconds. The rest of this guide walks through each platform, including the v3.0.8 fix that keeps renamed Telegram users linked to the same participant session.

What Cline CLI connectors do

Connectors give you a chat interface on top of the SDK that powers the connector system. Each connector opens a channel between a running Cline agent session and a messaging platform. From that channel you can:

• Send a new task in plain text ("Refactor the auth module to use JWT")
• Approve or reject tool calls the agent surfaces during execution
• Receive streamed output as the agent works

The connectors shipped as experimental in the SDK announcement and landed in Cline CLI in v3.0.8 (May 19, 2026). That same release patched a specific Telegram edge case: when a user renames their Telegram username, the connector now tracks them by numeric participant ID instead of username string, so the session stays linked. Before the fix, a renamed user would appear to the connector as a new, unrecognized participant.

That matters for team setups where developer usernames change on the org's Telegram workspace. The bridge no longer drops their active sessions.

Prerequisites

Install the CLI globally:

npm install -g @cline/cli

Verify the install:

cline --version

You'll also need an LLM provider configured. The CLI reads from ~/.cline/config.json or environment variables. Check cline --help for provider flags. Connectors work with any provider Cline supports; we've been running ours against Claude claude-sonnet-4-6 via Anthropic direct.

Supported connector platforms as of v3.0.8:

• Telegram (polling mode, no public URL needed)
• Slack (webhook mode, requires a public URL)
• WhatsApp (webhook mode, requires a public URL)
• Discord (webhook mode, requires a public URL)
• Google Chat (service account credentials, requires a public URL)
• Linear (webhook mode, requires a public URL)

Run cline connect --help to see the current list of available adapters.

Step 1: Set up the Telegram connector

Telegram is a quick platform to get running because it uses polling rather than webhooks. Your machine reaches out to Telegram; Telegram doesn't need to reach back.

Create a bot with BotFather.

1. Open Telegram and search for @BotFather.
2. Send /newbot and follow the prompts. BotFather gives you a username (e.g. my_cline_bot) and a token string (e.g. 7312045891:AAFz...).
3. Copy both.

Start the connector.

cline connect telegram -m <BOT_USERNAME> -k <BOT_TOKEN>

Replace <BOT_USERNAME> with the bot username BotFather gave you (without the @), and <BOT_TOKEN> with the full token string.

When the bridge is live, the terminal shows something like:

[cline-connector] Telegram bridge active
[cline-connector] Polling for updates on @my_cline_bot
[cline-connector] Agent session ready

Send a task from Telegram.

Open a chat with your bot and send a message:

Write a Python function that reads a CSV file and returns the row count

The agent picks it up, starts executing, and streams status back to the chat. If the task requires a tool call (file write, shell command), you'll get an approval prompt in the same thread.

Approve from chat:

approve

Reject and explain:

reject - use the csv module instead of pandas

The v3.0.8 participant ID fix means this conversation persists correctly even if you later rename your Telegram username. The connector stores your numeric ID, not the string handle.

Step 2: Set up the Slack connector

Slack uses webhook mode: Slack's servers push events to your connector process, which means you need a URL that Slack can reach. For local development, ngrok handles this. For production, you need a server with a stable public endpoint.

Create a Slack app.

1. Go to api.slack.com/apps and click "Create New App."
2. Choose "From scratch," name the app (e.g. "Cline Agent"), and pick your workspace.
3. Under "OAuth & Permissions," add the bot token scopes: chat:write, app_mentions:read, channels:history.
4. Install the app to your workspace. Copy the "Bot User OAuth Token" (starts with xoxb-).
5. Under "Basic Information," copy the "Signing Secret."

Start ngrok for local testing.

ngrok http 3000

ngrok prints a forwarding URL like https://a1b2c3d4.ngrok.io. Copy it.

Start the connector.

cline connect slack \
  --token <SLACK_BOT_TOKEN> \
  --signing-secret <SLACK_SIGNING_SECRET> \
  --base-url <NGROK_URL>

Replace the placeholders with your xoxb-... token, your signing secret, and the full ngrok URL.

Invite the bot to a channel and test it.

/invite @ClineAgent

Then send a message in that channel:

@ClineAgent Add input validation to the user registration endpoint

The agent receives the mention, runs the task, and posts status updates back to the channel.

For production deployments where you need a persistent public endpoint, a VPS or managed server works well. We've been routing our own Slack connector through a Cloudways-hosted node that stays live across reboots. Cloudways supports Node processes directly and gives you a static IP without managing nginx config by hand.

Production flag: swap the ngrok URL for your server's URL, restart the connector on the server, and update the Slack app's Event Subscriptions URL to point to the new address.

WhatsApp, Discord, and Google Chat (quick setup)

All three use webhook mode, so the same ngrok-to-production pattern from the Slack section applies.

WhatsApp

You'll need a WhatsApp Business account and a phone number ID from Meta's developer portal.

cline connect whatsapp \
  --phone-id <WHATSAPP_PHONE_ID> \
  --token <WHATSAPP_TOKEN> \
  --app-secret <WHATSAPP_APP_SECRET> \
  --base-url <YOUR_PUBLIC_URL>

WhatsApp is the right pick if your team already runs in WhatsApp groups and you want task delegation to feel native to that workflow. The approval flow works identically to Telegram.

Google Chat

Google Chat uses a service account JSON file for auth rather than a token string.

cline connect gchat \
  --credentials <PATH_TO_SERVICE_ACCOUNT_JSON> \
  --base-url <YOUR_PUBLIC_URL>

Create the service account in Google Cloud Console, download the JSON, and pass its local path to --credentials. Google Chat fits organizations that run on Google Workspace and want to delegate tasks from Spaces without leaving their existing environment.

Discord

cline connect discord \
  --app-id <DISCORD_APP_ID> \
  --token <DISCORD_BOT_TOKEN> \
  --public-key <DISCORD_PUBLIC_KEY> \
  --base-url <YOUR_PUBLIC_URL>

You'll register an application in the Discord Developer Portal to get these values. Discord is the strongest fit for developer communities or open-source projects where contributors already live in a Discord server.

When to pick each platform:

Platform	Auth model	Public URL required	Best for
Telegram	Bot token, polling	No	Solo devs, async approvals on mobile
Slack	OAuth token + signing secret	Yes	Team delegation, channel-based workflows
WhatsApp	Meta Business API	Yes	Teams already in WhatsApp
Google Chat	Service account JSON	Yes	Google Workspace orgs
Discord	App registration	Yes	Dev communities, open-source teams

Managing and stopping connectors

Multiple connectors run simultaneously. Start Telegram and Slack in separate terminal windows (or background processes) and both bridges stay active.

Stop a specific bridge:

cline connect telegram --stop

Stop everything at once:

cline connect --stop

For persistent availability, run the connector as a background process with a process manager. Using pm2 as an example:

pm2 start "cline connect telegram -m <BOT_USERNAME> -k <BOT_TOKEN>" --name cline-telegram
pm2 save
pm2 startup

This keeps the bridge running across reboots without leaving a terminal window open. We run our own Telegram connector this way on a Mac Mini that's always on; it's been stable across two macOS updates and a handful of CLI version bumps.

Connectors vs. headless CI: picking the right mode

Cline CLI also ships a headless mode built for CI pipelines. The -y flag gives the agent full autonomy, suppresses the interactive TUI, and streams everything to stdout:

cline -y "Run the full test suite and fix any TypeScript type errors"

That pattern fits a GitHub Actions step or a cron job where no human is in the loop. Output pipes cleanly to logs; the agent either finishes or exits with a non-zero code your CI catches.

Connectors are the opposite pattern: human-in-the-loop via chat, persistent session, mobile access. The right choice depends on the task:

• Use headless mode when the task is repeatable, the scope is bounded, and you want it to run unattended. A nightly type-check pass is a good example. No approval needed.
• Use connectors when the task is open-ended, involves file writes or deploys, or when a team member needs to delegate something while away from their machine. The chat approval step is the safety valve.

You can run both at the same time. A CI pipeline can call cline -y for automated checks while a Slack connector sits open for ad-hoc delegation.

For teams building more complex agent architectures, the Cline CLI docs link out to the SDK that powers the connector system which covers how sessions, tool execution, and the Agent Client Protocol (ACP) fit together. If you're also using MCP-connected tools to pipe external services into your agent, the patterns in Zapier MCP integrations for Cursor, Claude, and Windsurf apply directly. And if you're comparing Cline's connector approach against Claude Code extensions, the decision mostly comes down to where your team already communicates.

Pick the platform your team checks first. Get Telegram running in five minutes, graduate to Slack when you need the webhook mode for a shared channel. The connector model is practical enough that the setup time pays off after the second delegated task.