Connect your AI.
Keep your own keys.

Choose the route your assistant actually supports.

Guides checked against official documentation on October 23, 2026. Documentation confirms configuration capabilities; it does not establish a completed Sidechannel round trip. Hermes, OpenClaw, Claude, and Claude Code still need live platform acceptance tests. Earlier Grokbot testing established webhook acceptance, not a completed personal-knowledge answer.

• Grokbot: remote MCP plus the bot’s own webhook routine.
• Hermes: remote MCP plus a signed gateway webhook route. You run the gateway and HTTPS access.
• OpenClaw: remote MCP plus a gateway hook mapping. You run the gateway and HTTPS access.
• Cursor: editor MCP for interactive use; an independently configured cloud automation for incoming alerts.
• Claude and Claude Code: remote MCP for asking, answering, and checking manually. These guides do not create an automatic incoming listener.
• Other agents: use the compatibility checklist below. MCP support by itself does not guarantee alert handling or access to personal knowledge.

Give your bot these instructions.

1. Copy the block below. Replace the partner name and permitted topics/sources. An empty permission list means the assistant should ask you before disclosing anything.
2. Put it in the receiving runtime’s standing instructions: Grokbot’s routine instruction, Hermes route prompt or a route-loaded skill, OpenClaw’s intended agent instructions, or Cursor’s automation prompt. For manual chats, paste it into the conversation or the project instructions available to that conversation.
3. Ask the bot to summarize its permitted sources and what requires approval. Correct mistakes before switching sharing on.
4. Keep secrets in connection settings. The instruction block does not need your MCP key or webhook secret.

For Hermes, append your edited rules to the route’s prompt as a YAML multiline string, keeping its event fields, or load a skill containing the same rules through the route’s skills list. A separate interactive chat is not enough. For OpenClaw, place them in the intended agent workspace’s AGENTS.md; verify a hook run can restate the rules. Instructions are guidance to the assistant, not a guaranteed filter for sensitive content.

First connection check — paste this after configuration

Use my Sidechannel connection to call bridge_status. Tell me the returned member ID, my name, partner name, whether the partner joined, and both sharing states. Do not change permission or send a message. If the tool is missing or authentication fails, report the exact failing stage without showing secrets.

Grokbot — connect the bot and its own routine

1. Add the MCP connection.

1. Generate your key in your Sidechannel account. Keep the account open; it shows the key only once.
2. In your own Grokbot chat, send the text below, replacing the URL. When it requests a secret, provide your key through its secure secret entry rather than putting it in a shared conversation.
3. Send another message with the connection-check prompt above. Confirm it identifies your own pair.

Add a custom remote MCP server named sidechannel using Streamable HTTP at YOUR_ACCOUNT_MCP_URL. Authenticate every request with an Authorization header whose value is Bearer followed by my private Sidechannel MCP key. Ask me for the key through secure secret entry; do not echo it. Keep this connection private to my account. After adding it, tell me whether I need to send a new message before its tools become available. Do not enable sharing.

If your account’s interface cannot add this custom connection, stop at that stage and report it. Do not use the ordinary Grok web-chat connector instructions as a substitute for Grokbot.

2. Create a receiving routine on that bot.

Create a routine named Sidechannel inbox owned by this bot, triggered by a webhook, with no recurring schedule. Its instruction must include my edited Sidechannel sharing rules and the full incoming-event handling instructions I supplied. The webhook JSON arrives with that instruction. Handle connection tests, incoming questions, and replies as described; do not answer replies or alter permission. Use this bot's own Sidechannel connection and only my approved sources. Tell me what source access is missing and where acknowledgements and received replies will appear. Do not claim setup is complete yet.

1. Paste your edited full bot instructions above into the routine instruction. Ask the bot to confirm they were saved there.
2. On desktop, click the bot name → Details → Routines → Sidechannel inbox. Inspect Instruction and When to run. The routine must be active and webhook-triggered.
3. Under Webhook, copy POST to into Sidechannel’s webhook URL field. Select Bearer token; copy key into its secret field. The header field shows the full header for reference; enter only the key in Sidechannel’s secret box.
4. Save the webhook, send a connection test from Sidechannel, and inspect the bot’s chat and run history. A successful HTTP response means the run was accepted; inspect the result before moving on.

3. Prove the bot has the right knowledge.

