mirror of
https://github.com/openclaw/openclaw.git
synced 2026-05-06 10:40:43 +00:00
docs(channels): cover WhatsApp replyToMode, Discord inheritParent, Slack HTTP/ACP/downloadFile, Telegram webhook+picker auth, Mattermost reasoning suppression, workspace .env block for channel endpoints
This commit is contained in:
@@ -655,6 +655,10 @@ Default slash command settings:
|
||||
- Discord threads are routed as channel sessions
|
||||
- parent thread metadata can be used for parent-session linkage
|
||||
- thread config inherits parent channel config unless a thread-specific entry exists
|
||||
- parent transcript inheritance into newly created auto-threads is opt-in via `channels.discord.thread.inheritParent` (default `false`). When `false`, newly created Discord thread sessions start isolated from the parent channel transcript; when `true`, the parent channel history seeds the new thread session
|
||||
- per-account overrides live under `channels.discord.accounts.<id>.thread.inheritParent`
|
||||
- message-tool reactions can resolve `user:<id>` DM targets in addition to channel targets
|
||||
- `channels.discord.guilds.<guild>.channels.<channel>.requireMention: false` is preserved during reply-stage activation fallback, so configured always-on channels stay always-on even when reply-stage fallback runs
|
||||
|
||||
Channel topics are injected as **untrusted** context (not as system prompt).
|
||||
Reply and quoted-message context currently stays as received.
|
||||
|
||||
@@ -267,6 +267,7 @@ Notes:
|
||||
- `progress` shows a status preview while generating and only posts the final answer at completion.
|
||||
- `off` disables preview streaming.
|
||||
- If the stream cannot be finalized in place (for example the post was deleted mid-stream), OpenClaw falls back to sending a fresh final post so the reply is never lost.
|
||||
- Reasoning-only payloads are suppressed from channel posts, including text that arrives as a `> Reasoning:` blockquote. Set `/reasoning on` to see thinking in other surfaces; the Mattermost final post keeps the answer only.
|
||||
- See [Streaming](/concepts/streaming#preview-streaming-modes) for the channel-mapping matrix.
|
||||
|
||||
## Reactions (message tool)
|
||||
|
||||
@@ -710,6 +710,8 @@ Manual reply tags are supported:
|
||||
|
||||
Note: `replyToMode="off"` disables **all** reply threading in Slack, including explicit `[[reply_to_*]]` tags. This differs from Telegram, where explicit tags are still honored in `"off"` mode. The difference reflects the platform threading models: Slack threads hide messages from the channel, while Telegram replies remain visible in the main chat flow.
|
||||
|
||||
Focused Slack thread replies route through their bound ACP session when one exists, instead of preparing the reply against the default agent shell. That keeps `/focus` and `/acp spawn ... --bind here` bindings intact for follow-up messages in the thread.
|
||||
|
||||
## Ack reactions
|
||||
|
||||
`ackReaction` sends an acknowledgement emoji while OpenClaw is processing an inbound message.
|
||||
@@ -744,6 +746,7 @@ Notes:
|
||||
- Media and non-text payloads fall back to normal delivery.
|
||||
- Media/error finals cancel pending preview edits without flushing a temporary draft; eligible text/block finals flush only when they can edit the preview in place.
|
||||
- If streaming fails mid-reply, OpenClaw falls back to normal delivery for remaining payloads.
|
||||
- Slack Connect channels that reject a stream before the SDK flushes its local buffer fall back to normal Slack replies, so short replies are not silently dropped or reported as delivered before Slack acknowledges them.
|
||||
|
||||
Use draft preview instead of Slack native text streaming:
|
||||
|
||||
@@ -1032,6 +1035,12 @@ openclaw pairing list slack
|
||||
snapshots, the HTTP account is configured but the current runtime could not
|
||||
resolve the SecretRef-backed signing secret.
|
||||
|
||||
Registered Request URL webhooks are dispatched through the same shared handler registry used by Slack monitor setup, so HTTP-mode Slack events keep routing through the registered path instead of 404ing after successful route registration.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="File downloads with custom bot tokens">
|
||||
The `downloadFile` helper resolves its bot token from the runtime config when a caller passes `cfg` without an explicit `token` or prebuilt client, preserving cfg-only file downloads outside the action runtime path.
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Native/slash commands not firing">
|
||||
|
||||
@@ -745,6 +745,10 @@ curl "https://api.telegram.org/bot<bot_token>/getUpdates"
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Model picker authorization in groups">
|
||||
Group model-picker inline buttons require the same authorization as `/models`. Unauthorized participants can browse and tap buttons, but OpenClaw rejects the callback before changing the session model.
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Long polling vs webhook">
|
||||
Default: long polling.
|
||||
|
||||
@@ -761,6 +765,8 @@ curl "https://api.telegram.org/bot<bot_token>/getUpdates"
|
||||
If your public endpoint differs, place a reverse proxy in front and point `webhookUrl` at the public URL.
|
||||
Set `webhookHost` (for example `0.0.0.0`) when you intentionally need external ingress.
|
||||
|
||||
The grammY webhook callback returns a 200 within 5 seconds so Telegram does not retry long-running updates as read timeouts; longer work continues in the background. Polling rebuilds the HTTP transport after `getUpdates` 409 conflicts, so retries use a fresh TCP connection instead of looping on a Telegram-terminated keep-alive socket.
|
||||
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Limits, retry, and CLI targets">
|
||||
|
||||
@@ -331,6 +331,28 @@ When the linked self number is also present in `allowFrom`, WhatsApp self-chat s
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
## Reply quoting
|
||||
|
||||
WhatsApp supports native reply quoting, where outbound replies visibly quote the inbound message. Control it with `channels.whatsapp.replyToMode`.
|
||||
|
||||
| Value | Behavior |
|
||||
| -------- | ---------------------------------------------------------------------------------- |
|
||||
| `"auto"` | Quote the inbound message when the provider supports it; skip quoting otherwise |
|
||||
| `"on"` | Always quote the inbound message; fall back to a plain send if quoting is rejected |
|
||||
| `"off"` | Never quote; send as a plain message |
|
||||
|
||||
Default is `"auto"`. Per-account overrides use `channels.whatsapp.accounts.<id>.replyToMode`.
|
||||
|
||||
```json5
|
||||
{
|
||||
channels: {
|
||||
whatsapp: {
|
||||
replyToMode: "on",
|
||||
},
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
## Reaction level
|
||||
|
||||
`channels.whatsapp.reactionLevel` controls how broadly the agent uses emoji reactions on WhatsApp:
|
||||
|
||||
@@ -1042,6 +1042,7 @@ Hardening tips:
|
||||
OpenClaw loads workspace-local `.env` files for agents and tools, but never lets those files silently override gateway runtime controls.
|
||||
|
||||
- Any key that starts with `OPENCLAW_*` is blocked from untrusted workspace `.env` files.
|
||||
- Channel endpoint settings for Matrix, Mattermost, IRC, and Synology Chat are also blocked from workspace `.env` overrides, so cloned workspaces cannot redirect bundled connector traffic through local endpoint config. Endpoint env keys (such as `MATRIX_HOMESERVER`, `MATTERMOST_URL`, `IRC_HOST`, `SYNOLOGY_CHAT_INCOMING_URL`) must come from the gateway process environment or `env.shellEnv`, not from a workspace-loaded `.env`.
|
||||
- The block is fail-closed: a new runtime-control variable added in a future release cannot be inherited from a checked-in or attacker-supplied `.env`; the key is ignored and the gateway keeps its own value.
|
||||
- Trusted process/OS environment variables (the gateway's own shell, launchd/systemd unit, app bundle) still apply — this only constrains `.env` file loading.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user