You kicked off a long build, closed the laptop, and walked to lunch. Twenty minutes later the deploy either shipped or died, and you have no idea which until you sit back down. Or worse: the agent finished, decided the prod migration looked fine, and ran it while you were gone.
Both of those are the same missing wire. Your coding agent has no way to reach you where you actually are, which is your phone. Connecting Claude Code to WhatsApp fixes that. Your agent gets a "send a WhatsApp message" capability (and a "read the reply" one), so it can ping your own number when work finishes and hold before an irreversible step until you answer.
What connecting Claude Code to WhatsApp actually does, and what it doesn't
Connecting Claude Code to WhatsApp gives your coding agent a send-and-read tool for messaging your own WhatsApp number. It is not a customer support chatbot and not the Meta Cloud API. The agent messages you (or your team) over the number you already own, so it can report results and wait for your decisions.
Here is the shape of it, mapped plainly:
- What it is - a WhatsApp send + read capability your agent invokes, like any other tool.
- What it runs on - your own number, linked over WhatsApp Web or a hosted 24/7 gateway.
- What it is not - a pre-trained support bot, a marketing-broadcast machine, or the Cloud API with its templates and per-message billing.
- Who it messages - you, your teammates, the people you already talk to. Not a cold list.
If you want the broader "put any AI agent on WhatsApp to read and triage your inbox" version, that is a different job, covered in giving your AI agent WhatsApp. This piece is narrower and more useful for developers: the coding-agent workflow, in the terminal and in CI.
Why route Claude Code notifications to WhatsApp instead of email or Slack
Because you already live in WhatsApp. Long builds, deploys, test suites, and headless agent runs finish while you are away from the terminal. A WhatsApp ping reaches you in seconds on a channel you already check, where an email waits until tomorrow and a Slack channel you muted last week never surfaces at all. Your terminal reaches your pocket.
Line up the options a coding agent usually has:
| Channel | Where you see it | Reply speed |
|---|---|---|
| Batch-read, hours later | Slow | |
| Slack / Teams | At a desk, often muted | Medium |
| A custom dashboard | Only when you remember to open it | You forget |
| Already open, already pushing | Seconds |
That is the whole case for coding agent WhatsApp notifications: the build result lands on the one screen you will actually look at before you look at anything else. One operator who ships alone put it this way: "I stopped babysitting the terminal for the last 10% of a deploy. The phone buzzes, I glance, I keep walking." The point is not novelty. It is closing the loop faster than any other channel closes it.
How to add the Blueticks MCP connector to Claude Code (and Cursor)
You add it one of two ways, both no-code. Point your client at the hosted remote connector at https://api.blueticks.co/mcp and approve access with a login, or run the MCP server with a bt_live_ key for key-based auth. Both reach the same WhatsApp tools. For Claude Code that means one claude mcp add command or a project .mcp.json entry; Cursor takes the same server in its own MCP config.
The steps, at the tool-surface level:
- Link your WhatsApp number to Blueticks so an engine is live. This is the part that actually holds your WhatsApp session.
- Add the connector. In Claude Code, register the remote connector by URL, or drop the server into a project
.mcp.jsonso it travels with the repo. Cursor has an equivalent MCP config screen. - Authenticate. The remote connector uses a login (OAuth); the server path takes your
bt_live_key. Either reaches the same tools. - Verify. Ask the agent to list your recent WhatsApp chats. If it answers using the tools, you are wired.
I am not going to rebuild the full connector walkthrough here, because it already exists and it drifts as clients update. The exact click path lives in the Claude WhatsApp MCP integration guide, and the canonical claude mcp add mechanics live in Anthropic's Claude Code MCP docs. MCP itself is the open standard Anthropic published in late 2024 for connecting assistants to external tools, which is why the same connector works in Claude Code, Cursor, and any other MCP client without a rewrite. The thing worth stressing: there is no second Node runtime or WhatsApp Web client for you to keep alive. The hosted engine removes that whole tier.
How to make Claude Code ping you when a build or deploy finishes
You instruct the agent to call the WhatsApp send tool at the end of a long task. A rule in your CLAUDE.md, a Stop hook that fires when the agent finishes, or a step in a slash command all work. The instruction is plain: "when the deploy step completes, send me a WhatsApp with the result." No code, just a tool the agent already has.
Here is the exact sequence for a deploy notification:
- Add the send tool by connecting the MCP connector (previous section).
- Write the rule in
CLAUDE.md: "After the deploy step, send a WhatsApp to my number with the branch, the environment, and pass/fail." - Let the task run. Build, test, deploy, whatever the job is.
- Get the ping. "Build green on
release/2.4, deployed to staging" lands on your phone. The message body stays short and outcome-focused; the agent references the result, not a wall of log output.
This is the coding-agent surface of a generic pattern. If you want the standalone version that any agent or cron job can use to notify you, do not rebuild it from here: the human-in-the-loop WhatsApp approvals guide owns the notify-and-approve mechanics end to end. Watch one gotcha even on the pure-notify path: treat "I called the send tool" as "I attempted a send," not "you saw it." If the engine was down when the agent fired, the ping never arrived, and the agent has no idea. For anything you truly must not miss, have it confirm the message reached a delivered state before it moves on.
Stop babysitting the last 10% of every deploy. Connect Claude Code to WhatsApp on the number you already own and let your agent ping build, deploy, and CI results straight to your phone, then wait for your yes before it does anything irreversible. No Meta Business verification, no message templates, no per-message fees, no self-hosted WhatsApp Web client to supervise.
How to make Claude Code ask for approval before it acts
You structure the task as ask-then-check instead of fire-and-forget. Before an irreversible step (a prod deploy, a database migration, a force-push, an rm), the agent sends a WhatsApp asking permission, then reads your reply through the MCP read tool and gates the action on it. The coding agent is the right place for this gate because it is the thing about to act.
The loop, using a production migration as the example:
- The agent reaches the gate. It has the migration ready but is configured to treat migrations as approval-required.
- It sends the ask. "About to run the prod migration on
orders. Reply YES to proceed or NO to hold." - It waits. The migration does not run. The agent's next step is "read the reply," not "execute."
- You reply. From your phone, "yes" or "no," in seconds.
- It acts or aborts. On yes it runs and confirms. On no, or on silence past a timeout you set, it holds and logs that it held.
The mechanics of that wait (how to poll, why silence must never map to yes, how to parse a fuzzy reply) are the same across every agent, so I will point rather than repeat: the human-in-the-loop approvals guide is the mandatory read for the pattern. The delta this article adds is the context: it is Claude Code, in your terminal or your pipeline, gating a command it was about to run itself. That is a real stop-and-wait before an irreversible step, on the device in your hand.
Can you wire this into CI, not just the local terminal
Yes. The same capability works from a pipeline. A CI step or a headless agent run posts the result to WhatsApp when a job finishes, and a manual-approval gate can wait on your reply before promoting to production. It is the same MCP connector or the same authenticated POST to the /v1 REST API, invoked from GitHub Actions or your deploy script instead of your laptop.
Two shapes cover almost everything:
- CI notification. A workflow step calls the send tool (or the
/v1API) at the end of the run: "CI passed onmain, artifact published." The recipient sits in the URL path, not the body, and any language that can make an HTTP request can fire it. - Manual-approval gate. A promote-to-prod job messages you, then blocks on your reply before it continues. Your pipeline enforces the pause; WhatsApp just carries the ask and the answer.
One number to plan around so a chatty pipeline does not surprise you: the free plan allows 5 requests per 6-hour window, shared across the REST API and MCP surfaces. Any active subscription lifts it. That is a guardrail, not a throttle a normal build cadence hits, but a CI job that pings on every push can burn through it, so gate the notification to the events that matter. If you want the full request-and-response walkthrough for the REST path, that belongs in the developer guide for giving an agent a send-and-read tool, not here. The point for this piece is that whatsapp mcp claude code setups and CI both reach the same hosted endpoint, with nothing for you to host.
Is this safe? Bans, consent, and what Blueticks is (and isn't)
It is low-risk by nature, but nobody honest promises a no-ban guarantee. You are messaging your own number and your own team, not cold-blasting strangers, which is about as safe as WhatsApp automation gets. You still send under WhatsApp's Business Messaging Policy whatever software is behind the send, and consent to message anyone else is yours to collect.
The boundaries, stated plainly so nobody feels misled later:
- It is your own number, not the Cloud API. The link is your existing WhatsApp over WhatsApp Web or a managed gateway, not a Meta-provisioned Cloud API number. No templates, no Business verification, no per-message billing. Meta deprecated conversation-based pricing on 1 July 2025 and now bills the Cloud API per message; the own-number path has none of that.
- The generally available surfaces are two. The
/v1REST API and the hosted MCP connector. The self-serve, trainable in-app support bot is not generally available, so do not plan around it. - It is not the first WhatsApp MCP. Open-source servers got here first. The
lharries/whatsapp-mcpproject and entries in the official MCP servers registry predate the hosted version and are a fine starting point if you want to run the plumbing yourself. The honest claim is first hosted, no-code, product-grade one, not first ever. - No guaranteed no-ban. A self-notification loop where your agent messages you is genuinely low-risk. The risk climbs the moment the same capability points at unsolicited outbound to people who never asked to hear from you.
Every platform fact above links its primary source on purpose. When you evaluate any tool in this space, hold it to the same bar: a Meta claim should link Meta, an MCP claim should link the protocol spec, and a Claude Code claim should link Anthropic's docs. A vendor sourcing a WhatsApp-pricing claim to its own blog post is a yellow flag.
When to use Claude Code + WhatsApp vs a full chatbot or the Cloud API
Use the own-number MCP or /v1 path when you are a developer or agent-operator who wants your tools to reach you on a number you already use: build, deploy, and CI notifications and approvals, with nothing to self-host. Reach for the Meta Cloud API plus a Business Solution Provider instead when you need approved marketing templates at broadcast scale or an Official Business Account badge.
Pick by the job:
- Notify yourself and gate your own agent's actions. Own-number, hosted MCP or
/v1. This article. No Meta approval, no templates, no per-message fees. - Blast approved templates to thousands of strangers from a brand number. Cloud API plus a BSP. Different product, different pricing model, not a substitute for the above and vice versa.
Here is the product bridge, and it is the honest reason the hosted route exists. The maintained open-source WhatsApp Web clients are Node projects. Self-hosting one means supervising a browser profile, reconnect logic, and session drops forever, on top of the actual work you wanted to do. A hosted /v1 plus MCP endpoint removes that entire tier: you connect a number once, add the connector, and your coding agent can reach your phone from the terminal and from CI without you ever running a WhatsApp session yourself.
FAQ
Can Claude Code send me a WhatsApp when my build or deploy finishes?
Yes. Connect the Blueticks MCP connector (or the /v1 API) to Claude Code, then instruct the agent with a CLAUDE.md rule, a Stop hook, or a slash-command step to call the send tool when the task ends. The result lands on your own WhatsApp number, on the phone in your hand, in seconds.
Do I need the Meta Cloud API to connect Claude Code to WhatsApp?
No. This runs on your own WhatsApp number, linked over WhatsApp Web or a managed 24/7 gateway. Meta's Cloud API is a separate provisioned number with template approval, Business verification, and per-message billing since 1 July 2025. The own-number path has none of those, which is why a quick self-notification carries no template overhead.
How does Claude Code wait for my WhatsApp approval before deploying?
You structure the task as ask-then-check. The agent sends a WhatsApp asking to proceed, then reads your reply through the MCP read tool before the gated step runs. Silence must map to "hold," never to "assume yes." The generic pattern, including timeouts and reply parsing, is covered in the human-in-the-loop approvals guide.
Does this work from Cursor and other MCP clients too?
Yes. Because MCP is an open standard, the same connector works in Cursor and any other MCP-compatible client, not just Claude Code. You add the same server in each client's own config location. Cursor, in particular, uses the identical hosted connector or bt_live_ key setup.
Can I trigger the WhatsApp notification from GitHub Actions or CI, not just my terminal?
Yes. A CI step calls the send tool or the /v1 REST API to post the pipeline result, and a manual-approval gate can block on your reply before promoting to prod. Note the free plan's 5 requests per 6-hour window, shared across REST and MCP, so gate the ping to events that matter; any active subscription lifts the ceiling.
Will sending WhatsApp messages from Claude Code get my number banned?
Nobody can guarantee it will not. That said, a coding agent messaging your own number and team is about as low-risk as WhatsApp automation gets. You send under WhatsApp's Business Messaging Policy whatever triggered the send, and consent to message anyone beyond yourself is your responsibility.