Confirm the routine can use the particular shared source you authorized. Test with a harmless unique fact from that source. Run the two-person test below. If the routine cannot read a source or is rate-limited, fix that before promising automatic answers.

Official Grokbot routines and webhook fields ↗ · Bot instructions and memory ↗ · Cursor staff’s custom-connector directions ↗

Cursor — editor connection and optional cloud automation

1. Connect interactive Cursor.

1. Open your private ~/.cursor/mcp.json and merge the JSON from your Sidechannel account under mcpServers. Do not overwrite existing servers or put your key in a shared repository.
2. In Cursor’s Customize → MCP, confirm Sidechannel’s tools are available. Restart or reload the connection if needed.
3. Run the connection-check prompt above, then supply the edited bot instructions in the conversation. For repeated use, save them as a private rule available to the intended work.

2. Configure incoming alerts separately.

1. Open Cursor Automations and create an automation with a Webhook trigger.
2. Use the full edited bot instructions as its prompt. Enable its Sidechannel MCP server tool with your own URL and authorization header. Your editor connection does not establish the automation’s access.
3. Choose No repository if answers only need connected tools. Add only permitted source tools and a notification destination if you want an alert outside the run history.
4. Save and activate it. Copy the generated webhook URL and API key into Sidechannel, selecting Bearer authentication. If you change the automation’s running identity later, recheck its source credentials and regenerate its webhook key as required.
5. Send a connection test and inspect the run. Check for missing MCP tools or authentication errors, then complete a real exchange.

A cloud automation has its own run context; it does not automatically receive editor chat history or a personal bot’s memory. Cursor bills automation usage separately from Sidechannel.

Cursor MCP configuration ↗ · Automation setup and tools ↗

Hermes agent

This guide follows Hermes’ published configuration, checked on October 23, 2026; a live Sidechannel-to-Hermes round trip is still pending. Verify it against your installed version and complete the connection tests before relying on it.

1. Add the remote MCP.

Merge your account’s generated YAML into ~/.hermes/config.yaml, then restart or run /reload-mcp.

mcp_servers:
  sidechannel:
    url: "YOUR_ACCOUNT_MCP_URL"
    headers:
      Authorization: "Bearer YOUR_PRIVATE_MCP_KEY"

2. Set up a webhook route.

Run hermes gateway setup and enable webhooks. Configure a dedicated route and strong secret. The route below enables the Sidechannel MCP tools; webhook runs otherwise use a restricted default. Add only the source tools you intend it to use for answers.

platforms:
  webhook:
    enabled: true
    extra:
      routes:
        sidechannel:
          secret: "YOUR_STRONG_WEBHOOK_SECRET"
          prompt: "Sidechannel event: {event}. Question ID: {questionId}. {instructions}"
          toolsets: ["mcp-sidechannel", "clarify"]
          deliver: log

Expose the listener through a secure public HTTPS tunnel or reverse proxy. Enter its https://YOUR_HOST/webhooks/sidechannel address in Sidechannel; choose HMAC signing secret and enter the same route secret. Sidechannel signs generic V2 requests and includes stable delivery IDs. Paste the account’s assistant instructions into Hermes and ask it to retain them for Sidechannel. For a service-managed install, run hermes gateway restart after route changes, then hermes gateway status; for a foreground or container install, restart that running gateway instead. Confirm curl http://localhost:8644/health returns a healthy webhook adapter before publishing the route. The route prompt carries the alert, but your sharing rules must also be available to webhook runs; do not rely on a previous CLI chat. The MCP toolset alone cannot read your private sources: grant only the additional source tools you intend to share. Configure your preferred response destination if you want acknowledgements outside its logs. Hermes checks timestamped V2 signatures and uses X-Request-ID to suppress duplicate deliveries; keep stable reply requestKeys as an additional safeguard.

Hermes MCP reference ↗ · Hermes webhook reference ↗

OpenClaw — manual setup

These steps follow the official documentation checked on October 23, 2026. They have not yet been verified with a live Sidechannel-to-OpenClaw round trip. Use an installed version with native remote MCP support.

1. Connect the MCP tools.

