Threading, /always-reply, and the gateway recovery flow - Chat Surfaces: Discord & Telegram

§4.1 was the structural case for Discord. §4.2 was the mechanical half (intents, Developer Mode, OAuth2). This article is the "the bot is online, now what" half: how to make the bot useful instead of just online. The three pieces are threading (one thread per sub-task keeps the channel clean), /always-reply (without it, the bot only responds to @mentions and looks broken), and the gateway recovery flow (when openclaw gateway restart doesn't bring the bot back, this is the path). The 3.7 context engine plugin earns its slot here too — without it, threads lose the main-chat context, which is the whole reason you started a thread.

What you'll learn

Discord threads are the right shape for sub-tasks because they keep the main channel readable. Open a thread for each new topic; let the agent work inside it.
The 3.7 context engine plugin is the change that makes threads actually remember the main chat. Pre-3.7, threads were isolated contexts.
After the bot joins, the default is mention-only mode — the bot only replies when you @mention it. Send it a chat instruction to always-reply, or every non-mentioned message will be silence.
openclaw gateway restart is the recovery path for most config-change failures. When it doesn't bring the bot back, the next step is ssh + openclaw update over Termius.
Agent-driven updates "hit permission errors and disconnects." The update path is the terminal, not the agent itself.
The OpenClaw gateway is a long-running process — it survives individual chat sessions, persists tokens, and brokers messages between Discord (or Telegram) and the agent runtime.
Why a permission error on openclaw gateway restart usually means a stale PID file or a port conflict, and how to clear both.
The interaction between the gateway and the cron scheduler: cron jobs are dispatched through the gateway, so a dead gateway means no morning briefs.
The "ACP persistent binding" change in 3.7 makes the OpenClaw ↔ Claude Code loop survive across agent restarts; without it, every Claude Code session pays a re-briefing tax.

The gateway, in plain terms

The gateway is the OpenClaw process that holds the Discord (and Telegram) connection open. It authenticates the bot token, maintains the WebSocket to Discord's gateway servers, and brokers messages between Discord and the agent runtime that actually runs your prompts. When the gateway is up, the bot is online in Discord. When the gateway is down, the bot shows offline and nothing works.

The gateway runs as a background process on the same host as OpenClaw itself. On a local install, it starts when you run openclaw start and stops when you run openclaw stop. On a VPS install, it should be supervised (systemd or supervisor) so it survives SSH disconnects and reboots.

The host's framing of why the gateway is the failure-point of choice: every config change touches the gateway. Add a channel, change a pairing policy, rotate a token — all of these require a gateway restart. And every restart is a window where the bot is offline. The fix is to make restarts fast and the recovery predictable, both of which openclaw gateway restart is supposed to do but doesn't always pull off.

The gateway restart command itself:

openclaw gateway restart

What it does, in order:

Sends SIGTERM to the running gateway process.
Waits up to 30 seconds for a clean shutdown.
Spawns a new gateway process with the current config.
The new gateway reconnects to Discord, re-authenticates, and resumes message routing.

What can go wrong:

Stale PID file. The gateway wrote a PID file but the process died; the new gateway refuses to start because the PID is "in use." Fix: rm /var/run/openclaw/gateway.pid (or the equivalent path in your install), then restart.
Port conflict. Another process is bound to the gateway's local port. Fix: lsof -i :<port> to find it, kill it, restart.
Permission error. The gateway process can't read the new config or write to its log directory. Fix: chmod -R u+rw ~/.openclaw/ (or the equivalent).
Token invalid. The bot token was rotated in the Developer Portal but the gateway still has the old one. Fix: update ~/.openclaw/.env, then restart.
Version mismatch. A new release changed the config schema and the gateway can't read the old config. Fix: openclaw update over the terminal, then restart.

If openclaw gateway restart doesn't recover, the next step is ssh + openclaw update:

# ssh into the VPS via Termius
ssh user@your-vps

# update OpenClaw to the latest version
openclaw update

# run the doctor command (3.2+) to catch missing dependencies
openclaw doctor

# restart the gateway with the new binary
openclaw gateway restart

The doctor command catches the silent failures — missing system libraries, wrong Node.js version, permission drift — that the bot-driven update silently misses.

Video 1: Setup OpenClaw with Discord (Complete Guide)

The threading and /always-reply patterns come from the same canonical Discord walkthrough as §4.1 and §4.2. The host walks through them in the second half of the video, after the bot is online.

Threads

Threads keep conversations organized:

Right-click any message in the bot's channel.
Select Create Thread.
Name it (e.g. "Research Task: AI Models").
Start chatting in the thread.

The agent will respond within the thread, keeping the main channel clean. The host uses threads for "every small topic" — an AI news aggregator, a cloud panel research task, a new dashboard — so each topic has its own conversation history and doesn't pollute the main channel.

The benefits, in the host's framing:

Focused conversations — one topic per thread.
Easy to find past discussions — thread titles are searchable.
Main channel stays organized — no megathread after a week.
Multiple parallel tasks — one thread per task, run them in parallel.

The structural rule: one thread per topic, one channel per agent. This is the same rule from §4.1, applied at the thread granularity.

/always-reply

The host emphasizes this at the end of the walkthrough: by default, the bot will only reply when you @mention it. After the bot joins your server, send it a chat message asking it to always-reply in that channel:

@YourBot from now on, respond to every message in this channel without needing @mentions.

Or use the configured pairing policy + bot behavior settings:

@YourBot only respond when I @mention you

The reverse pattern — strict mention-only — is useful for shared channels where you don't want the bot to interject on every message. For a personal bot in its own channel, always-reply is the right default.

The gateway recovery flow

The host links a short recovery video as the "next thing to watch" after the main walkthrough, and the recovery flow he describes in the main video is the standard path:

Try openclaw gateway restart first. This handles 80% of post-config failures.
```
openclaw gateway restart
```
If the gateway doesn't come back, ssh in via Termius and try openclaw update. Agent-driven updates can't recover from a restart that takes down the agent itself. The terminal path catches permission changes, missing packages, and config drift that the bot-driven update silently misses.
```
openclaw update
```
Check the OpenClaw status.
```
openclaw status
openclaw logs
```
Verify the bot token is correct. If the token was reset in the Developer Portal, you have to update ~/.openclaw/.env with the new token and restart.
Verify the channel IDs. Re-paste from Discord with Developer Mode on. If a channel was renamed or moved, the ID changed.

The host's framing is direct: "the gateway doesn't start up again after a bad config" is the #1 failure mode. Bookmark the recovery video before you start configuring, because the failure is most likely to hit right after your first openclaw gateway restart.

Video 2: NEW Openclaw 3.7 Update is INSANE!

The 3.7 release is the one that makes threading actually work. The context engine plugin is the load-bearing feature for this article.

The context engine plugin (threads remember the main chat)

Before 3.7, the structural problem was: "if you open a thread, it doesn't update the main chat." Your agent had no idea what you'd discussed elsewhere. The host's team spawns a new Discord thread for every small topic — they have threads for the AI news aggregator, the cloud panel research task, the dashboard work, and more. In the old world, opening a thread meant the main branch of the conversation "doesn't update the main chat."

The 3.7 context engine plugin connects the thread back to the main branch, so "everything ties together. It's more coherent, more cohesive." For anyone running more than one thread per channel — which is everyone running more than one agent — this is the actual "huge upgrade" and the prerequisite for the §4.5 thread discipline.

The fix is structural, not cosmetic. Without the plugin, every new thread is a fresh agent that knows nothing about the main chat. With it, the thread inherits the main-chat context and the conversation stays coherent across the channel-tree.

ACP persistent binding (the Claude Code side)

If you wire Claude Code into your OpenClaw agent (see Course 4: Claude Code & AI Coding), ACP persistent binding is the change that makes the loop usable. Before 3.7, every new Claude Code session had to be re-briefed on what it was building. ACP persistent binding "remembers what Claude Code has been building" across sessions, which "substantially" improves the loop between planning (OpenClaw) and execution (Claude Code / Windsurf).

The rest of the 3.7 surface area

Native OpenAI-stack support (GPT 5.4, Gemini 3.1 Flash) is the cost lever. Longcat integration for China-side users. The other 36+ items in the changelog are background fixes — skip them on the first read.

The model cost reality check

The host runs the most expensive tier (Opus) and burns $30–$60/day on it. The co-host is on the Minimax developer plan (flat $20/month), reports it working "substantially better" — but only after about two weeks of context optimization. The 2-week window is the rule: don't judge a new model setup on day one.

When threads fail (the pre-3.7 default)

If you haven't installed the 3.7 context engine plugin, every new Discord thread is a fresh agent with no memory of the main chat. The failure mode looks like:

User posts a question in #stark-dev.
The bot answers correctly.
User opens a thread inside #stark-dev for a sub-question.
The bot answers as if it's never met the user before.
The user is confused; the bot "lost context."

This is the pre-3.7 default. Install the context engine plugin on the 3.7+ install and the threads remember the main chat. The fix is structural — there is no per-thread prompt that compensates for the missing context engine.

Try it yourself

The hands-on goal: a bot that always-replies, threads that carry context, and a recovery path that works when the gateway dies.

Set the bot to always-reply. In the bot's channel, send: @YourBot from now on, respond to every message in this channel without needing @mentions. Test by posting a normal message (no @mention). The bot should reply. The reply should appear in the same channel (or thread) where you posted, not somewhere else.
Create a thread and test it. Right-click any message in the bot's channel, select Create Thread, name it, and start a sub-conversation. The bot should reply inside the thread, not in the main channel. Verify by checking the parent channel — no bot reply should appear there for messages sent inside the thread.
Install the 3.7 context engine plugin. On a stable 3.7 install, install the plugin and restart the gateway. Verify that a thread opened after the install carries context from the main chat — ask a follow-up question in the thread that requires knowledge of the main chat and check the bot's reply.
Practice the recovery flow. Make a deliberate bad config change (e.g. paste a wrong channel ID). Watch the gateway restart fail with an error message. Then run openclaw update over ssh/Termius. The gateway should come back. Confirm the bot is online in your member list.
Test ACP persistent binding (if using Claude Code). Start a Claude Code session, ask the bot to brief Claude on the project, restart the agent, then ask Claude to continue the work. Claude should remember without being re-briefed. Verify by asking Claude to reference something from the pre-restart conversation.
Audit the pairing policy. Confirm your bot's pairing policy is what you want. For a personal bot in its own channel, Open is fine. For shared channels, switch to Allowlist or Pairing codes. Use openclaw tui → "View paired users" to see who's currently paired.
Bookmark the recovery video. When the gateway dies at 2am, you don't want to be searching for the URL. Bookmark the host's gateway-recovery video now. Add the SSH credentials for your VPS to your password manager so you can recover from any device.
Test thread inheritance across gateway restarts. Open a thread, send a multi-message conversation, restart the gateway (openclaw gateway restart), then send another message in the same thread. The bot should remember the thread's pre-restart context — the context engine plugin should carry it over.
Run openclaw doctor after the recovery. Should report no missing dependencies. If it does, address them before going further — they often surface after a version upgrade.
Time-box the cost check. Run the bot for a day with the default 30-minute heartbeat, then for a day with a 60-minute heartbeat. Compare the OpenRouter bill. The 60-minute cadence should be ~50% of the 30-minute cadence.

Common pitfalls

Expecting the bot to reply without @mention. Default is mention-only. The host emphasises this: "by default the bot will only reply when you @mention it. After the bot joins, send it a chat message asking it to always-reply in that channel."
Running threads on pre-3.7. The context engine plugin ships in 3.7. On earlier versions, every thread is a fresh agent with no memory of the main chat. Upgrade first.
Asking the agent to update OpenClaw. Agent-driven updates "hit permission errors and disconnects" because the agent itself is the thing being restarted. Use the terminal: ssh + openclaw update.
Trying to debug an offline bot via Discord UI. The bot's actual status is in OpenClaw's logs, not Discord's. Run openclaw status and openclaw logs first.
Skipping openclaw gateway restart after a config change. Configuration changes don't apply until the gateway restarts. If you skip this step, nothing you configured will take effect.
Resetting the bot token without updating .env. If the token rotates, the gateway will fail to authenticate. Update ~/.openclaw/.env with the new token and restart.
Renaming or moving a channel without updating the channel ID. Channel IDs change when channels are renamed or moved. Re-paste from Discord (Developer Mode on) after any channel restructure.
Treating a single-thread test as proof the context engine works. Run a multi-message thread, restart the gateway, and verify the thread still carries context. The plugin is invisible until you actually test the inheritance.
Using strict mention-only on a personal bot. Mention-only mode is useful for shared channels. For a personal bot in its own channel, always-reply is the right default.
Skipping the /verbose flag when debugging. Add /verbose to your prompt to see raw tool errors. Default behaviour hides them.

Sources

Setup OpenClaw with Discord (Complete Guide) — 7,682 views · video_id: VfmG9Q69p1o
NEW Openclaw 3.7 Update is INSANE! — 7,974 views · video_id: p3aB9Qd-PIs
Supabase query (project ttxdssgydwyurwwnjogq): SELECT video_id, title, views, summary_content, summary_key_takeaways, transcript_content FROM public.videos WHERE video_id = ANY(ARRAY['VfmG9Q69p1o', 'p3aB9Qd-PIs']);