/agent-channeltalk

name: agent-channeltalk
description: Interact with Channel Talk using extracted desktop app or browser credentials - read chats, send messages, search messages, manage groups
version: 2.38.0
allowed-tools: Bash(agent-channeltalk:*)
metadata:
  openclaw:
    requires:
      bins:
        - agent-channeltalk
    install:
      - kind: node
        package: agent-messenger
        bins: [agent-channeltalk]

Agent Channel

A TypeScript CLI tool that enables AI agents and humans to interact with Channel Talk workspaces through a simple command interface. Features zero-config credential extraction from the Channel Talk desktop app (with browser fallback) and multi-workspace support.

Key Concepts

Before diving in, a few things about Channel Talk's terminology:

• **Channel** = workspace (not a chat channel like Slack). The API calls it a "channel," but it means your entire workspace.
• **UserChats** = 1:1 conversations with end users (customers).
• **Groups** = team inbox channels (similar to Slack channels). Referenced by ID.
• **DirectChats** = direct messages between managers.
• **Managers** = human agents on your team.
• **Bots** = automated agents in the workspace.
• **Messages** use a `blocks` format: `[{ type: "text", value: "..." }]`. The CLI handles this automatically when you pass plain text.

Quick Start

# Get workspace snapshot (credentials are extracted automatically)
agent-channeltalk snapshot --pretty

# Send a message to a group
agent-channeltalk message send group grp_abc123 "Hello from the CLI!"

# Send a message to a user chat
agent-channeltalk message send user-chat uc_abc123 "Thanks for reaching out!"

# List user chats
agent-channeltalk chat list

Authentication

Credentials are extracted automatically from the Channel Talk desktop app (or Chromium browser as fallback) on first use. No manual setup required, no API keys needed. Just run any command and authentication happens silently in the background.

The Channel Talk desktop app stores auth cookies in a SQLite database. On macOS, cookies are plaintext and no Keychain prompt is needed. On Windows, cookies are DPAPI-encrypted and decrypted automatically. When falling back to a Chromium browser on macOS, cookies require Keychain decryption. The CLI reads two cookies:

• `x-account` (JWT) - your account identity
• `ch-session-1` (JWT) - your session token

These cookies expire after roughly 30 days. When they expire, the CLI automatically re-extracts fresh cookies from the desktop app or browser on the next command.

**IMPORTANT**: Always use `agent-channeltalk auth extract` to obtain credentials. The CLI extracts from the desktop app first, falling back to Chromium browsers if the app isn't installed.

Multi-Workspace Support

If you're logged into multiple Channel Talk workspaces, all are discovered automatically. The first workspace is selected by default.

# List all available workspaces
agent-channeltalk auth list

# Switch to a different workspace
agent-channeltalk auth use <workspace-id>

# Check auth status
agent-channeltalk auth status

# Remove a stored workspace
agent-channeltalk auth remove <workspace-id>

Memory

The agent maintains a `~/.config/agent-messenger/MEMORY.md` file as persistent memory across sessions. This is agent-managed, the CLI does not read or write this file. Use the `Read` and `Write` tools to manage your memory file.

Reading Memory

At the **start of every task**, read `~/.config/agent-messenger/MEMORY.md` using the `Read` tool to load any previously discovered workspace IDs, group IDs, chat IDs, manager IDs, and preferences.

• If the file doesn't exist yet, that's fine. Proceed without it and create it when you first have useful information to store.
• If the file can't be read (permissions, missing directory), proceed without memory. Don't error out.

Writing Memory

After discovering useful information, update `~/.config/agent-messenger/MEMORY.md` using the `Write` tool. Write triggers include:

• After discovering workspace IDs and names (from `auth list`, `snapshot`, etc.)
• After discovering group IDs and names (from `group list`, `snapshot`, etc.)
• After discovering chat IDs (from `chat list`, etc.)
• After discovering manager IDs and names (from `manager list`, etc.)
• After discovering bot names (from `bot list`, etc.)
• After the user gives you an alias or preference ("call this the support workspace", "my main group is X")

When writing, include the **complete file content**. The `Write` tool overwrites the entire file.

What to Store

• Workspace IDs with names
• Group IDs with names
• UserChat IDs with context
• Manager IDs with names
• Bot IDs with names
• User-given aliases ("support workspace", "billing group")
• Any user preference expressed during interaction

What NOT to Store

Never store cookies, tokens, credentials, or any sensitive data. Never store full message content (just IDs and context). Never store personal user data.

Handling Stale Data

If a memorized ID returns an error (chat not found, group not found), remove it from `MEMORY.md`. Don't blindly trust memorized data. Verify when something seems off. Prefer re-listing over using a memorized ID that might be stale.

Format / Example

# Agent Messenger Memory

## Channel Talk Workspaces

- `abc123` - Acme Support

## Groups (Acme Support)

- `grp_111` - Support Inbox
- `grp_222` - Billing Inbox
- `grp_333` - Engineering

## Recent UserChats (Acme Support)

- `uc_aaa` - John Doe inquiry (opened)
- `uc_bbb` - Refund request (closed)

## Managers (Acme Support)

- `mgr_001` - Alice (Team Lead)
- `mgr_002` - Bob (Support Agent)

## Bots (Acme Support)

- `bot_001` - Support Bot
- `bot_002` - Notification Bot

## Aliases

- "support" -> `grp_111` (Support Inbox in Acme Support)

## Notes

- User prefers --pretty output for snapshots
- Main workspace is "Acme Support"

> Memory lets you skip repeated `group list` and `cha