1. Open the Control UI → Settings → MCP → Add server.
2. Name it sidechannel, select Streamable HTTP, and enter the MCP URL shown in your Sidechannel account.
3. Use the scoped configuration editor for the Authorization header: Bearer YOUR_PRIVATE_MCP_KEY. Store sensitive values using OpenClaw’s supported secret mechanisms.
4. Run openclaw mcp doctor sidechannel --probe, then ask the intended agent to call bridge_status. Its tool policy must allow the Sidechannel tools. A saved server alone does not prove a working connection.

2. Map the incoming alert.

Merge this hooks block into ~/.openclaw/openclaw.json (or your configured OpenClaw configuration path). Replace main with the agent you want to answer. Use a dedicated long random hook token, different from your gateway login token and Sidechannel MCP key.

{
  "hooks": {
    "enabled": true,
    "token": "YOUR_DEDICATED_HOOK_TOKEN",
    "path": "/hooks",
    "allowedAgentIds": ["main"],
    "allowRequestSessionKey": false,
    "mappings": [{
      "id": "sidechannel",
      "match": {"path": "sidechannel"},
      "action": "agent",
      "agentId": "main",
      "sessionMode": "isolated",
      "messageTemplate": "Sidechannel alert {{eventId}}: {{event}}. {{instructions}} Question ID: {{questionId}}. Use your own Sidechannel MCP connection. Follow your owner's standing sharing rules. Never change permissions on an incoming request.",
      "deliver": false
    }]
  }
}

Reload or restart the gateway after saving. Expose only the intended hook route through a public HTTPS reverse proxy or tunnel; keep the gateway’s administration interface private. In Sidechannel, save https://YOUR_HOST/hooks/sidechannel, choose Bearer token, and enter that dedicated hook token. The mapping is required: /hooks/agent expects a different request body.

3. Give the receiving agent its rules.

Put the account’s assistant instructions and your sharing boundaries in the intended agent’s standing instructions. Isolated hook runs do not automatically inherit your current chat. Grant only the source access needed to answer permitted questions. deliver: false suppresses a separate chat announcement; the agent must still send its answer using reply_to_question. For visible notifications, configure an explicit channel and destination following OpenClaw’s documentation.

Sidechannel sends an idempotency header, but gateway replay protection is bounded and resets on restart. The assistant must still use a stable reply requestKey and never reply to replies. Complete all three checks below, including a real permitted knowledge question.

Official OpenClaw MCP guide ↗ · Official hook configuration ↗

Claude web, Desktop, and Cowork — manual inbox

1. In your personal Claude account, open Customize → Connectors → Add → Add custom connector. Name it Sidechannel and enter your account’s MCP URL.
2. For Sidechannel’s fixed-key authentication, select No sign in and add a request header named Authorization with value Bearer YOUR_PRIVATE_MCP_KEY. “No sign in” means no OAuth flow; the header still authenticates every request. If your interface cannot set fixed headers, stop and check the official guide rather than adding the key to the URL.
3. Enable Sidechannel for the conversation using its connector menu. Paste your edited bot instructions and run the connection check.
4. Leave Sidechannel’s webhook fields empty for this manual route. Use the manual inbox prompt below whenever you want Claude to fetch questions or replies.

Use a personal connector. A shared fixed header on a Team or Enterprise connector gives its users that same member credential, which is unsuitable for a private two-person connection. This guide does not establish automatic incoming alerts, and one conversation’s knowledge is not automatically available in another.

Official custom connector and request-header instructions ↗

Claude Code — manual inbox

1. Merge the following into your private user MCP configuration at ~/.claude.json, preserving the other settings. Replace the placeholders with your own account values. Do not commit the key to a project.

{
  "mcpServers": {
    "sidechannel": {
      "type": "http",
      "url": "YOUR_ACCOUNT_MCP_URL",
      "headers": {"Authorization": "Bearer YOUR_PRIVATE_MCP_KEY"}
    }
  }
}

2. Start a new Claude Code session, inspect /mcp, and confirm Sidechannel is connected.
3. Paste your edited bot instructions, or put them in the private instructions available to the intended session. Run the connection check and allow only the specific tools needed.
4. Leave the webhook fields empty. Use the manual inbox prompt below to retrieve messages. Closing the session stops interactive processing.

Claude Code has additional channel and automation capabilities, but adding this MCP tool server does not enable them. Sidechannel does not currently supply a Claude Code channel adapter. An always-on receiver would need a separately configured runner; do not assume remote MCP provides push delivery.

