The Messaging-Native Agent Moment

A session would be mid-task, I'd need to step away, and the only thing standing between Claude and finishing was a permission prompt. Allow Bash? Write to this file? The session would just sit there, frozen in the terminal, until I came back and hit y.

So I built a Telegram bot.

The tmux Notifier

The first version was a shell script. Claude Code has lifecycle hooks — SessionStart, PreToolUse, PermissionRequest, Stop, and four others. Each hook fires a script. I wired every hook to write state files to ~/.local/share/claude-notifier/, then had status.sh poll those files and render badges in the tmux status bar.

That solved visibility. I could see across all sessions at a glance: this one's working, that one's waiting, this one needs permission. But I still needed to be at the terminal to respond.

The next piece was the Telegram bot. When a PermissionRequest hook fires, the bot sends a notification to my phone — the tool name, what it's trying to do — with inline Approve and Deny buttons. I tap Approve. The bot runs a tmux send-keys y Enter to the right pane. Claude continues.

From wherever I happened to be.

It worked. It was also entirely held together with bash, Python, and tmux pane sends.

It was a proof of concept. What I actually wanted was a proper platform.

The Same Pattern, Everywhere

OpenClaw is a self-hosted personal AI assistant. You run it locally, connect your WhatsApp or Telegram or Slack, and talk to an AI through whatever app you already live in. No new interface. No app to install. The agent is reachable wherever you already are.

It has over 200,000 stars on GitHub.

That's not a coincidence. It's evidence that the interface is right. People don't want another app. They want their AI where they already are — in the thread they're already in, on the device already in their pocket, through the app they already keep notifications on for.

The tmux notifier was the same idea, narrower scope: I wanted Claude Code accessible from wherever I was, not just from the terminal it was running in.

Then Anthropic Shipped It

Claude Code v2.1.80 added channels. An MCP server with the claude/channel capability becomes a bridge into a running CC session — events push in, Claude reacts, tools relay back out. v2.1.81 added the permission relay: tool approval requests forward through the channel, you approve from wherever the channel delivers them, the session continues.

The four things my Telegram bot was doing with bash and tmux pane sends are now a first-class API.

# PermissionRequest hook fires this script.
# Telegram callback eventually returns "approve" or "deny".

PANE=$(detect_pane_for_session "$CLAUDE_SESSION_ID")
if [ -z "$PANE" ]; then
log_error "no pane mapped for session"
exit 1
fi

# Strip ANSI from current pane buffer so we can parse the prompt.
BUFFER=$(tmux capture-pane -p -t "$PANE" | sed 's/\x1b\[[0-9;]*m//g')
OPTION=$(echo "$BUFFER" | grep -oE '^[0-9]+\.' | head -1 | tr -d '.')

case "$VERDICT" in
approve) tmux send-keys -t "$PANE" "${OPTION:-y}" Enter ;;
deny)    tmux send-keys -t "$PANE" "n" Enter ;;
esac

rm -f "$STATE_DIR/pending-$REQUEST_ID"

The gap between "hacky proof of concept" and "supported protocol" closed in the time it took me to build the proper version.

AgentHive

I'd started AgentHive before channels shipped. The premise was that the tmux notifier pattern needed a real platform underneath it: proper rooms, a real-time feed, a permission system with actual state management, something that could scale beyond one person's terminal setup.

The CC Channels integration in AgentHive replaced the tmux pane send path with the native relay. Instead of tmux send-keys y Enter, the approval verdict goes through notifications/claude/channel/permission. Instead of polling state files, the room feed updates via WebSocket as events come in. The plumbing is cleaner. The result is the same: I can approve tool calls from my phone, see what Claude is working on in real time, send it messages mid-task.

What's different is the surface. AgentHive isn't a messaging bot — it's a web UI. Rooms, feeds, approval cards, sidebar with session status. A control plane rather than a chat thread. That's a deliberate choice: for complex sessions with many tool calls, a structured feed is easier to follow than a message thread. But the underlying need is identical to what OpenClaw is solving at the personal assistant level.

The Pattern

What's converging:

• AI agents need a control interface that isn't the terminal they're running in
• The best available interface is usually messaging — you already have it, you already watch it
• Anthropic recognized this and built it into the protocol
• The open source community recognized it and built it into a product with 200k stars

The difference is scope. OpenClaw is a personal assistant: one human, their apps, their machine, general-purpose tasks. Claude Code Channels is for developer tooling: coding agents, permission-gated tool calls, technical workflows. AgentHive is somewhere in between: a control plane for any agent, with a web UI instead of a chat thread.

All three are solving the same problem. The terminal is not the right home for an AI agent's interface. Wherever the human actually is — that's where it needs to be.

AgentHive is currently personal-use only while I validate use cases. The tmux-claude-code-notifier is open source if you want to wire up your own Telegram bridge today.

Related: Building AgentHive — what the proper platform looks like. Claude Code Channels — how the API that powers the bridge actually works.