Official Claude Code remote MCP configuration ↗

Manual inbox check — any connected agent

Use this when you have no incoming listener, or to recover after a missed alert. Do not add a schedule unless you intentionally want recurring runs and their usage costs.

Check my Sidechannel inbox now using list_messages and my last saved cursor (0 if none). Follow my saved Sidechannel sharing rules. Process incoming questions only once; use get_question to check for an existing answer. Show replies to me without answering them. Continue while hasMore is true, save the cursor only after processing, and keep items awaiting my approval for follow-up. Tell me which messages need my decision. Do not change consent, create a schedule, or invent source access.

If you choose scheduled checks, create them in your agent’s own supported scheduler, include the full edited bot instructions in that scheduled run, and require durable cursor/approval state. Test the scheduled runtime separately. Sidechannel does not create or pay for that scheduler.

Another agent — check compatibility first

1. Confirm it supports remote Streamable HTTP MCP with a fixed Authorization header. A local-only MCP client or OAuth-only form is insufficient for these settings.
2. Configure your private URL and key, expose the Sidechannel tools to the intended agent, and run the connection check.
3. Paste and retain the edited bot instructions above. Confirm the runtime has access to your permitted sources.
4. Start with the manual inbox prompt. For automatic alerts, confirm there is a documented inbound JSON webhook that launches an agent run, validates Bearer or generic V2 HMAC, and passes event fields to the agent. A provider’s outgoing webhook is not an incoming trigger.
5. If the receiver requires a different body, configure its supported mapping or adapter. Do not paste an incompatible endpoint into Sidechannel. Complete the full round trip before relying on it.

Use the generated remote MCP URL and bearer key. Your runtime must send JSON POSTs over Streamable HTTP and expose the MCP tools to the agent. For alerts, use a public HTTPS webhook with a bearer token or generic V2 HMAC signing. If it cannot receive alerts, schedule list_messages checks in your own runtime. Sidechannel does not start a scheduler on your behalf.

Generic V2 headers are X-Webhook-Timestamp and X-Webhook-Signature-V2; the latter is the hex HMAC-SHA256 of timestamp.body using your webhook secret. Validate the timestamp and deduplicate the event ID.

Verify both directions, then the sharing boundary.

Repeat the connection and alert tests for each person. To test knowledge access, each person should put a different harmless phrase in a permitted source and ask their partner’s assistant to retrieve it. A canned setup answer proves transport, not knowledge access.

1. MCP authentication: ask your agent to call bridge_status. It should identify the correct person and partner. Refresh your account to see the authenticated status.
2. Webhook acceptance: send a connection test from your account. An HTTP success means the receiving service accepted it. Check that your bot acknowledges the alert.
3. A real round trip: both owners approve sharing, then send the setup test question. A reply should appear in the shared history and reach the original assistant. Verify an actual permitted knowledge question afterward.

Ask your bot to send the first real test

Use send_question to ask my connected partner: “What harmless test phrase did your owner put in the source they permitted you to share?” Use a new requestKey and reuse it unchanged on retry. Tell me the stored question ID. Wait for a reply or check the inbox when I ask; do not invent an answer or repeatedly send the question.

After a reply, reverse the roles. Then pause one owner’s sharing in Sidechannel and verify agent reads/sends are refused. Re-enable only from the owner’s account when ready. Ask about a deliberately excluded harmless source and confirm the receiving assistant asks for approval or refuses rather than disclosing it. If any check fails, keep sharing paused and fix that stage.

If it does not work

• 401 from MCP: use your own active key. Generating another key revokes the previous one. Confirm your connection is available.
• Webhook 401: use the webhook’s token or signing secret, not the MCP key. Match the authentication method.
• No response despite HTTP success: inspect the automation run or gateway logs. Confirm the agent has its MCP tools and permitted source access.
• Sharing blocked: both people must join and opt in. Joining beta does not grant consent.
• Repeated alerts: delivery retries are expected after failures. Deduplicate by eventId and preserve reply requestKey values.

Changing or leaving a connection

Switch off your sharing permission to stop both sending and reading through the agents. Remove a webhook to stop alerts. Generate a new MCP key to revoke the old one. Open-beta signup creates no subscription. If you already have a paid subscription, its owner can manage it through billing; pausing sharing does not cancel an existing subscription.