grave geodeBOT Feb 13, 2026, 8:30 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

ashen fernBOT Feb 13, 2026, 8:32 PM

#

If you’re open to building this on top of OpenClaw, you can get most of what you described without writing a custom “worker agent” from scratch:

Terminal / CLI interaction: openclaw tui gives you an interactive terminal UI connected to the Gateway
Docs: https://docs.openclaw.ai/cli/tui
Telegram (Bot API): built-in grammY-based connector (DMs + groups; can also post into a Telegram channel if the bot is added as an admin and you target the channel chat id / @handle)
Docs: https://docs.openclaw.ai/channels/telegram
Slack bot (send/receive): built-in Slack connector (Socket Mode default; HTTP Events also supported)
Docs: https://docs.openclaw.ai/channels/slack

“Relay terminal conversation to both Telegram + Slack in real time”

In OpenClaw terms, that’s usually implemented as either:

a small skill that, whenever you confirm “send this update”, calls outbound messaging to Slack + Telegram, or
a simple “tee” style workflow using the CLI openclaw message send / openclaw message broadcast (broadcast can hit multiple targets).
Docs: https://docs.openclaw.ai/cli/message

Rough timeline (for a dev who’s already done Slack/Telegram bots)

MVP (CLI + Slack + Telegram wired + basic forwarding): ~1–3 days

#

Production-ready (loop prevention, retries, formatting, auth hardening, deployment): ~1–2 weeks

Clarifying questions (these change scope a lot)

Do you need two-way sync (Slack ↔ Telegram ↔ terminal), or only terminal → (Slack+Telegram)?
When you say “new Telegram channel”, do you mean a Telegram Channel (broadcast-only) or a group chat?
Is this for one operator in the terminal, or multiple operators concurrently?
Any requirements around message threading (Slack threads, Telegram topics), file attachments, or audit logging?

If you answer those 4, I can sketch a concrete architecture and the minimal config/skill approach (OpenClaw-based) vs a greenfield Node/Python service.

jolly finch Feb 13, 2026, 8:37 PM

#

@ashen fern okay so here is the plan, i want to make a new worker agent give me way how to make new order agent.

next i want to talk to that agent specific and connect telegram specific to that agent

ashen fernBOT Feb 13, 2026, 8:39 PM

#

You can do this with Multi‑Agent Routing + bindings. Two parts:

Create a new agent (your “order” worker)
Route Telegram to that agent (either via a dedicated Telegram bot token, or by routing specific chats)

1) Create the new “order” agent

Easiest:

openclaw agents add orders
openclaw agents list --bindings

This creates a new isolated agent (separate workspace + sessions).

To talk to that agent from terminal:

openclaw tui then run: /agent orders

#

or one-shot from CLI:

openclaw agent --agent orders --message "hello order agent"

Docs: https://docs.openclaw.ai/concepts/multi-agent
Docs (terminal UI): https://docs.openclaw.ai/web/tui

2) Connect Telegram specifically to that agent

Option A (recommended): Give the orders agent its own Telegram bot

This is the cleanest “Telegram specific to that agent” setup.

Create a new bot with BotFather → get a token
Add it as a separate Telegram accountId in config, then bind that account to the agent:

#

{
  agents: {
    list: [
      { id: "main", workspace: "~/.openclaw/workspace" },
      { id: "orders", workspace: "~/.openclaw/workspace-orders" },
    ],
  },

  channels: {
    telegram: {
      accounts: {
        main:   { botToken: "123:MAIN_TOKEN" },
        orders: { botToken: "123:ORDERS_TOKEN" },
      },
      dmPolicy: "pairing",

#

    },
  },

  bindings: [
    { agentId: "orders", match: { channel: "telegram", accountId: "orders" } },
    { agentId: "main",   match: { channel: "telegram", accountId: "main" } },
  ],
}

Now: DM the orders bot → it always hits the orders agent.

Option B: Same Telegram bot, but route only a specific DM/group to “orders”

If you want one bot, but only one chat goes to the orders agent:

#

{
  bindings: [
    {
      agentId: "orders",
      match: { channel: "telegram", peer: { kind: "group", id: "-1001234567890" } },
    },
    { agentId: "main", match: { channel: "telegram" } },
  ],
}

(You can also route a specific DM by matching peer.kind: "direct" + the user id.)

Docs: https://docs.openclaw.ai/channels/channel-routing
Telegram docs: https://docs.openclaw.ai/channels/telegram

#

After config changes

Restart the gateway:

openclaw gateway restart

And if you use Telegram pairing, approve the pairing code:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

One important note: don’t paste bot tokens in a public Discord channel—share them only in your own config on your server.

jolly finch Feb 13, 2026, 8:48 PM

#

@ashen fern I have made a new agent but i can't talk to him this erro come

ashen fernBOT Feb 13, 2026, 8:52 PM

#

That error is almost always a version bug, not something you did wrong in the agent config.

1) First: what version are you on?

Please run and paste:

openclaw --version

2) If you’re on 2026.2.12

There’s a known regression in 2026.2.12 that breaks non-default agents (like loki) with:

Session file path must be within sessions directory

It’s fixed in 2026.2.13 (changelog calls it out as “Sessions/Agents … no longer fail …” #15141).

Fix: update + restart gateway:

#

openclaw update --channel beta   # or --channel dev if beta isn't available yet
openclaw gateway restart

Then reopen:

openclaw tui

…and switch to your agent again (/agent loki) and try sending a message.

3) If you’re NOT on 2026.2.12

Then it’s usually a config/path issue: double-check you didn’t accidentally set agentDir for loki to the same folder as main, or set a custom session.store path that points outside the agent’s sessions directory.

Paste (redact tokens) your agents.list entries for main + loki if you want me to sanity check them.

#

If the update fixes it, please mark the solution so it’s indexed (right-click the message → Apps → ✅ Mark Solution).

jolly finch Feb 13, 2026, 8:59 PM

#

@ashen fern okay openclaw version is 2026.2.12

worker agent was made few days ago is it running old version if so can i update it how?

main and worker agent using same api still can't talk to worker agent

ashen fernBOT Feb 13, 2026, 9:01 PM

#

Yep — that error is a known bug in 2026.2.12 that specifically breaks non-default agents (like loki) in the TUI with:

Session file path must be within sessions directory

1) Your worker agent is NOT “on an old version”

All agents run inside the same Gateway process, so they all use the same OpenClaw version. You fix it by updating OpenClaw itself.

2) Update OpenClaw (fix is in 2026.2.13)

Run:

openclaw update --channel beta
openclaw gateway restart

Then try again:

#

openclaw tui
# inside tui:
# /agent loki

If you don’t want beta, you can wait until 2026.2.13 is promoted to stable, then:

openclaw update --channel stable
openclaw gateway restart

3) After it works: check auth for the worker agent (auth is per-agent)

Even if main has API keys/tokens, each agent has its own auth-profiles.json.

Check:

#

openclaw models status --agent loki

If it shows missing creds, you have two options:

Option A (clean): re-add the token(s) while scoped to the loki agent (exact command depends on provider you use).

Option B (fast, same API creds): copy auth profiles from main → loki:

cp ~/.openclaw/agents/main/agent/auth-profiles.json \
   ~/.openclaw/agents/loki/agent/auth-profiles.json
openclaw gateway restart

If you tell me which provider you’re using (Anthropic/OpenAI/etc), I can give the exact “add token” command for the loki agent.

jolly finch Feb 13, 2026, 9:04 PM

#

@ashen fern it shows

openclaw models status --agent loki

🦞 OpenClaw 2026.2.12

ashen fernBOT Feb 13, 2026, 9:05 PM

#

You’re still on 2026.2.12 — that’s the problem.

In 2026.2.12 there’s a known bug that breaks non-default agents (like loki) and triggers the “Session file path must be within sessions directory” error. It’s fixed in 2026.2.13+.

Your worker agent is not “running an old version”

All agents run inside the same Gateway, so they all use the same OpenClaw version. You need to update OpenClaw itself.

Update (recommended)

Try this first:

openclaw update --channel beta
openclaw gateway restart
openclaw --version

You should see 2026.2.13 (or a 2026.2.13-beta/dev build).

#

If openclaw update doesn’t work on your install, use the installer (preferred update path):

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --beta --no-onboard
openclaw gateway restart
openclaw --version

After updating

Open TUI and talk to the worker:

openclaw tui
# then inside the TUI:
# /agent loki

#

If you run the update and it still shows 2026.2.12, paste the output of openclaw update --channel beta here and we’ll see why it didn’t upgrade.

jolly finch Feb 13, 2026, 9:05 PM

#

@ashen fern why it says this how to fix the this session stuff

ashen fernBOT Feb 13, 2026, 9:06 PM

#

That error isn’t “your session is corrupted” in the normal sense — it’s a bug in OpenClaw 2026.2.12 that hits non-default agents (like loki). Internally OpenClaw is trying to resolve the transcript/session file path, and 2026.2.12 sometimes resolves it wrong for non-main agents, then the safety check blocks it with:

Session file path must be within sessions directory

Fix (real fix): update to ≥ 2026.2.13, then restart

Run:

openclaw update --channel beta
openclaw doctor
openclaw gateway restart
openclaw --version

Then try again:

#

openclaw tui
# in TUI:
# /agent loki

If you updated but it STILL shows 2026.2.12

That usually means the Gateway service is still running the old install (common when you have multiple installs / daemon still pointing at old path).

Please paste the output of:

which openclaw
openclaw gateway status
openclaw update status

#

…and I’ll tell you exactly what to run next (usually re-running the installer + openclaw doctor fixes the service entrypoint).

Temporary workaround (until you update)

Use the main agent in TUI (don’t switch to loki) — this specific bug mostly affects non-default agents.

If the update fixes it, please mark the solution (right-click message → Apps → ✅ Mark Solution) so Answer Overflow indexes it.

jolly finch Feb 13, 2026, 9:11 PM

#

@ashen fern I don't want to install open claw beta

run status and stuff show me this

│ Item │ Value │
├──────────┼──────────────────────────────────────────────────────────────────────────────────────┤
│ Install │ pnpm │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest 2026.2.12

I don't know how to run on for spisifc agent can i run for speisific agent?

ashen fernBOT Feb 13, 2026, 9:12 PM

#

Stable is telling you the truth: 2026.2.12 is currently the latest stable, so if you refuse beta/dev you can’t get the fix yet. The “session file path must be within sessions directory” crash for non‑default agents is a 2026.2.12 bug (fixed in 2026.2.13).

That’s why loki blows up before using any tokens (tokens stay 0).

Can you run a specific agent?

Yes:

In TUI: openclaw tui then /agent loki (or Ctrl+G to pick agent)

One-shot CLI:

openclaw agent --agent loki --message "hi"

But on 2026.2.12 those will still hit the same bug for existing sessions.

Workarounds without installing beta (pick one)

Workaround A (often works): use a NEW session key for loki

#

The bug commonly triggers on the existing main session record.

In the TUI:

/agent loki
/session scratch (any new name)
send a message

If that works, you can keep using loki in that new session until stable updates.

Workaround B (more reliable): reset ONLY loki’s sessions (loses loki chat history)

This keeps your main agent untouched.

openclaw gateway stop
mv ~/.openclaw/agents/loki/sessions/sessions.json ~/.openclaw/agents/loki/sessions/sessions.json.bak

#

openclaw gateway start

Then try /agent loki again.

The real fix (when you’re ready)

Update to a build that includes 2026.2.13 (beta/dev), or wait until it’s promoted to stable.

If you try Workaround A, tell me whether /session scratch stops the error. If it doesn’t, Workaround B will.

vagrant bay Feb 13, 2026, 9:13 PM

#

ashen fern ```bash openclaw gateway start ``` Then try `/agent loki` again. ## The real f...

┌──────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Install │ pnpm │
│ Channel │ beta (config) │
│ Update │ pnpm · npm latest 2026.2.12 │
└──────────┴─────────────────────────────────────────

ashen fernBOT Feb 13, 2026, 9:14 PM

#

That table means:

you set your update channel to beta in config, but
there is no newer beta release published yet — both stable and beta still point to 2026.2.12 right now.

So if you won’t run dev (git/main) and you won’t wait for 2026.2.13 stable, you can’t “update your way out” of this yet.

Why you’re seeing the session error

It’s a 2026.2.12 bug that can break non-default agents (like loki) when the TUI tries to open/use the agent’s existing session transcript.

Fix options

Option 1 (no beta/dev): use a fresh session for `loki` (quick try)

In the TUI:

/agent loki
/session scratch (or /new)

#

Send a message

If it works, keep using that new session name until 2026.2.13 hits stable.

Option 2 (no beta/dev): clear ONLY loki’s session index (more reliable, loses loki chat history)

Stop the gateway first, then move loki’s session store out of the way:

openclaw gateway stop
mv ~/.openclaw/agents/loki/sessions/sessions.json ~/.openclaw/agents/loki/sessions/sessions.json.bak
openclaw gateway start

Then try TUI again: /agent loki.

Option 3 (real fix now): dev channel (not beta)

If you want the fix immediately without waiting for stable, you need dev (it’s the only place the fix exists before release):

#

openclaw update --channel dev
openclaw gateway restart

If you tell me whether Option 1 (/session scratch) worked or not, I’ll tell you the next best move.

jolly finch Feb 13, 2026, 9:16 PM

#

@ashen fern if i run

openclaw agent --agent loki --message "hi"

it work says hey back to me. but if go from

openclaw tui then /agent loki

give same error

ashen fernBOT Feb 13, 2026, 9:19 PM

#

That makes perfect sense:

openclaw agent --agent loki --message "hi" works ✅ (that CLI path isn’t hitting the buggy codepath)
openclaw tui + /agent loki fails ❌ because TUI chat runs for non-default agents are broken in 2026.2.12 (known bug; fixed in 2026.2.13).

Since you don’t want dev/beta, here’s the best workaround on 2026.2.12:

Workaround: don’t use loki’s `main` session from TUI

In TUI, switch to a new session name first, then switch agent:

Start TUI:

openclaw tui

Inside TUI run:

#

/session scratch
/agent loki

Now send a message.

Even easier: start TUI directly on a fresh loki session

openclaw tui --session agent:loki:scratch

This avoids touching the problematic agent:loki:main session from TUI.

Why this helps

Your loki main session already exists (created by earlier runs), and 2026.2.12 TUI trips over it and throws the “Session file path must be within sessions directory” error. A brand-new session like scratch usually bypasses it.

#

If /session scratch still errors, tell me what happens and I’ll give you the “clear only loki’s sessions.json” workaround (it’s a bit more destructive, but reliable).

jolly finch Feb 13, 2026, 9:23 PM

#

@ashen fern but it works for main only perfectly

using openclaw tui and setecting main.

okay scrtch that how do i connect loki to a new telegram bot i have bot created how do i connect him now

ashen fernBOT Feb 13, 2026, 9:25 PM

#

To connect agent loki to a new Telegram bot, you want to run Telegram as a separate Telegram accountId and then bind that account to loki.

0) Don’t paste your bot token here

Put the token only in your ~/.openclaw/openclaw.json (JSON5).

1) Add a Telegram “account” for Loki in config

Edit: ~/.openclaw/openclaw.json

Add/merge something like this (keep whatever you already have, this is the pattern):

{
  channels: {
    telegram: {

#

      enabled: true,

      // If you already have a main Telegram bot, keep it as "main"
      accounts: {
        // main: { botToken: "123:MAIN_BOT_TOKEN" },

        loki: { botToken: "123:LOKI_BOT_TOKEN" },
      },

      dmPolicy: "pairing",
    },
  },

  bindings: [
    // Route the *loki telegram bot* to agent loki

#

    { agentId: "loki", match: { channel: "telegram", accountId: "loki" } },

    // (optional) keep other Telegram traffic on main
    // { agentId: "main", match: { channel: "telegram", accountId: "main" } },
  ],
}

2) Restart the gateway

openclaw gateway restart

3) DM the new Loki bot and approve pairing

Open Telegram → message your new bot (/start)
On your server run:

#

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

After approval, messages sent to the Loki bot will go to agent loki.

Why this helps (and why TUI still errors)

On 2026.2.12 stable, the TUI + non-default agents (/agent loki) can hit that “session file path…” bug. Telegram routing to loki will still work fine even if TUI is flaky.

If you want, paste your (redacted) channels.telegram + bindings sections and I’ll sanity-check the JSON5 structure.

jolly finch Feb 13, 2026, 9:30 PM

#

@ashen fern so here is how it setup now no main or anything

"telegram": {
"enabled": true,
"dmPolicy": "open",
"botToken": "BOT_TOKEN",
"groups": {
"@GROUP": {
"requireMention": false,
"allowFrom": [
"*"
]

ashen fernBOT Feb 13, 2026, 9:31 PM

#

Two important notes first:

Don’t paste your real BOT_TOKEN in Discord. If you posted it anywhere public, go to BotFather and regenerate/revoke the token and update your config.
dmPolicy: "open" is risky (anyone can DM your bot). For testing it’s fine, but I strongly recommend dmPolicy: "pairing" or allowlist.

If this Telegram bot should go ONLY to agent `loki` (single bot setup)

You don’t need accounts at all. Just route all Telegram inbound to loki with a binding:

{
  bindings: [
    { agentId: "loki", match: { channel: "telegram" } },
  ],

#

  channels: {
    telegram: {
      enabled: true,
      botToken: "BOT_TOKEN",
      dmPolicy: "pairing", // or "open" if you really want it open

      // optional: group behavior
      groups: {
        "*": { requireMention: false, groupPolicy: "open" },
      },
    },
  },
}

Then restart:

#

openclaw gateway restart

If dmPolicy is pairing, DM the bot and approve:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

If you want TWO Telegram bots (one for main, one for loki)

Then you do want accounts:

#

{
  channels: {
    telegram: {
      enabled: true,
      dmPolicy: "pairing",
      accounts: {
        main: { botToken: "MAIN_BOT_TOKEN" },
        loki: { botToken: "LOKI_BOT_TOKEN" },
      },
    },
  },

  bindings: [
    { agentId: "loki", match: { channel: "telegram", accountId: "loki" } },
    { agentId: "main", match: { channel: "telegram", accountId: "main" } },

#

  ],
}

Restart gateway, then DM each bot and approve pairing codes.

About your current `groups: { "@GROUP": ... }`

Telegram groups are most reliably identified by numeric chat id (like -100123...), not @name. If you’re unsure, easiest is:

send a message in the group
run openclaw logs --follow
look for chat.id

If you paste your bindings section (with tokens removed), I can tell you if it’s routing Telegram to loki correctly.

jolly finch Feb 13, 2026, 9:33 PM

#

@ashen fern can you write me a promot that i can give it to my main bot and ask him to make the change i will giev the token directly to him for loki bot

ashen fernBOT Feb 13, 2026, 9:34 PM

#

Copy/paste this as a prompt to your main OpenClaw bot (in a private chat), and paste the Loki bot token only when it asks:

Prompt for main bot:

I want to connect a new Telegram bot to my worker agent loki.

Requirements:

Do not print my Telegram bot token back to me (treat it like a secret).
Make a backup of my config before editing.
Update my OpenClaw config (JSON5) so Telegram account loki routes to agent loki.

Steps:

Confirm agent loki exists (openclaw agents list --bindings).
Open my config file (usually ~/.openclaw/openclaw.json). Make a timestamped backup copy.
Change/ensure channels.telegram looks like this (merge with what’s there; keep other settings intact):

#

channels: {
  telegram: {
    enabled: true,
    dmPolicy: "pairing", // safer than "open"
    accounts: {
      loki: {
        botToken: "<PASTE_LOKI_BOT_TOKEN_HERE>"
      },
    },
  },
},
bindings: [
  { agentId: "loki", match: { channel: "telegram", accountId: "loki" } },

  // keep existing bindings below (don’t delete other bindings)

#

],

Important notes while editing:

If there is an existing channels.telegram.botToken, either remove it (if using accounts) or move it into accounts.main.botToken (only if I tell you I have a “main” telegram bot).
Keep my existing groups config if present.
Ensure bindings order keeps more-specific rules above less-specific ones.

Restart the gateway: openclaw gateway restart
Tell me to DM the new Loki Telegram bot (/start), then approve pairing:
- openclaw pairing list telegram
- openclaw pairing approve telegram <CODE>

After this, any message to the Loki Telegram bot should go to agent loki.

Before you write changes, show me a redacted diff/summary (no tokens), then apply it.

#

If you want, paste your current bindings section here (with tokens removed) and I’ll tell you exactly where to insert the new loki binding so it wins.

jolly finch Feb 13, 2026, 9:35 PM

#

@ashen fern what is bindings how it works?

ashen fernBOT Feb 13, 2026, 9:35 PM

#

bindings = the routing rules that tell OpenClaw which agent should handle an incoming message.

OpenClaw does not let the model “choose” an agent. It uses deterministic routing:

Mental model

channel = where the message came from (telegram, slack, discord, whatsapp, …)
agent = a separate “brain” (its own workspace + sessions + auth)
binding = “if message matches X, send it to agent Y”

How bindings work (most-specific wins)

When a message arrives, OpenClaw tries bindings in priority order, roughly:

Exact peer match (a specific DM / group / channel id)
Slack teamId / Discord guildId
Specific accountId (e.g. Telegram bot accounts.loki)
Channel-wide match (any Telegram → some agent)
Otherwise, default agent

#

So you can do things like:

“All Telegram goes to loki”
“Only this one Telegram group goes to loki, everything else goes to main”
“Telegram bot account loki goes to agent loki, bot account main goes to agent main”

Example 1: route all Telegram to loki

bindings: [
  { agentId: "loki", match: { channel: "telegram" } },
]

Example 2: route a specific Telegram group to loki, rest to main

bindings: [
  { agentId: "loki", match: { channel: "telegram", peer: { kind: "group", id: "-1001234567890" } } },

#

  { agentId: "main", match: { channel: "telegram" } },
]

Example 3 (your case): route a specific Telegram bot account to loki

If you configure:

channels: {
  telegram: {
    accounts: {
      loki: { botToken: "..." },
      main: { botToken: "..." },
    }
  }
}

#

Then bindings:

bindings: [
  { agentId: "loki", match: { channel: "telegram", accountId: "loki" } },
  { agentId: "main", match: { channel: "telegram", accountId: "main" } },
]

Why it matters

Without bindings, OpenClaw will send Telegram messages to the default agent (usually main). Bindings are how you make “this Telegram bot/chat belongs to Loki.”

Docs: https://docs.openclaw.ai/channels/channel-routing

If you paste your current bindings array (no tokens), I’ll tell you exactly what to add and where (order matters).

jolly finch Feb 13, 2026, 9:41 PM

#

@ashen fern Yes I want selerate now make a new worker agent only for the new bot

i search bndings on openclaw.json here is the stuff i found

"bindings": [],
"messages": {
"ackReactionScope": "group-mentions"
},
"commands": {
"native": "auto",
"nativeSkills": "auto"
},
"web": {
"enabled": true

Now i need you to give me the promot please again. so i can ask main bot to do the change for loki

ashen fernBOT Feb 13, 2026, 9:42 PM

#

Paste this prompt to your main OpenClaw bot (in a private chat). It’s written so it can safely update openclaw.json and set up a separate worker agent that only handles your new Telegram bot.

Prompt to give your main bot

I want a separate worker agent that is used only for a new Telegram bot.

Agent requirements:

Agent id: loki (if it doesn’t exist, create it; if it exists, reuse it)
Telegram bot should route ONLY to loki
Keep my current main bot/other channels unchanged
Do not print my Telegram token back to me and do not log it

Steps:

Check agents:

#

openclaw agents list --bindings

If agent loki does not exist, create it:

openclaw agents add loki

Edit my config file ~/.openclaw/openclaw.json (JSON5). Make a backup copy first (timestamped).
My config currently has "bindings": []. Add a binding so Telegram accountId loki routes to agent loki:

bindings: [
  { agentId: "loki", match: { channel: "telegram", accountId: "loki" } },
  // keep any existing bindings below

#

],

Update channels.telegram to use a dedicated bot token under accounts.loki.

If channels.telegram.botToken exists, move it into accounts.main.botToken only if I confirm I still want a “main” Telegram bot.
Otherwise, set ONLY accounts.loki.botToken.

Target structure (merge with existing settings like groups if present):

channels: {
  telegram: {
    enabled: true,
    dmPolicy: "pairing", // safer than "open"
    accounts: {

#

      loki: { botToken: "<LOKI_BOT_TOKEN>" },
      // main: { botToken: "<MAIN_BOT_TOKEN>" } // optional
    },
  },
},

After editing, show me a redacted summary of what changed (no tokens), then restart:

openclaw gateway restart

Tell me to DM the new Loki bot in Telegram (/start), then approve pairing:

openclaw pairing list telegram

#

openclaw pairing approve telegram <CODE>

Ask me to paste the Loki bot token only at the moment you need it, and never echo it back.

If you want, paste your current channels.telegram block with the token removed and I’ll tailor the prompt to match your exact file shape (so the bot doesn’t “guess” where to insert things).

jolly finch Feb 13, 2026, 9:55 PM

#

@ashen fern this is what my main bot saying

Still getting "Session file path must be within sessions directory" error for Loki. The binding isn't working correctly.

This is a bug with multi-account Telegram in OpenClaw. The session path validation is failing when routing to a non-default agent.

Workaround options:

Option 1: Use a different approach — instead of bindings, add Loki's mention patterns to the main agent config (like /loki or @loki)

Option 2: Create Loki as a completely separate agent with its own dedicated Telegram bot (no multi-account)

Option 3: Debug the binding path issue (requires code changes)

Quick fix — Option 1: Let me remove the binding and instead add Loki mention patterns to the main config, so you can trigger Loki with /loki or @loki in any chat:

Want me to do this? Or do you prefer a different approach? 🔧

ashen fernBOT Feb 13, 2026, 9:57 PM

#

Your main bot is half-right about the symptom, but wrong about the cause.

It’s not “a Telegram multi-account bug”.
It’s the known 2026.2.12 non-default-agent session-path bug (“Session file path must be within sessions directory”). That’s why:
- openclaw agent --agent loki --message "hi" works
- but TUI + /agent loki (and sometimes channel-driven runs) can blow up on 2026.2.12.

Since you don’t want beta/dev, here are your real options:

Option A (recommended on stable): run Loki as a separate OpenClaw instance (separate profile)

This avoids the non-default-agent bug entirely, because Loki becomes the main agent of that second instance.

1) Create a new profile config for Loki

Create/edit:

~/.openclaw-loki/openclaw.json

#

Put only the Loki Telegram bot there (token stays on your machine):

{
  gateway: {
    mode: "local",
    port: 18790, // must be different from your main gateway (18789)
  },

  channels: {
    telegram: {
      enabled: true,
      botToken: "PASTE_LOKI_BOT_TOKEN_HERE",
      dmPolicy: "pairing",
    },
  },

#

2) Start Loki gateway

openclaw --profile loki gateway

3) Pair your Telegram DM

DM the Loki bot /start, then on the server:

openclaw --profile loki pairing list telegram
openclaw --profile loki pairing approve telegram <CODE>

#

Now: that Telegram bot talks to the Loki gateway, completely separate from your main bot.

(You can also run a Loki TUI against it: openclaw --profile loki tui.)

Option B: wait for stable 2026.2.13

That release contains the fix. Right now stable (and beta) still show 2026.2.12 for you, so you can’t get the fix without dev.

Quick note on safety

Please don’t keep dmPolicy: "open" on a public bot unless you really want strangers to be able to DM it. pairing is the sane default.

If you tell me whether you want Loki to run in parallel with your main gateway (service/daemon) or just manually in a terminal, I can give the cleanest “run it as a service” commands too.

jolly finch Feb 13, 2026, 10:02 PM

#

@ashen fern okay how about can i connect it to a group and open topic and connect them on spisic topic and call worker agents from there can it possible spisifc top for that top and i don't need to mentchone it everytime i know know that topic is made for him only?

ashen fernBOT Feb 13, 2026, 10:03 PM

#

Yes — Telegram forum topics (a “topic” inside a supergroup) can map to a specific isolated session, so you can treat “this topic = Loki’s room” and not mention the bot every time.

What OpenClaw can do (today)

In a Telegram forum supergroup, each topic has a message_thread_id.
OpenClaw uses that to make a separate session key like:

agent:<agentId>:telegram:group:<chatId>:topic:<topicId>

So the bot will keep separate context per topic automatically.
(Ref: https://docs.openclaw.ai/channels/channel-routing + https://docs.openclaw.ai/channels/telegram)

Important limitation

Bindings (agent routing) can’t route by “topic id” — bindings match the group chat id, not the topic. So you can’t (yet) say “topic 42 → agent loki, topic 43 → agent main” using bindings alone.

But you can still get “this topic is only for him; no mentions needed”

You do it with per-topic settings under Telegram config:

#

Make the bot only active in one topic, and/or
Make that topic requireMention: false, while other topics stay mention-gated or disabled.

Example (single Telegram bot; dedicate one topic)

{
  channels: {
    telegram: {
      enabled: true,
      dmPolicy: "pairing",
      groups: {
        "-1001234567890": {               // your forum supergroup chat id
          requireMention: true,           // default: must mention
          topics: {
            "42": {                       // your topic id (message_thread_id)
              requireMention: false,      // in THIS topic, no mention needed

#

              enabled: true,
              // optional: skills/systemPrompt just for this topic
              // systemPrompt: "You are Loki, the order agent…",
              // skills: ["orders"],
            },

            // optional: disable the bot in other topics explicitly
            "43": { enabled: false },
            "44": { enabled: false },
          },
        },
      },
    },
  },
}

#

How to find the group chat id and topic id

Send a message inside the target topic.
Run on your gateway machine:

openclaw logs --follow

Look for:

chat.id (that’s the -100… group id)
message_thread_id (that’s the topic id)

Also required: Telegram “privacy mode”

If you want no-mention behavior in a group/topic, Telegram must actually deliver messages to the bot:

either disable BotFather privacy mode (/setprivacy → Disable), or
make the bot an admin in the group.

#

If you tell me whether you’re using one Telegram bot or you already have a separate Loki Telegram bot, I’ll give you the exact config shape to make “Topic X = Loki only, no mentions” with minimal risk.

jolly finch Feb 13, 2026, 10:05 PM

#

@ashen fern sound complex exin it to me like a 6 grade english please

ashen fernBOT Feb 13, 2026, 10:05 PM

#

Think of a Telegram forum group like a school binder:

The group is the whole binder.
Each topic is a separate tab inside the binder (like “Orders”, “Support”, “Random”).
Your bot can “listen” in the whole binder, but you can tell it:
- “Only listen in the Orders tab”
- and “Don’t make me say the bot’s name every time in that tab”.

What you want (simple version)

You want one topic that is Loki’s room.

So you go to that topic and just talk normally, and Loki replies there automatically.

How it works

You create a Telegram forum group (a supergroup with topics).
You create a topic named “Loki Orders” (or whatever).
You configure OpenClaw so:

#

In the whole group: bot needs a mention (so it stays quiet)
- In the Loki topic only: bot does NOT need a mention (so it replies every time)

What you have to do (steps)

Step A — Make sure Telegram actually sends messages to the bot
Telegram has a “privacy” setting for bots.

If privacy is ON, the bot may not see all messages.
Fix: in BotFather run /setprivacy → Disable (or make the bot an admin).

Step B — Find the two IDs
OpenClaw needs numbers to know which group/topic you mean:

the group id (looks like -100...)
the topic id (a small number)

Easy way:

Send one message inside the Loki topic.
On your server run:

#

   openclaw logs --follow

Look for:
- chat.id → that’s the group id
- message_thread_id → that’s the topic id

Step C — Put those IDs in config
Then you set:

group: requireMention: true (quiet by default)
that one topic: requireMention: false (Loki replies without mentions)

One important limitation (so expectations are clear)

This makes Loki behave like “topic = Loki room”, but it’s still the same agent behind the scenes unless you run a separate gateway/profile for Loki (because bindings can’t pick an agent by topic yet).

If you tell me:

do you already have a forum group with topics (yes/no)?

#

do you want Loki to reply only in that one topic, and be silent everywhere else (yes/no)?

…I’ll give you the exact tiny config snippet to paste (with placeholders).

jolly finch Feb 13, 2026, 10:10 PM

#

@ashen fern so here is my setup made a group on telegram i have topic added. made my main bot as admin also from bot father my main bot privecy set to DISABLE

'Disable' - your bot will receive all messages that people send to groups.
Current status is: DISABLED

so i can't even make my main bot to reply on the group topic. how do i set worker agent work.

1st give me promot lets fix my main bot replying problem.

make sure i don't have to mentchone main bot or any other bot to reply.

ashen fernBOT Feb 13, 2026, 10:11 PM

#

Copy/paste this prompt to your main bot (in a private chat with it). Don’t include any tokens.

Prompt (fix main bot replying in Telegram topic without mentions)

I need you to fix my Telegram group/topic setup so you (main bot) reply without me mentioning you.

Context:

Telegram is a forum supergroup (has topics).
The bot is admin in the group.
BotFather privacy is DISABLED (bot should receive all group messages).
Right now the bot does not reply in the topic.

Goal:

In my Telegram group/topic, reply automatically to every message (no @mention required).

#

Do this step-by-step:

Find the real group + topic IDs from logs
- Tell me to send a test message inside the target topic (e.g. “test 123”).
- While I do that, run:
```
openclaw logs --follow
```
- Extract and write down:
  - chat.id (looks like -100...) ← this is the group id
  - message_thread_id ← this is the topic id
Fix my config to allow replies without mention
Edit ~/.openclaw/openclaw.json (JSON5). Make a backup first.
Then update/merge Telegram group settings so the bot is allowed and doesn’t require mention.

Use the numeric IDs you found (do NOT use @groupname).

#

Recommended config shape:

channels: {
  telegram: {
    enabled: true,

    // allow group messages from anyone in the group
    groupPolicy: "open",

    groups: {
      "<CHAT_ID>": {
        requireMention: false,
        groupPolicy: "open",

        // Optional: lock it to just one topic (recommended)

#

           topics: {
             "<TOPIC_ID>": {
               requireMention: false,
               groupPolicy: "open",
             },
           },
         },
       },
     },
   }

Important:

If channels.telegram.groups exists, it acts like an allowlist — so make sure the real chat.id is present (or use "*").
Keep other existing settings intact.

#

Restart
```
openclaw gateway restart
```
Verify
- Tell me to post a normal message in that topic (no mention).
- If it still doesn’t reply, run:
```
openclaw channels status --probe
```
and check logs for any “skip reason” (requireMention / group not allowlisted / sender blocked).

Safety check:

Confirm with me that setting groupPolicy: "open" means the bot can reply to anyone in that group/topic.

#

If you want, paste your current channels.telegram block here with the token removed, and I’ll rewrite the config snippet with the exact keys you already have so it’s copy/paste-safe.

jolly finch Feb 13, 2026, 10:21 PM

#

@ashen fern main bot now talk to the telegram froum with out any problem nice!

now i want to talk to my worker agent loki to a new topic from that temegram forum

ashen fernBOT Feb 13, 2026, 10:21 PM

#

Nice — now for “Loki lives in this forum topic”:

Key point (so it’s not confusing)

With one Telegram bot, OpenClaw can keep separate memory per topic, but it can’t route different topics to different agents.
So if you want a whole topic to be “Loki-only, no mentions”, the clean way is:

Give Loki its own Telegram bot and add that bot to the same forum group.

What to do (simple steps)

1) Create a new topic for Loki

In your Telegram forum group, create a topic like “Loki Orders”.

2) Add Loki’s Telegram bot to that group

Add the Loki bot to the forum group

#

Make it admin (or at least ensure it can read/send)
(Privacy disabled is good; admin is usually easiest)

3) Run Loki as a separate OpenClaw “profile” (separate instance)

This avoids the 2026.2.12 “non-default agent” bug entirely, because Loki will be the main agent of that Loki instance.

Create this file:

~/.openclaw-loki/openclaw.json (JSON5)

{
  gateway: { mode: "local", port: 18790 }, // different port than your main bot

  channels: {
    telegram: {

#

      enabled: true,
      botToken: "PASTE_LOKI_BOT_TOKEN_HERE",
      dmPolicy: "pairing",

      // only reply in the one forum group + one topic:
      groups: {
        "-100YOUR_GROUP_ID": {
          groupPolicy: "open",
          requireMention: false,
          topics: {
            "YOUR_TOPIC_ID": {
              enabled: true,
              groupPolicy: "open",
              requireMention: false,
            },

#

          },
        },
      },
    },
  },
}

Start Loki:

openclaw --profile loki gateway

Pair your DM (if using pairing), then test in the topic:

#

openclaw --profile loki pairing list telegram
openclaw --profile loki pairing approve telegram <CODE>

4) (Optional but recommended) Disable your MAIN bot in Loki’s topic

So you don’t get two bots replying in the same topic. In your main config, add:

channels: {
  telegram: {
    groups: {
      "-100YOUR_GROUP_ID": {
        topics: {
          "YOUR_TOPIC_ID": { enabled: false },
        },

#

      },
    },
  },
}

Restart main gateway after that.

How to get the IDs (fast)

Send a message inside the Loki topic, then:

openclaw logs --follow

#

Look for:

chat.id → the -100... group id
message_thread_id → the topic id

If you paste those two numbers (no tokens), I’ll plug them into the exact config snippet for you.

jolly finch Feb 13, 2026, 10:24 PM

#

@ashen fern how do i connect loki to a new telegram bot we failed last time lets pdate hte open claw to beta if that fix and i can talk to him on a new telegram bot

ashen fernBOT Feb 13, 2026, 10:25 PM

#

Updating to beta is a good move here — that “Session file path must be within sessions directory” bug is fixed in 2026.2.13, so once beta actually gives you > 2026.2.12, Loki should behave normally (TUI + Telegram routing).

1) Update OpenClaw to beta (and confirm it’s newer than 2026.2.12)

Run:

openclaw update status
openclaw update --channel beta
openclaw --version
openclaw gateway restart

If openclaw --version still shows 2026.2.12, then beta hasn’t been published yet on your machine’s channel, and beta won’t help (you’d need dev or wait for stable).

(If openclaw update --channel beta doesn’t update because you installed via pnpm, the fallback is:)

#

pnpm add -g openclaw@beta
openclaw --version
openclaw gateway restart

Docs: https://docs.openclaw.ai/install/updating and https://docs.openclaw.ai/cli/update

2) Connect Loki to a NEW Telegram bot (multi-account Telegram)

In ~/.openclaw/openclaw.json set Telegram to use accounts, then route the loki account to the loki agent via bindings.

Example shape (DO NOT paste tokens in Discord):

{
  channels: {

#

    telegram: {
      enabled: true,
      dmPolicy: "pairing",
      accounts: {
        main: { botToken: "MAIN_BOT_TOKEN" },
        loki: { botToken: "LOKI_BOT_TOKEN" },
      },
    },
  },

  bindings: [
    { agentId: "loki", match: { channel: "telegram", accountId: "loki" } },
    { agentId: "main", match: { channel: "telegram", accountId: "main" } },
  ],
}

#

Then:

openclaw gateway restart

3) Pair your Telegram DM with the Loki bot

DM the Loki bot in Telegram (/start)
Approve pairing:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Docs: https://docs.openclaw.ai/channels/telegram and https://docs.openclaw.ai/channels/channel-routing

#

If you run the update commands, paste back (no tokens):

openclaw --version
openclaw update status

and I’ll tell you immediately whether beta actually contains the fix on your setup.

jolly finch Feb 13, 2026, 10:36 PM

#

@ashen fern update didint work are you sure there is new beta tha fix the conecting multiple bot?

ashen fernBOT Feb 13, 2026, 10:37 PM

#

No — right now beta doesn’t have a newer build for you, so openclaw update --channel beta can’t pull the fix yet.

What you’re seeing is consistent with:

stable = 2026.2.12
beta = also 2026.2.12 (beta and stable can point to the same version)

The fix for the Loki/session-path issue is in 2026.2.13 (unreleased), so until a 2026.2.13 beta is published, “updating to beta” won’t change anything.

Quick way to confirm what beta points to

Run:

npm view openclaw dist-tags
npm view openclaw@beta version
npm view openclaw@latest version

#

openclaw --version

If openclaw@beta version == openclaw@latest version (likely 2026.2.12), then there is no beta fix available yet.

What to do instead (if you want it working now)

Option 1 (fastest): use dev (has the fix)

This is the only way to get the 2026.2.13 fix before it’s released:

openclaw update --channel dev
openclaw gateway restart

#

openclaw --version

(Dev can be less stable, but it will include the fix.)

Option 2 (stable-only): run Loki as a separate profile / second instance

This avoids the non-default-agent bug on 2026.2.12 because Loki becomes the “main” agent of that second instance.

If you paste the output of:

openclaw update status
npm view openclaw@beta version

#

I can tell you immediately whether beta is actually newer on your machine right now.

dusk basin Feb 13, 2026, 10:37 PM

#

Recruitment is against this server's rules. Just in case you're wondering where your top post went.

ashen fernBOT Feb 13, 2026, 10:37 PM

#

Good call, thanks for the heads-up.

For anyone following along: if you need help building something with OpenClaw, post it as a setup/implementation question (what you want to achieve + current config/logs), not as a “looking to hire” request. That keeps it within server rules and also gets you better technical help.

jolly finch Feb 13, 2026, 10:40 PM

#

@ashen fern so what's the solution now! with out making it dev setup i can't connect worker bot to new telegram bot?

ashen fernBOT Feb 13, 2026, 10:41 PM

#

On 2026.2.12 (and right now your “beta” is still 2026.2.12), the truth is:

Routing a new Telegram bot to a non-default agent (loki) inside the same Gateway is not reliable yet, because that session-path bug hits non-default agents.
So if you don’t want dev, the working solution today is: run Loki as a separate Gateway instance (still stable) with its own Telegram bot.

That way, Loki is the main agent of that second instance → the bug doesn’t trigger.

Solution (stable, no dev): run a 2nd OpenClaw instance for Loki using `--profile`

1) Create Loki’s profile config

Create this file on your server:

~/.openclaw-loki/openclaw.json (this is a separate state/config)

Minimal example (paste your Loki bot token here on your server, not in Discord):

#

{
  gateway: { mode: "local", port: 18790 }, // must be different than your main gateway (18789)

  channels: {
    telegram: {
      enabled: true,
      botToken: "LOKI_BOT_TOKEN",
      dmPolicy: "pairing",
    },
  },
}

2) Start Loki gateway

#

openclaw --profile loki gateway

(Leave it running, or install it as a service later.)

3) Set up model/API key for Loki profile (important)

Profiles have separate state, so make sure Loki has model creds too:

openclaw --profile loki models status

If it’s missing creds, add the same API key/setup-token you used for main (in the Loki profile).

4) Add Loki bot to your Telegram forum + use one topic just for Loki

Add the Loki Telegram bot to the same forum group

#

Make it admin + privacy disabled (like you did for main)
Create a topic like “Loki”
Talk in that topic

(Optional but recommended) disable your main bot in Loki’s topic so only Loki replies.

When can you do it “the nice way” (single gateway + bindings)?

When 2026.2.13 becomes available on stable/beta. Right now you can’t update to it because it’s not published for you yet.

If you tell me what OS you’re running the gateway on (Linux/macOS) and whether you want Loki to run “always on” as a service, I’ll give you the exact openclaw --profile loki gateway install ... commands.

jolly finch Feb 13, 2026, 10:43 PM

#

@ashen fern can't run new worker agent on seperate gateway on one mechine i try that it didn't work

if there is work around let me know I may don't know

ashen fernBOT Feb 13, 2026, 10:44 PM

#

You can run a “Loki bot” on the same machine — but the usual reason it “doesn’t work” is one of these:

you picked a port too close to the main gateway (hidden ports collide), or
you didn’t run commands with --profile loki consistently (so you were still editing/starting the main instance), or
the Loki profile is missing model credentials (so it runs but can’t answer).

Here’s the simplest stable workaround that avoids the 2026.2.12 multi-agent bug:

✅ Working recipe: run Loki as a 2nd Gateway using a profile + far-away port

1) Pick a port far away (IMPORTANT)

Don’t use 18790. Use something like 19789 (docs recommend leaving ~20 ports gap).

2) Create Loki config (separate state)

Create/edit this file on your server:

~/.openclaw-loki/openclaw.json

#

{
  gateway: { mode: "local", port: 19789 },

  channels: {
    telegram: {
      enabled: true,
      botToken: "PASTE_LOKI_BOT_TOKEN_HERE",
      dmPolicy: "pairing",
    },
  },
}

3) Start the Loki gateway (foreground, to see errors)

#

openclaw --profile loki gateway --port 19789 --verbose

Leave that running.

4) Make sure Loki profile has model auth

In another terminal:

openclaw --profile loki models status

If it says missing credentials, you must add the same API key/setup-token for the Loki profile (profiles do not share auth automatically).

5) Connect to Loki via TUI (optional)

#

openclaw --profile loki tui

If it still “didn’t work”, I need the exact error

Please paste (no tokens):

openclaw --profile loki status
openclaw --profile loki gateway status

…and tell me what happens when you run:

#

openclaw --profile loki gateway --port 19789 --verbose

Most of the time the error message will clearly say “port already in use”, “refusing to start unconfigured”, or “missing credentials”, and we can fix it in one step.

jolly finch Feb 13, 2026, 10:50 PM

#

@ashen fern hmm okay how do i check my slack seassions it's running slow can i clear it?

ashen fernBOT Feb 13, 2026, 10:51 PM

#

If Slack feels “slow”, it’s usually because the current Slack session has gotten huge (lots of back-and-forth context). You don’t need to delete anything on disk first.

1) See what Slack sessions exist

On the gateway machine run:

openclaw sessions --active 1440

Look for session keys that contain :slack: (they’ll look like agent:main:slack:channel:... or agent:main:slack:direct:...).

If you want everything (bigger output):

openclaw sessions --json

#

2) Clear/reset the slow Slack chat (recommended)

In the same Slack DM/channel/thread that feels slow, send one message:

/new

(or /reset)

That starts a fresh session for that chat, so replies get fast again.

If you want to keep the chat but shrink it (instead of fully resetting), use:

/compact

#

3) (Only if you really want a hard wipe)

There isn’t a “delete one Slack session” CLI yet; hard wipes are more destructive. If you think you need that, tell me:

is it a Slack DM, channel, or a thread?
and do you want to wipe just that one, or all Slack history?

Then I’ll give the safest next step.

jolly finch Feb 13, 2026, 10:54 PM

#

@ashen fern This /command don't work on slack i try it i think i need to setup seperatey but don't work for me on slack i have to do @menshone to call the bot i whink i don't have to do that in private channel there is more that 1 people bot me and my partnerts as well so few people there and tehy all call bot only

ashen fernBOT Feb 13, 2026, 10:55 PM

#

In Slack, “private channel” still counts as a channel, not a DM — and OpenClaw is mention-gated in channels by default. That’s why you currently have to mention it.

1) Make the bot reply in that Slack channel without @mention

You need to set requireMention: false for that channel in config.

Step A — get the Slack channel ID (looks like C012ABC…)

Easiest: open the channel in Slack → the URL contains the channel id (…/archives/C012ABC…)

Or via CLI (if directory works for you):

openclaw directory groups list --channel slack --query "channel-name"

Step B — add channel config
In ~/.openclaw/openclaw.json:

#

{
  channels: {
    slack: {
      groupPolicy: "open", // or "allowlist" if you want tighter control
      channels: {
        "C012ABCDEF": {
          requireMention: false,

          // optional safety: only allow these users to trigger the bot
          // users: ["U01...", "U02..."],
        },
      },
    },
  },
}

#

Then restart:

openclaw gateway restart

After that, anyone in that channel (or only the users allowlist if you set it) can just type normally and the bot should respond.

2) Why `/new` “doesn’t work” in Slack

Slack treats messages starting with / as Slack slash commands, so "/new" never reaches OpenClaw as a normal chat message.

Two ways to reset the session in a Slack channel:

Option A (quick): send "/new" as part of a normal message (so Slack doesn’t intercept it), e.g.

mention the bot once: BotName /new

#

(after you set requireMention:false, you can even do something like: reset please: /new)

Option B (proper Slack way): set up a Slack slash command (like /openclaw) and enable channels.slack.slashCommand or channels.slack.commands.native (more setup).

If you paste the Slack channel URL (just the part that includes C0…, no tokens), I can give you the exact config block with the right channel id.

jolly finch Feb 13, 2026, 10:57 PM

#

@ashen fern can you make a promot for me so i can give my main bot to do that change for me

ashen fernBOT Feb 13, 2026, 10:57 PM

#

Paste this prompt to your main bot (private chat). No tokens needed.

Prompt: make Slack channel reply without @mention

I want OpenClaw to reply in a specific Slack channel without requiring @mention.

Goal:

In channel <PASTE_SLACK_CHANNEL_ID_HERE> (looks like C012ABC...), the bot should respond to normal messages (no mention).
Optional safety: only allow me + my partner to trigger it (I can provide user IDs if you ask).

Steps:

Ask me for the Slack channel ID (C...) and (optional) allowed user IDs (U...).
Edit my config file ~/.openclaw/openclaw.json (JSON5). Make a timestamped backup first.
Add/merge this config (keep existing Slack settings intact):

#

channels: {
  slack: {
    // keep existing tokens/settings
    groupPolicy: "open", // or keep my current value

    channels: {
      "<CHANNEL_ID>": {
        requireMention: false,

        // optional allowlist (only add if I provide IDs)
        // users: ["U01...", "U02..."],
      },
    },
  },
}

#

Restart gateway:

openclaw gateway restart

Verify:

I will send a normal message in that Slack channel (no mention).
Confirm the bot replies.
If it doesn’t, run openclaw logs --follow and tell me the skip reason.

Important:

Don’t remove other Slack channel configs.
Don’t echo any tokens/secrets.

Tip to you: you can get the channel ID from the Slack channel URL (.../archives/C012ABC...).

jolly finch Feb 13, 2026, 11:01 PM

#

@ashen fern this is my slack channel setup

"slack": {
  "mode": "socket",
  "webhookPath": "/slack/events",
  "enabled": true,
  "botToken": "slck_token",
  "appToken": "slack_bot_token",
  "userTokenReadOnly": true,
  "groupPolicy": "open"
}

ashen fernBOT Feb 13, 2026, 11:01 PM

#

Your Slack config is fine for connecting (Socket Mode + tokens). The reason you still have to @mention in that “private channel” is: Slack channel messages are mention-gated by default, even when groupPolicy: "open".

To make the bot reply without @mention, you need a per-channel override:

1) Get the Slack channel ID

It looks like C012ABCDEF.

Fast ways:

From Slack desktop/web URL: it contains /archives/C012ABCDEF

Or (if directory works):

openclaw directory groups list --channel slack --query "channel-name"

2) Add channel override in `openclaw.json`

Keep what you have, just add a channels map under channels.slack:

#

channels: {
  slack: {
    mode: "socket",
    enabled: true,
    botToken: "…",
    appToken: "…",
    groupPolicy: "open",

    channels: {
      "C012ABCDEF": {
        requireMention: false,

        // optional safety: only you + partner can trigger
        // users: ["U01AAAAAAA", "U02BBBBBBB"],

#

        // optional: ignore other bots
        // allowBots: false,
      },
    },
  },
}

Then restart:

openclaw gateway restart

Now people can talk normally in that channel and the bot should reply without @mention.

#

Important security note

You pasted tokens in Discord (even if partially redacted). If those are real, rotate them in Slack immediately and update your config.

If you paste the channel URL (just the part with /archives/C…, no tokens), I can tell you exactly what to put for the channel id.

jolly finch Feb 13, 2026, 11:03 PM

#

@ashen fern when will the new bot connect will be fix to telegram like connect new worker agent to bot and group as well

ashen fernBOT Feb 13, 2026, 11:04 PM

#

I can’t give an exact date (releases aren’t on a guaranteed schedule), but the fix is already in main and is slated for 2026.2.13. You’ll be able to do “Telegram bot → worker agent (loki) via bindings/accounts” cleanly once 2026.2.13 is published to beta (and later promoted to stable).

How to know when it’s fixed (takes 10 seconds)

On your gateway machine, run:

npm view openclaw dist-tags
npm view openclaw@beta version
npm view openclaw@latest version

When openclaw@beta version becomes 2026.2.13 (or higher), you can update and the Loki/Telegram routing should stop breaking.

Then update

If you installed with pnpm, do:

#

pnpm add -g openclaw@beta
openclaw --version
openclaw gateway restart

Until then (2026.2.12)

The reliable workaround is still:

separate gateway profile/instance for Loki, or
keep everything on main (no worker agent routing) and use topic-based behavior / system prompts.

If you paste the output of npm view openclaw dist-tags here, I’ll tell you immediately whether beta has moved yet on your side.

jolly finch Feb 13, 2026, 11:05 PM

#

@ashen fern npm view openclaw dist-tags
{ latest: '2026.2.12', beta: '2026.2.12' }

ashen fernBOT Feb 13, 2026, 11:05 PM

#

Yep — that confirms it: beta and stable are the same version right now.

latest: 2026.2.12
beta:   2026.2.12

So there is no beta build yet that contains the fix, which is why “update to beta” didn’t change anything and why connecting a new Telegram bot → worker agent (loki) is still flaky on 2026.2.12.

What you can do right now (no dev)

Option 1 (best today): “Loki topic” without a separate agent

Use one agent (main) but dedicate a Telegram forum topic to “Loki Orders” by setting:

in that topic: requireMention: false
optional: a topic-only systemPrompt / skills so it behaves like Loki

This gives you “Loki room” behavior even though it’s technically still the main agent.

#

Option 2: run Loki as a second gateway/profile (still stable)

This does work on one machine, but it’s easy to mess up (ports, profile mismatch, missing creds). If you want, paste the exact error you got when you tried openclaw --profile loki gateway --port 19789 --verbose and I’ll tell you the fix.

When will real multi-agent Telegram routing work?

When 2026.2.13 (or later) becomes available as beta, then promoted to latest. You can keep checking with the same command; once beta changes, you can update.

If you want, tell me which path you prefer right now:

“Loki topic” inside main agent (fast, no extra process), or
second gateway/profile (clean isolation, but more setup).

jolly finch Feb 13, 2026, 11:07 PM

#

@ashen fern 1

ashen fernBOT Feb 13, 2026, 11:07 PM

#

Cool — option 1 means: you keep only the “main” agent, but you make one Telegram topic act like “Loki” by giving that topic its own settings + prompt.

So when you talk in that topic, the bot will answer normally without mentions, and it will “behave like Loki” in that topic.

Step-by-step

1) Pick the Loki topic

In your Telegram forum group, make (or choose) a topic like “Loki Orders”.

2) Get the two numbers (IDs)

Send one message inside that Loki topic (like “test loki”).

On your gateway machine run:

openclaw logs --follow

#

Look for:

chat.id → the group id (looks like -100...)
message_thread_id → the topic id (a number like 42)

3) Add a “Loki topic config” in `~/.openclaw/openclaw.json`

Put your real IDs in here:

{
  channels: {
    telegram: {
      groups: {
        "-100YOUR_GROUP_ID": {
          // group defaults (you can keep your existing working settings)
          groupPolicy: "open",
          requireMention: false,

#


          topics: {
            "YOUR_TOPIC_ID": {
              enabled: true,
              groupPolicy: "open",
              requireMention: false,

              // This is the magic: topic-only personality/instructions
              systemPrompt: `
You are Loki, my worker agent for orders.
In this topic ONLY:
- Ask clarifying questions if the request is missing details.
- Keep replies short and action-focused.
- If something is not an order/task request, ask whether to create an order or ignore it.
`,

#

              // Optional: restrict to certain skills if you use them:
              // skills: ["orders"],
            },
          },
        },
      },
    },
  },
}

4) Restart

openclaw gateway restart

#

5) Test

Go to the Loki topic and type normally. No mention needed.

What this gives you (and what it doesn’t)

✅ One topic = one “Loki room” (separate memory/session because it’s a topic)
✅ No mentions needed (you already set privacy disabled + admin, so it can see messages)
❌ It’s not a truly separate agent with separate files/auth — it’s still the main agent, just with a topic-specific prompt + session

If you paste your group id and topic id (just the numbers), I’ll plug them into the exact snippet so you can copy/paste it safely.

jolly finch Feb 13, 2026, 11:13 PM

#

@ashen fern okay tell me something.

the main reason i want to build a new worker agent. I want that agent to do product recharge and copywiring as well.

under his i want to build sub-agent with there own memory.

like reccharge reader
idea generate from that
writing
reviewing
checking with tears

find new topic
learn
social media chek

and all sub agent have option to use diffrent api
like if need to generate image use that sub bot who will generate the image
for vidoe use diffrent sub agent make that happen

you got me?

so for that setup new seperate worket agent is readlly needed. so the main agent don't forget his task that is dddrent he don't made for the other task

let me understand can this possible now.

also like worker agent i am trying to build they will aso talk to eaach another

like main worker agent start the work and start the recharge
ocne done he pass it to reader and review
then pass it to image or vide generator

Keep going like this

ashen fernBOT Feb 13, 2026, 11:14 PM

#

Yep, I got you.

You’re describing a manager + specialist workers setup:

Main “manager”: talks to you, keeps the big plan, starts tasks.
Worker “Loki”: only does “product recharge + copywriting”.
Under Loki you want smaller specialists:
- recharge reader → idea generator → writer → reviewer → QA/tests
- image bot (different API/model)
- video bot (different API/model)
And they can hand work to each other in a pipeline.

Can OpenClaw do this?

Yes, conceptually. OpenClaw supports:

Multiple agents (each has its own workspace + memory files + auth)
Sub-agents (background workers that do one task and report back)
Agent-to-agent messaging (agents can talk to each other when enabled)

#

The “right” way (what you ultimately want)

Use multiple real agents:

manager
loki-recharge
loki-writer
loki-reviewer
media-image
media-video

Each agent can have:

its own MEMORY.md / files (durable memory)
its own model + API keys (because auth is per-agent)
its own tool permissions (image agent can have image tools, etc.)

Then enable agent-to-agent messaging:

#

tools: {
  agentToAgent: {
    enabled: true,
    allow: ["manager", "loki-recharge", "loki-writer", "loki-reviewer", "media-image", "media-video"],
  },
},

The problem right now for you

You’re on 2026.2.12 and beta == stable. There’s a known bug that makes non-default agents unreliable in some reply paths (you already hit it with Loki). The fix lands in 2026.2.13 (not published yet).

So: full “many worker agents + Telegram routing” is painful until 2026.2.13 is released, unless you use dev or separate gateways.

What you can do NOW (stable) that still matches your goal

#

Use one agent (main) but split work by Telegram forum topics + topic prompts + files for durable memory.

Make topics like:

“Recharge Reader”
“Idea Generator”
“Writing”
“Review / QA”
“Images”
“Video”

In each topic, set a topic-only systemPrompt (like we did for “Loki Orders”) and tell the bot:

“In this topic, you are the Writer.”
“Always write your notes to memory/writer.md.”
“Only do writing tasks here.”

That gives you:

#

separate conversation memory per topic (topics are separate sessions)
durable memory via files (so it won’t forget)
a pipeline feel: you post output from one topic into the next

If you want, I can write you a single copy/paste config template for 5 topics (Reader/Ideas/Writer/Reviewer/Media) — you just fill in the group id + topic ids.

When 2026.2.13 drops

We convert those topic-roles into real agents cleanly (each with separate API keys and real agent-to-agent handoffs).

jolly finch Feb 13, 2026, 11:19 PM

#

@ashen fern understood. lets wait for the new update will be great.

and when agent call each other and talk to each other i can see that from slack/telegram right?

so i can call main loki what to do if something not looking good. and he talk to that sub agent i see the convecrtion and see the update readl time the in group chat? possible right with there own id and stuff?

ashen fernBOT Feb 13, 2026, 11:20 PM

#

Mostly yes — but with two important “gotchas” about what you’ll actually see in Slack/Telegram.

What you’ll see in Slack/Telegram when agents call sub-agents

When the main agent spawns a sub-agent, the sub-agent runs in the background and then posts its result back into the same chat (that’s the default “announce results back to requester” behavior).
So you’ll see progress like:
- “I’m sending this to the Reviewer sub-agent…”
- then later a message with the reviewer’s findings.

You can jump in at any time in the chat (“Stop, that looks wrong, change X”), and the main agent can continue / adjust / re-run.

What you won’t see by default

1) You won’t see a full “agent A ↔ agent B” transcript in chat

Internal agent-to-agent messages aren’t automatically mirrored as a live chat log. Usually you see summaries and outputs that the main agent chooses to post.

If you want maximum transparency, you can instruct the main agent:

“Post every sub-agent result verbatim”
“Post step-by-step checkpoints”

#

2) “Their own ID / name” is limited by the bot account

In Slack/Telegram, messages come from the same bot account (same Slack app bot user / same Telegram bot). Even if you have multiple OpenClaw agents, they won’t appear as separate “users” unless you run separate bot accounts.

Workarounds:

Add a prefix in replies, e.g. [Loki] …, [Reviewer] …
Or later: use separate Telegram bots / separate Slack apps if you truly want distinct identities.

Best practical setup (once the update lands)

One “manager” agent that you talk to in Slack/Telegram
It spawns sub-agents for reader/writer/reviewer/image/video
Each sub-agent posts results back
Manager coordinates and you can override anytime

When 2026.2.13 is out and you wire Loki properly, you’ll get the “specialist worker” separation and better reliability.

If you tell me which surface you care about most (Slack channel vs Telegram forum topic), I can suggest the cleanest “prefix + threading” pattern so it feels like separate bots even though it’s one bot account.

jolly finch Feb 13, 2026, 11:39 PM

#

@ashen fern okay can you tell me something once the new update come up and I connect multiple worker bot in telegram forum

Each with there own task can my bot talk to each other in the channel

Like I call main bot to ask worker bot to do something, and he did. And mentioned back if needed anything from main bot and he replied will that work ?

ashen fernBOT Feb 13, 2026, 11:42 PM

#

Yes — the workflow you described can work, but it helps to separate two ideas:

1) Can “main” delegate work to “Loki” and you see updates in Telegram/Slack?

Yes. Once the update lands and multi‑agent routing is stable again, you can do:

You talk to Main in a Telegram topic (or Slack channel).
Main sends a task to Loki (worker agent).
Loki does the task and posts results back into the chat so you can see it.

You can also tell Main: “Always post Loki’s output back here” so it’s transparent.

2) Can the bots “talk to each other” inside the channel like a conversation?

Kind of — with an important caveat:

Internally, agents can message each other (agent‑to‑agent) and coordinate.
But that internal chat is not automatically shown in Telegram/Slack unless you ask them to mirror it.

So what you’ll typically do is:

#

Main ↔ Loki talk internally to coordinate
Main posts: “Loki asked X, I answered Y, here’s the result…”

That avoids weird bot loops.

3) Will each worker show as its “own user / name” in Telegram?

Only if you give each worker its own Telegram bot account (separate bot tokens) and add them to the forum group.

One Telegram bot + many agents → messages still come from the same Telegram bot user (you can add prefixes like [LOKI]).
Many Telegram bots (one per agent) → they appear as different bot users in the group.

4) Recommended “clean” Telegram forum layout (works well)

Topic “Control Room” → Main bot lives here (you talk to it)
Topic “Loki – Recharge” → Loki bot lives here (no mention required)
Topic “Writer” → Writer bot
Topic “Reviewer” → Reviewer bot
Topic “Images” → Image bot

#

Topic “Video” → Video bot

Then you tell Main: “Delegate to Loki / Writer / Reviewer and post the results back.”

If you want, when the new version drops, I can give you a copy/paste template for:

enabling agent‑to‑agent coordination safely, and
forcing “mirror the handoffs into chat” so you actually see the pipeline in real time.

jolly finch Feb 13, 2026, 11:51 PM

#

@ashen fern how about if I setup new port can I run openclaw config on worker agent and active 2 seperte open claw at the same time?

ashen fernBOT Feb 13, 2026, 11:51 PM

#

Yes — you can run two OpenClaw Gateways on the same machine at the same time, as long as you:

give the second one a different port, and
keep its config + state separate.

The easiest way is using profiles.

How to do it (simple)

1) Main bot (normal)

Runs on the default profile (no --profile):

openclaw gateway restart

2) Worker bot (separate OpenClaw) on a new port

#

Pick a port far away, like 19789 (don’t use 18790; ports close together can collide).

Create/setup the worker profile:

openclaw --profile worker setup
openclaw --profile worker config set gateway.port 19789 --json

Start the worker gateway:

openclaw --profile worker gateway

Now you have:

main gateway on 18789

#

worker gateway on 19789

3) Run `openclaw config` for the worker instance

Any config command for the worker just needs --profile worker, like:

openclaw --profile worker config get channels.telegram.enabled
openclaw --profile worker config set channels.telegram.enabled true --json

4) Check both are running

openclaw gateway status
openclaw --profile worker gateway status

Notes / common mistakes

#

Profiles create separate folders automatically: ~/.openclaw-worker/…
You must use --profile worker every time when you mean the worker bot (status/config/logs/etc).
Each profile has its own API keys / auth, so you may need to set up models again in the worker profile.

Docs: https://docs.openclaw.ai/gateway/multiple-gateways

If you tell me your OS (Linux/macOS) and how you start the gateway (service vs terminal), I can give you the exact “run both as services” commands too.

jolly finch Feb 14, 2026, 7:37 AM

#

@ashen fern okay i just run loki gateway with new port got pairing code. how to cofig it now

ashen fernBOT Feb 14, 2026, 7:40 AM

#

That “pairing code” usually means DM access is in pairing mode: the bot won’t process your message until you approve that sender.

1) Approve the pairing code (most common)

On the machine running the Gateway (“loki”):

openclaw pairing list telegram   # or slack / discord / whatsapp / signal
openclaw pairing approve telegram <CODE>

Then send a message to the bot again — it should reply normally.

Docs: https://docs.openclaw.ai/channels/pairing#1-dm-pairing-inbound-chat-access

2) If you meant “pair a device/node” (phone/mac) to the Gateway

That’s device pairing, not DM pairing:

#

openclaw devices list
openclaw devices approve <requestId>

Docs: https://docs.openclaw.ai/channels/pairing#2-node-device-pairing-iosandroidmacosheadless-nodes

Quick clarifier

Where did you see the pairing code — in Telegram/Slack/Discord chat, or printed in the Gateway terminal/UI? And are you trying to (a) chat with the bot, or (b) connect a node/device?

jolly finch Feb 14, 2026, 7:43 AM

#

@ashen fern i got the pairing code from loki telegram how to active for that worker pairing now

ashen fernBOT Feb 14, 2026, 7:44 AM

#

If the code came as a Telegram DM from your bot, that’s DM pairing. You “activate” it by approving that code on the Gateway host (loki):

# run on loki (where the gateway is running)
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Then DM the bot again in Telegram — now it should actually process/reply (before, it only sent the code and ignored your message).

Notes:

Pairing codes expire after ~1 hour, so approve fairly soon.
If pairing list telegram shows nothing, the request might have expired (just DM the bot again to generate a fresh one).

Docs: https://docs.openclaw.ai/channels/telegram (see “Start gateway and approve first DM”)

If what you mean by “worker” is “route Telegram to my worker agent (not main agent)”, tell me what agentId you want Telegram to use + paste your routing snippet (redact tokens), and I’ll point you to the right multi-agent routing config.

jolly finch Feb 14, 2026, 7:47 AM

#

@ashen fern I start loki gateway it shwoing this over and over closed before connect

and if i dile local dashboard
127.0.0.1:18789

show Disconnected from gateway.

ashen fernBOT Feb 14, 2026, 7:49 AM

#

127.0.0.1:18789 only works if the Gateway is running on the same machine as your browser.

If your Gateway is on your server (“loki”), and you open 127.0.0.1:18789 on your laptop, the UI will show “Disconnected from gateway” because there’s no gateway on your laptop.

Fix (recommended): SSH tunnel to loki

On your laptop, run (keep this terminal open):

ssh -N -L 18789:127.0.0.1:18789 <user>@<loki-host>

If you changed the gateway port on loki to e.g. 18888, then:

ssh -N -L 18789:127.0.0.1:18888 <user>@<loki-host>

#

Then open in your laptop browser:

http://127.0.0.1:18789/

Also: verify which port loki is actually using

On loki, run:

openclaw --version
openclaw gateway status
openclaw dashboard --no-open

openclaw dashboard --no-open prints the correct dashboard URL and usually includes an SSH hint.

About “closed before connect” repeating

That message typically happens when the UI/CLI is trying to connect to a host/port where the gateway isn’t reachable (wrong port, no tunnel, gateway not running, etc.).

#

If the tunnel setup above doesn’t fix it, paste the output of:

openclaw gateway status

(from loki) and I’ll tell you exactly what it’s failing on.

jolly finch Feb 14, 2026, 7:52 AM

#

@ashen fern main bot running in 18790

that is fine problem with worker gateway he is not running i try running the ssh it wont run what it will do is it for mac?

ashen fernBOT Feb 14, 2026, 7:52 AM

#

SSH tunneling is not Mac-only — it works on Linux/macOS/Windows (Windows either has built-in OpenSSH, or use WSL).

Also: you usually do not run a “worker gateway” as a second gateway.
OpenClaw architecture is:

1 Gateway (your main one on 18790)
optional worker machines = nodes (they connect to the gateway and can run terminal commands)

If your “worker” is another machine that should run terminal commands

On the worker machine, run a node host, not a gateway:

(If your gateway is only bound to loopback) make a tunnel from the worker → gateway
Run this on the worker machine (not on loki):

ssh -N -L 18791:127.0.0.1:18790 user@<gateway-host>

#

In a second terminal on the worker machine:

export OPENCLAW_GATEWAY_TOKEN="<gateway.auth.token from the gateway host>"  # don’t paste this in Discord
openclaw node run --host 127.0.0.1 --port 18791 --display-name "worker"

Back on the gateway host, approve the node pairing:

openclaw devices list
openclaw devices approve <requestId>

Docs:

Nodes overview: https://docs.openclaw.ai/nodes
Remote/tunnels: https://docs.openclaw.ai/gateway/remote

#

If your SSH “won’t run”

Tell me:

what OS are you running the SSH command on (Windows/macOS/Linux)?
what exact error text do you get when you run ssh -N -L ...?

(Just paste the error; don’t paste tokens.)

jolly finch Feb 14, 2026, 7:54 AM

#

@ashen fern I can't run main or worker agents gateway at the same time?

ashen fernBOT Feb 14, 2026, 7:55 AM

#

You can run two Gateways at the same time, but most people shouldn’t—because a single Gateway can run multiple agents, and “worker machines” are usually nodes, not a second gateway.

What you probably want (recommended)

1 Gateway + multiple agents

One Gateway process (your “main” on 18790)
Define a “worker” agent in config and route messages to it (multi-agent routing)
If the worker needs to run terminal commands on another machine, run a node host on that machine (not a gateway)

This avoids 90% of the pain.

If you really want 2 Gateways (yes, but isolate everything)

You must isolate config + state + ports (otherwise they collide):

different --profile (recommended)
different gateway.port (leave ~20 port gap)
different state dir + config path + workspace

#

Example:

openclaw --profile main gateway --port 18790
openclaw --profile rescue gateway --port 19790

Docs: https://docs.openclaw.ai/gateway/multiple-gateways

Important limitation

You generally should not connect the same Telegram bot token / Slack app / Discord bot to two gateways at once. They’ll fight for updates/events and you’ll get weird “connect/disconnect / no replies” behavior. If you run two gateways with channels, use separate bot tokens/apps.

If you tell me what your “worker” is supposed to do (separate agent logic? or run commands on another server?), I can point you to the right setup: multi-agent routing vs node host.

jolly finch Feb 14, 2026, 7:56 AM

#

@ashen fern how do i connect worker bot to same port them have them setup worker bot seperate telegram bot and everything

ashen fernBOT Feb 14, 2026, 7:58 AM

#

You can’t run two gateway processes on the same port (only one process can listen on 18790).

But you can run one Gateway on 18790 and connect multiple Telegram bots (separate bot tokens) to that same Gateway port, and route each bot to a different agent (“worker”) via bindings.

What you want: 1 Gateway (18790) + 2 Telegram bots + 2 agents

1) Create a worker agent

On the gateway host:

openclaw agents add worker

2) Configure Telegram with multiple accounts (two bot tokens)

Edit your ~/.openclaw/openclaw.json (JSON5) to something like:

#

  agents: {
    list: [
      { id: "main", default: true, workspace: "~/.openclaw/workspace" },
      { id: "worker", workspace: "~/.openclaw/workspace-worker" },
    ],
  },

  // Route each Telegram bot (accountId) to a different agent
  bindings: [
    { agentId: "main", match: { channel: "telegram", accountId: "default" } },
    { agentId: "worker", match: { channel: "telegram", accountId: "worker" } },
  ],

  channels: {
    telegram: {

#

      accounts: {
        default: { name: "Main bot", botToken: "123:MAIN_TOKEN" },
        worker:  { name: "Worker bot", botToken: "456:WORKER_TOKEN" },
      },

      // optional but common:
      dmPolicy: "pairing",
    },
  },
}

3) Restart the gateway

openclaw gateway restart

#

4) Pair/allow yourself for each bot

DM each Telegram bot once, get pairing code(s), then on gateway:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Key point

“Same port” = same Gateway
“Separate Telegram bot and everything” = separate Telegram accountId + separate agentId inside that one Gateway.

If you paste (redacting tokens) your current channels.telegram + bindings section, I can tell you exactly what to change for your setup.

jolly finch Feb 14, 2026, 8:01 AM

#

@ashen fern can my main agent remove other worker agent i have i want to setup new give me promot so my main agent can do it

ashen fernBOT Feb 14, 2026, 8:02 AM

#

Yes — your main agent can remove a worker agent, but the clean/safe way is via the CLI on the gateway host (because it edits config + moves the agent’s workspace/state to trash).

Recommended (manual, 2 commands)

On the machine where the Gateway runs:

openclaw agents list
openclaw agents delete <workerId>

Notes:

You cannot delete main.
agents delete will also remove that agent from config (bindings, etc.) and move its workspace/state/sessions to trash.

Afterwards, restart the gateway so everything reloads cleanly:

#

openclaw gateway restart

If you really want to tell your main agent to do it (prompt)

This only works if your main agent has exec enabled and you approve the command.

Copy/paste this to your main agent:

Run these commands on the gateway host and show me the output (don’t paste any tokens):

openclaw agents list

Delete the agent id <workerId> with: openclaw agents delete <workerId> --force

Then run: openclaw agents list --bindings to confirm it’s gone

Finally restart the gateway: openclaw gateway restart

If you tell me the worker agent id you want to remove (e.g. worker, work, etc.), I can tailor the exact commands.

jolly finch Feb 14, 2026, 8:07 AM

#

@ashen fern okay i removed all worker agents

so here is the goal give me guide how to create new worket agnet and connect them to a new telegram bot

and tlak to him seperate

ashen fernBOT Feb 14, 2026, 8:08 AM

#

Here’s the clean way to get a new worker agent that talks on its own Telegram bot, completely separate from your main bot — while still using the same Gateway port (18790).

0) Quick sanity check (on the gateway host)

openclaw --version
openclaw gateway status

1) Create a NEW Telegram bot (worker) in BotFather

In Telegram → chat with @BotFather:

/newbot
copy the bot token (keep it secret)

You should now have:

Main bot token (already working)
Worker bot token (new)

#

2) Add a new agent (“worker”)

On the gateway host:

openclaw agents add worker

Then confirm it exists:

openclaw agents list --bindings

3) Configure Telegram for multi-account (two bot tokens)

Edit your config (~/.openclaw/openclaw.json, JSON5) so Telegram has accounts:

Example:

#

{
  agents: {
    list: [
      { id: "main", default: true },
      { id: "worker" },
    ],
  },

  channels: {
    telegram: {
      enabled: true,

      // two separate Telegram bots:
      accounts: {
        default: {

#

          name: "Main bot",
          botToken: "123:MAIN_TOKEN",
        },
        worker: {
          name: "Worker bot",
          botToken: "456:WORKER_TOKEN",
        },
      },

      dmPolicy: "pairing",
    },
  },

  // Route each Telegram bot (accountId) to a different agent:
  bindings: [

#

    { agentId: "main", match: { channel: "telegram", accountId: "default" } },
    { agentId: "worker", match: { channel: "telegram", accountId: "worker" } },
  ],
}

Important notes:

Don’t paste tokens in Discord.
If you previously had channels.telegram.botToken: "...", move it into accounts.default.botToken.

4) Restart the gateway

openclaw gateway restart

5) Pair yourself in DMs (so each bot will respond)

#

DM the main Telegram bot → you’ll get a pairing code
DM the worker Telegram bot → you’ll get a pairing code

Then on gateway host:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

(Repeat until both are approved.)

6) Talk to them separately

DM Main bot → routes to agent main
DM Worker bot → routes to agent worker

#

If you paste (redacting tokens) your current channels.telegram + bindings section, I can tell you exactly what to edit so you don’t accidentally break the main bot.

jolly finch Feb 14, 2026, 8:20 AM

#

@ashen fern how do i config exists
made a new worker agent call jax
Now can you make a promot for my main agent to fix everything buinding to all. then temegram config for new bot

ashen fernBOT Feb 14, 2026, 8:21 AM

#

Paste this prompt to your main agent (on your gateway host). It tells it exactly what to do to route your new agent jax to a new Telegram bot, without breaking your existing main bot.

Prompt for your main agent

You are running on the OpenClaw gateway host. Goal:

I already created a new agent: jax
I created a new Telegram bot token for jax (separate from the main bot)
I want:
- Telegram main bot → routes to agent main
- Telegram jax bot → routes to agent jax
Keep Telegram DMs safe with dmPolicy: "pairing".

Do this step-by-step, and ask me for any missing info. Do not paste tokens back into chat.

#

Show current agent + bindings status:

openclaw agents list --bindings

Confirm agent id jax exists.

Inspect current Telegram config:

openclaw config get channels.telegram
openclaw config get bindings

Configure Telegram for multi-account. Ensure we have:

#

channels.telegram.accounts.default.botToken = the existing main bot token (from current config)
channels.telegram.accounts.jax.botToken = my new jax token (I will provide it)
channels.telegram.dmPolicy = "pairing"

If the config currently uses channels.telegram.botToken (single-account), migrate it into channels.telegram.accounts.default.botToken. After migration, remove the old single key:

openclaw config unset channels.telegram.botToken

Update bindings (preserve any non-telegram bindings!). Ensure these exist:

{ agentId: "main", match: { channel: "telegram", accountId: "default" } }
{ agentId: "jax",  match: { channel: "telegram", accountId: "jax" } }

#

Most-specific wins, but these two should be present.

Restart gateway:

openclaw gateway restart

Verify Telegram is healthy:

openclaw channels status --probe
openclaw pairing list telegram

Tell me to DM both Telegram bots once, then approve the pairing code(s) that appear:

#

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Stop when both bots reply correctly and DMs to each bot go to the right agent.

If you want, paste (redacting tokens) your current channels.telegram and bindings sections here and I’ll tell you exactly what the final JSON5 should look like.

jolly finch Feb 14, 2026, 8:24 AM

#

@ashen fern

ask for the token also says this my main bot

Now my reply will be give the token and help me write promot to help main bot

Current bindings: Empty array []

So I need to create the bindings from scratch.

Ready for your jax bot token.

Once you provide it, I'll:

Add jax account to channels.telegram.accounts
Create bindings for main → main and jax → jax
Restart gateway
Verify
Paste the token when ready 🔧

ashen fernBOT Feb 14, 2026, 8:24 AM

#

Don’t paste the Telegram bot token in Discord (it’s basically a password). Put it directly into config on the gateway host (loki), or paste it only into your local terminal when the agent asks.

Safest way to give the token (on loki)

Run this on the gateway machine:

openclaw config set channels.telegram.accounts.jax.botToken "<JAX_BOT_TOKEN>"
openclaw gateway restart

(Quotes matter; keep the token secret.)

Then DM the new bot once and approve pairing:

openclaw pairing list telegram

#

openclaw pairing approve telegram <CODE>

Prompt for your main agent (token-safe)

Copy/paste this to your main bot:

Goal: route a new Telegram bot to agent jax without breaking my main Telegram bot.
Do not ask me to paste any bot token into chat. If you need the token, instruct me to run an openclaw config set ... command on the gateway host myself.

Steps:

Show current state:

openclaw agents list --bindings

openclaw config get channels.telegram

openclaw config get bindings

Ensure Telegram is multi-account:

If channels.telegram.botToken exists, migrate it into channels.telegram.accounts.default.botToken and then openclaw config unset channels.telegram.botToken.

#

Ensure these accounts exist:

channels.telegram.accounts.default (main bot)

channels.telegram.accounts.jax (new bot)
And set channels.telegram.dmPolicy to "pairing".

Ensure bindings include (and don’t delete other bindings):

{ agentId: "main", match: { channel: "telegram", accountId: "default" } }

{ agentId: "jax", match: { channel: "telegram", accountId: "jax" } }

Tell me exactly which openclaw config set ... commands to run for the new bot token, then restart gateway:

openclaw gateway restart

Verify:

openclaw channels status --probe

Pairing approve flow for the new bot.

If you paste your current (redacted) channels.telegram + bindings output here, I can tell you the exact final config shape and the exact openclaw config set ... commands (without needing your token in chat).

jolly finch Feb 14, 2026, 8:37 AM

#

@ashen fern It's not working

I dm but no pairing code come can you make a promot to check everything. and run the worker jex to run on new temegram bot

ashen fernBOT Feb 14, 2026, 8:38 AM

#

If you DM the new Telegram bot and you get no pairing code at all, that usually means the new bot account isn’t actually connected/working (wrong token, not loaded, gateway not restarted, or Telegram channel not running), not a pairing problem.

Here’s a pasteable prompt for your main agent to check everything end-to-end and make sure agent jax (you wrote jex—confirm which id) is routed to the new Telegram bot account.

Prompt to paste to your main agent

Goal: Make new agent jax talk on a new Telegram bot (separate token), with DM pairing working. Diagnose why DMs to the new bot produce no pairing code.

Rules:

Run commands on the gateway host.
Do not print any tokens. If a command output contains a token, redact it.
Ask me before making destructive changes.

Steps:

#

Confirm agent + bindings:

openclaw agents list --bindings

Verify the agent id is exactly jax (or tell me what it is).
Verify there is a binding that routes Telegram accountId jax to agentId jax.

Confirm Telegram accounts are configured (multi-account):

openclaw config get channels.telegram
openclaw config get bindings

Check that channels.telegram.accounts contains:

#

default (main bot)
jax (new bot)

Also verify channels.telegram.dmPolicy is "pairing" (either globally or for the jax account).

Confirm the gateway actually loaded the config and Telegram is running:

openclaw status
openclaw channels list
openclaw channels status --probe

Look specifically for Telegram + whether it shows both accounts and “ready/connected”. If --probe isn’t supported on this build, use:

#

openclaw status --deep

Check pairing state and whether requests are being created:

openclaw pairing list telegram

If there are already 3 pending requests (cap), tell me (pairing codes won’t be created for new senders until one expires/approved).

Tail logs while I DM the NEW bot (this is key):

openclaw logs --follow

#

Tell me what you see when I send a normal text message (not just /start) to the new bot:

Do we see any inbound Telegram update at all?
Any errors like 401, Unauthorized, botToken invalid, network/DNS issues, etc?

If the new bot isn’t receiving updates:

Conclude whether it’s a token/config/restart issue.
Tell me the exact safe command I should run to set the token on the gateway host (I will run it myself), like:

openclaw config set channels.telegram.accounts.jax.botToken "<TOKEN>"
openclaw gateway restart

Once inbound updates work, verify routing:

DM main bot → should hit agent main
DM jax bot → should hit agent jax

#

Two quick gotchas (common)

/start alone doesn’t always create a pairing code. Send a normal text like “hi”.
Pairing code only sends when a new pairing request is created (and requests expire ~1h; max pending ~3).

If you can paste the output of these two commands (redact tokens) I can tell you what’s wrong immediately:

openclaw agents list --bindings
openclaw config get channels.telegram

jolly finch Feb 14, 2026, 8:51 AM

#

@ashen fern It's not working i setup new working bot jax

and ask my main bot to check everything still dm not working no pairing code coming up. can you make promot and check what's going or or ask me before to check stuff before making the promot

ashen fernBOT Feb 14, 2026, 8:52 AM

#

Before I write another “big prompt”, I need 2 minutes of hard facts — because “no pairing code” can mean (a) the gateway never receives the DM, (b) it receives it but drops it (policy), or (c) Telegram polling is broken (409 conflict / webhook / wrong token).

Please answer these + run these checks on the gateway host (loki). Don’t paste any tokens.

A) Quick questions

Does your main Telegram bot still reply normally right now?
When you DM the jax bot, are you sending a normal text like hi (not only /start)?
Are you 100% sure the jax bot token isn’t used by any other server/app right now? (If another process is polling that token, OpenClaw won’t see updates.)

B) Commands to run (paste output, redact secrets)

openclaw --version
openclaw gateway status
openclaw channels list
openclaw channels status --probe
openclaw pairing list telegram

#

What I’m looking for:

channels status --probe should show Telegram is “ready/connected” and ideally show both accounts (default + jax) without errors.
pairing list telegram — if you already have 3 pending requests, Telegram pairing won’t create new ones.

C) The most important test: logs while you DM the jax bot

Run:

openclaw logs --follow

While that’s running, DM the jax bot the text: hi
Copy/paste the Telegram-related log lines that appear right then.

If there are no log lines at all when you DM jax, the gateway is not receiving Telegram updates for that bot (usually wrong token, account not loaded, or Telegram conflict).

Common smoking guns you might see in logs:

401 Unauthorized → wrong token
409 Conflict / “webhook is active” / “terminated by other getUpdates request” → token is being used elsewhere or webhook mode is set somewhere

#

Once you paste those outputs (especially the probe + the log snippet), I’ll give you a precise “prompt for main agent” and the exact fix steps for the jax Telegram bot.

jolly finch Feb 14, 2026, 9:13 AM

#

@ashen fern okay i run out of token on openchalw change api restart still say using gemini how do i remove other model and keep on api for the main bot?

#

@ashen fern ?

ashen fernBOT Feb 14, 2026, 9:19 AM

#

I need the outputs to tell where it’s failing — otherwise I’m guessing.

On the gateway host (loki) run these and paste the output here (redact tokens):

openclaw --version
openclaw gateway status
openclaw channels status --probe   # if this errors, run: openclaw status --deep
openclaw pairing list telegram

Then do this test:

In one terminal on loki:

openclaw logs --follow

#

While that’s running, DM your jax Telegram bot the text: hi
Paste the Telegram-related log lines that appear right when you send hi.

If no logs appear at all, the gateway isn’t receiving updates for that bot (usually wrong token, webhook/conflict, or the account isn’t loaded). If logs show 401 or 409 conflict, that’s the smoking gun.

jolly finch Feb 14, 2026, 9:22 AM

#

@ashen fern how do i remove other api key from main bot and only use kimi in it

ashen fernBOT Feb 14, 2026, 9:24 AM

#

To make your main agent use only Kimi (and stop using other providers), you need to do two things:

Select Kimi as the only model (primary + no fallbacks)
Remove/disable other credentials (optional, for cleanup/security)

Also: don’t paste any API keys/tokens in Discord.

1) Force main agent to only use Kimi

First, decide which “Kimi” you mean:

Moonshot Kimi provider: moonshot/... (uses MOONSHOT_API_KEY)
Kimi Coding provider: kimi-coding/... (uses KIMI_API_KEY)

On the gateway host:

#

openclaw models status --agent main

Then set Kimi as the default model (pick ONE):

openclaw models set moonshot/kimi-k2.5
# or:
openclaw models set kimi-coding/k2p5

Now remove fallbacks so it won’t fail over to Anthropic/OpenAI/etc:

openclaw models fallbacks clear

#

openclaw models image-fallbacks clear

Restart:

openclaw gateway restart

2) Remove other API keys (cleanup)

OpenClaw can store creds in two places:

A) Config `env` block (easy to remove)

Check what’s in config:

#

openclaw config get env

If you see keys you don’t want (examples: OPENAI_API_KEY, ANTHROPIC_API_KEY, OPENROUTER_API_KEY), remove them:

openclaw config unset env.OPENAI_API_KEY
openclaw config unset env.ANTHROPIC_API_KEY
openclaw config unset env.OPENROUTER_API_KEY
openclaw gateway restart

B) Auth profiles file (if you used `openclaw models auth ...`)

Those live per-agent here (for main agent):
~/.openclaw/agents/main/agent/auth-profiles.json

#

There isn’t a nice “remove auth profile” CLI yet; you’d edit that file and delete the profiles/providers you don’t want (careful: it contains secrets). After editing, restart the gateway.

If you tell me which Kimi you’re using

Reply with one line:

moonshot or kimi-coding

…and paste (redacting values) the output of:

openclaw models status --agent main
openclaw config get env

…and I’ll tell you exactly which config unset lines you should run for your case.

jolly finch Feb 14, 2026, 9:30 AM

#

@ashen fern it says using

model: moonshot/kimi-k2.5 │
│ gateway.mode: local │
│ gateway.port: 18790 │
│ gateway.bind: loopback │
│ skills.nodeManager: npm

but giving me
404 No endpoints found for google/gemini-2.0-flash-exp:free.

that is from openrouter

how do i set to kimi?

ashen fernBOT Feb 14, 2026, 9:30 AM

#

You are set to Kimi as the primary model already (moonshot/kimi-k2.5).
That 404 ... google/gemini-2.0-flash-exp:free (from openrouter) means OpenClaw is still trying OpenRouter somewhere — usually because of fallbacks, an image model, or a session override.

Do this on the gateway host:

1) Check what it’s actually trying (main agent)

openclaw models status --agent main
openclaw models fallbacks list
openclaw models image-fallbacks list

2) Force only Kimi (remove OpenRouter fallbacks)

openclaw models set moonshot/kimi-k2.5
openclaw models fallbacks clear

#

openclaw models image-fallbacks clear
openclaw gateway restart

3) If it still happens: you probably have a session override

In the chat where you saw the error, run:

/model status
then set it back:
- /model moonshot/kimi-k2.5

4) Important gotcha: images

If you send an image, and Kimi doesn’t support images in your setup, OpenClaw will use the image model (often configured as OpenRouter/Gemini). That can trigger the OpenRouter 404 even when your text model is Kimi.

If you want, paste (redacting secrets) the output of:

#

openclaw models status --agent main
openclaw models fallbacks list
openclaw models image-fallbacks list

…and tell me whether you were sending an image when the error happened. I’ll tell you exactly which setting is pulling OpenRouter in.

jolly finch Feb 14, 2026, 9:33 AM

#

@ashen fern now giving new error the api i gave it's new have limits why it showing this now

Agent failed before reply: All models failed (2): kimi-coding/k2p5: Provider kimi-coding is in cooldown (all profiles unavailable) (rate_limit) | moonshot/kimi-k2.5: Provider moonshot is in cooldown (all profiles unavailable) (rate_limit).
Logs: openclaw logs --follow

ashen fernBOT Feb 14, 2026, 9:35 AM

#

That message means you hit the provider’s rate limit / quota, and OpenClaw is doing the right thing: it puts the provider into a temporary cooldown so it doesn’t keep hammering the API and get you locked out harder.

Because both of your configured models are Kimi providers:

kimi-coding/k2p5 → in cooldown (rate_limit)
moonshot/kimi-k2.5 → in cooldown (rate_limit)

…OpenClaw has nothing left to try, so you get: “All models failed”.

What to do (in order)

1) Stop sending messages for a bit (cooldown backoff)

Cooldown uses exponential backoff (1m → 5m → 25m → 1h). If you keep retrying immediately, you’ll usually just extend the pain.

To see how long it’s cooling down, run on the gateway host:

#

openclaw models status --json --agent main

Look for auth.unusableProfiles / cooldownUntil timestamps (this tells you when it will try again).

(You can also tail logs to confirm it’s a 429/rate-limit response:)

openclaw logs --follow

2) Pick ONE Kimi provider as primary (optional but recommended)

If you want “only Kimi”, pick either moonshot or kimi-coding as the primary, and clear fallbacks so it doesn’t bounce between them:

openclaw models set moonshot/kimi-k2.5

#

# OR:
openclaw models set kimi-coding/k2p5

openclaw models fallbacks clear
openclaw models image-fallbacks clear
openclaw gateway restart

This won’t fix the rate limit by itself, but it removes extra attempts.

3) Real fix: increase limits or add a fallback

If your Kimi key is new / low tier, you have 3 options:

Upgrade / add billing / raise quota on Moonshot/Kimi.
Add another key/profile (so OpenClaw can rotate when one is rate-limited).
Add a non-Kimi fallback model so the bot keeps replying when Kimi is cooling down (you can choose one from openclaw models list or /model list).

#

If you tell me which Kimi you want to keep as primary (moonshot or kimi-coding), I’ll give you the exact minimal commands for that setup + a safe fallback plan.

jolly finch Feb 14, 2026, 9:46 AM

#

@ashen fern i have 6 fallback setup how do i remove those myself

ashen fernBOT Feb 14, 2026, 9:46 AM

#

Remove them with the models CLI (easiest), then restart.

On the gateway host:

1) See what fallbacks are configured

openclaw models fallbacks list
openclaw models image-fallbacks list

2) Remove all fallbacks (fast)

openclaw models fallbacks clear
openclaw models image-fallbacks clear
openclaw gateway restart

#

3) Or remove just one fallback (repeat per model)

openclaw models fallbacks remove <provider/model>
openclaw models image-fallbacks remove <provider/model>

If they still “come back”

Then they’re probably also set directly in config under agents.defaults.model.fallbacks. Check:

openclaw config get agents.defaults.model

If you see a fallbacks list there, unset it (or set it to an empty list):

#

openclaw config unset agents.defaults.model.fallbacks
# or:
openclaw config set agents.defaults.model.fallbacks "[]" --json
openclaw gateway restart

If you paste your openclaw models fallbacks list output (no secrets), I can tell you exactly which command(s) to run.

jolly finch Feb 14, 2026, 10:12 AM

#

@ashen fern how do i rest my main bot model api key just want to remove all other model api key and run the new api from kimi only

ashen fernBOT Feb 14, 2026, 10:13 AM

#

If you want your main agent to use only Kimi and remove every other provider key, you need to clean up 3 places where credentials/models can come from:

Model selection + fallbacks
Config env / models.providers
Stored auth profiles (auth-profiles.json)

Don’t paste any keys here.

0) Pick which Kimi you want (choose ONE)

Moonshot Kimi: model moonshot/kimi-k2.5 → keep MOONSHOT_API_KEY
Kimi Coding: model kimi-coding/k2p5 → keep KIMI_API_KEY

(You can keep both, but then you’re still using two providers and you’ll hit cooldown failover like you saw.)

#

1) Force main to only use that model (remove all fallbacks)

On the gateway host:

openclaw models set moonshot/kimi-k2.5
# OR:
openclaw models set kimi-coding/k2p5

openclaw models fallbacks clear
openclaw models image-fallbacks clear

Restart:

openclaw gateway restart

#

2) Remove other API keys from config (keep ONLY the Kimi one)

See what you currently have:

openclaw config get env

Then remove everything you don’t want (examples):

openclaw config unset env.OPENAI_API_KEY
openclaw config unset env.ANTHROPIC_API_KEY
openclaw config unset env.OPENROUTER_API_KEY
openclaw config unset env.GEMINI_API_KEY

#

openclaw config unset env.GOOGLE_API_KEY
openclaw config unset env.ZAI_API_KEY
openclaw config unset env.MINIMAX_API_KEY

Make sure you do not unset the one you actually need:

keep env.MOONSHOT_API_KEY if using moonshot/...
keep env.KIMI_API_KEY if using kimi-coding/...

Restart again:

openclaw gateway restart

Also check custom providers (optional)

#

If you added other providers under models.providers, remove them:

openclaw config get models.providers

Then e.g.:

openclaw config unset models.providers.openrouter
openclaw config unset models.providers.anthropic
openclaw config unset models.providers.openai
# keep models.providers.moonshot if you’re using moonshot

Restart:

#

openclaw gateway restart

3) Remove stored auth profiles (this is where “other keys” often hide)

Main agent auth profiles live here on the gateway host:

~/.openclaw/agents/main/agent/auth-profiles.json

There’s no “delete auth profile” CLI yet — so you edit the file and remove the profiles for providers you don’t want (OpenAI/Anthropic/OpenRouter/etc).

Do a backup first:

#

cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/main/agent/auth-profiles.backup.json

Then edit:

nano ~/.openclaw/agents/main/agent/auth-profiles.json

After editing, restart:

openclaw gateway restart

#

Verify it’s really only Kimi now

openclaw models status --agent main

If you paste the output of openclaw config get env with values redacted (just show which keys exist), I can tell you exactly which config unset ... lines to run for your setup.

jolly finch Feb 14, 2026, 10:21 AM

#

@ashen fern why this become complicated

it's saything this now!

⚠️ Agent failed before reply: All models failed (4): kimi-coding/k2p5: Provider kimi-coding is in cooldown (all profiles unavailable) (rate_limit) | moonshot/kimi-k2-0905-preview: Provider moonshot is in cooldown (all profiles unavailable) (rate_limit) | minimax/MiniMax-M2.5: Provider minimax is in cooldown (all profiles unavailable) (rate_limit) | moonshot/kimi-k2.5: Provider moonshot is in cooldown (all profiles unavailable) (rate_limit).
Logs: openclaw logs --follow

I think it pulling from old api new api not getting used

ashen fernBOT Feb 14, 2026, 10:22 AM

#

It’s not “pulling the old API key” — that error is telling you something else:

What’s actually happening

You’re hitting rate limits (429 / quota) on the providers you configured.
OpenClaw then marks that provider/profile as in cooldown (so it stops retrying and burning requests).
Because every model in your list is now in cooldown, you get “All models failed”.

So the fix is: (1) stop it from trying extra models, and (2) let cooldown expire (or reset cooldown state).

1) Make it use ONLY one Kimi model (remove those other models from the chain)

On the gateway host, run:

openclaw models fallbacks list

#

openclaw models image-fallbacks list

Then clear them:

openclaw models fallbacks clear
openclaw models image-fallbacks clear

Now set exactly one primary (pick ONE and stick to it):

openclaw models set moonshot/kimi-k2.5
# (or if you prefer kimi-coding)

#

# openclaw models set kimi-coding/k2p5

Restart:

openclaw gateway restart

If you still see MiniMax / other Kimi preview models being tried after this, they are still configured in config. Check:

openclaw config get agents.defaults.model

If it contains fallbacks: [...], delete/empty it:

#

openclaw config unset agents.defaults.model.fallbacks
# or:
openclaw config set agents.defaults.model.fallbacks "[]" --json
openclaw gateway restart

2) Confirm what’s in cooldown + how long

Run:

openclaw models status --json --agent main

Look for auth.unusableProfiles / cooldownUntil. That tells you when it will work again.

#

(If you keep spamming messages during cooldown, it often just gets worse.)

3) If you want to “reset” cooldown immediately (manual, optional)

Cooldown state is stored in:

~/.openclaw/agents/main/agent/auth-profiles.json

If you delete the usageStats section (or the entries for moonshot/kimi/minimax), you clear cooldown bookkeeping.

Do not paste this file in Discord. Do this on the gateway host:

cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/main/agent/auth-profiles.backup.json
nano ~/.openclaw/agents/main/agent/auth-profiles.json

#

openclaw gateway restart

Then try again slowly.

One question that matters

Are you using Moonshot Kimi (moonshot/...) or Kimi Coding (kimi-coding/...) as the one true provider? Pick one; if you try to keep both, you’ll just bounce between two rate limits.

If you paste the output of these (no secrets):

openclaw models fallbacks list
openclaw config get agents.defaults.model

…I’ll tell you exactly why MiniMax + the preview Kimi model are still being attempted.

jolly finch Feb 14, 2026, 10:25 AM

#

@ashen fern okay fallback list is showing 0

still i get this message

⚠️ Agent failed before reply: All models failed (2): kimi-coding/k2p5: Provider kimi-coding is in cooldown (all profiles unavailable) (rate_limit) | moonshot/kimi-k2.5: Provider moonshot is in cooldown (all profiles unavailable) (rate_limit).
Logs: openclaw logs --follow

ashen fernBOT Feb 14, 2026, 10:26 AM

#

Fallbacks being 0 is good — but this error isn’t about config anymore. It means both providers are rate-limited right now, so OpenClaw put them into cooldown and refuses to try them until the cooldown expires:

kimi-coding/k2p5 … cooldown … (rate_limit)
moonshot/kimi-k2.5 … cooldown … (rate_limit)

That also strongly suggests your new API key is being used: if the key was wrong you’d usually see 401/unauthorized, not rate_limit.

What to do next

1) See how long the cooldown is

Run this on the gateway host:

openclaw models status --json --agent main

Look for auth.unusableProfiles and cooldownUntil (it’ll show a timestamp). That tells you when it should start working again.

#

Then… wait until that time, and don’t spam messages (spamming tends to keep you rate-limited).

2) Make sure it’s only trying ONE of the two Kimi providers (optional)

Right now it’s trying both kimi-coding and moonshot. If you want “Kimi only”, pick one:

openclaw models set moonshot/kimi-k2.5
# or:
openclaw models set kimi-coding/k2p5
openclaw gateway restart

(You already cleared fallbacks, so after this it should only try one model once the cooldown ends.)

3) Emergency: clear cooldown state (only if you really need to)

Cooldown state is stored locally in:

#

~/.openclaw/agents/main/agent/auth-profiles.json

You can clear it by removing the usageStats entries (this does not change your API key, it just resets the “cooldown” bookkeeping). Do a backup first:

cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/main/agent/auth-profiles.backup.json
nano ~/.openclaw/agents/main/agent/auth-profiles.json
openclaw gateway restart

If you do this and the provider is actually still rate-limiting you, it’ll just immediately re-enter cooldown again.

If you paste the output of only this (safe, no secrets):

#

openclaw models status --agent main

…I can tell you whether it’s going to recover in 1 minute vs 1 hour, and which provider is the real bottleneck.

jolly finch Feb 14, 2026, 12:02 PM

#

@ashen fern how i check whihc api i am using

ashen fernBOT Feb 14, 2026, 12:02 PM

#

You can check which API/provider/key is being used in 3 practical ways (without exposing the key).

1) Check the resolved provider + model (what it intends to use)

On the gateway host:

openclaw models status --agent main

This shows the active model (e.g. moonshot/kimi-k2.5) and configured providers.

2) See which provider is actually being called (logs)

This is the best “truth”.

openclaw logs --follow

#

Then send one message. In the logs you’ll see which provider/model was attempted and the error (rate_limit, etc.).
It won’t print the full key, but it tells you moonshot vs kimi-coding vs openrouter etc.

3) See where the key is coming from (env vs auth profiles vs models.providers)

On the gateway host:

A) Config env keys (you’ll see which variables exist)

openclaw config get env

Look for things like MOONSHOT_API_KEY, KIMI_API_KEY, OPENROUTER_API_KEY, etc. (Don’t paste the values.)

B) Stored auth profiles (keys saved by `models auth …`)

File location for main agent:

ls -la ~/.openclaw/agents/main/agent/auth-profiles.json

#

(Do not paste contents; it contains secrets.)

What I need from you (safe)

Paste the output of these two commands (values redacted if any show up):

openclaw models status --agent main
openclaw config get env

Then I can tell you exactly which provider/key source OpenClaw is using.

jolly finch Feb 14, 2026, 12:03 PM

#

@ashen fern how do i replace from json

ashen fernBOT Feb 14, 2026, 12:03 PM

#

Which JSON are you talking about—your OpenClaw config (~/.openclaw/openclaw.json / JSON5), or auth-profiles.json?

If you mean “replace a value in openclaw.json”

Best/safest is to use the CLI (no manual editing needed):

Replace Moonshot (Kimi) API key in config:

openclaw config set env.MOONSHOT_API_KEY "<NEW_KEY>"
openclaw gateway restart

Replace Kimi-Coding API key:

openclaw config set env.KIMI_API_KEY "<NEW_KEY>"
openclaw gateway restart

#

Remove another provider key (example OpenRouter):

openclaw config unset env.OPENROUTER_API_KEY
openclaw gateway restart

Notes:

Don’t paste keys into Discord.
openclaw config set treats values as strings by default; use --json only when setting arrays/objects.

If you mean “edit the file directly”

On the gateway host:

nano ~/.openclaw/openclaw.json

Change the value, save, then:

#

openclaw gateway restart

Tell me exactly which key/path you want to replace (e.g. env.MOONSHOT_API_KEY, channels.telegram.accounts.jax.botToken, etc.) and I’ll give you the exact command.

jolly finch Feb 14, 2026, 12:06 PM

#

@ashen fern this is what i see in json

"models": {
"mode": "merge",
"providers": {
"moonshot": {
"baseUrl": "https://api.moonshot.ai/v1",
"api": "openai-completions",
"models": [
{
"id": "kimi-k2-0905-preview",
"name": "Kimi K2 0905 Preview",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 256000,
"maxTokens": 8192
},
{
"id": "kimi-k2.5",
"name": "Kimi K2.5",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 256000,
"maxTokens": 8192
}
]
},

ashen fernBOT Feb 14, 2026, 12:08 PM

#

What you pasted is just the model catalog for the moonshot provider (baseUrl + which model IDs exist). The API key usually is NOT stored there unless you add it — it’s typically coming from either:

auth-profiles.json (if you used openclaw models auth …)
env (MOONSHOT_API_KEY / KIMI_API_KEY)
models.providers.<provider>.apiKey (optional)

Recommended: replace the Moonshot key via CLI (safest)

On the gateway host:

openclaw models auth paste-token --provider moonshot --profile-id moonshot:default

It will prompt you to paste the new key (don’t paste it in Discord), then:

#

openclaw gateway restart

If you really want it “in JSON config”

Add apiKey to that provider, and set the env var (either in config or real shell env):

Config (JSON5) idea:

env: { MOONSHOT_API_KEY: "sk-..." }, // keep secret
models: {
  providers: {
    moonshot: {
      baseUrl: "https://api.moonshot.ai/v1",
      apiKey: "${MOONSHOT_API_KEY}",
      api: "openai-completions",

#

      models: [ ... ]
    }
  }
}

Or using CLI (note the single quotes to prevent $ expansion):

openclaw config set models.providers.moonshot.apiKey '${MOONSHOT_API_KEY}'
openclaw config set env.MOONSHOT_API_KEY "<NEW_KEY>"
openclaw gateway restart

Why you still see two models tried (kimi-coding + moonshot) even with 0 fallbacks

That usually happens when your current chat session is still set to /model kimi-coding/k2p5 (session override). When it fails, OpenClaw then tries the default model (moonshot).

#

Fix in the chat:

run /model moonshot/kimi-k2.5
or start fresh with /new.

Verify which provider is actually being hit

openclaw logs --follow

Send one message; logs will show whether it tried moonshot or kimi-coding and why it failed (rate_limit, etc.).

If you paste (redacting secrets) your openclaw config get models.providers and openclaw config get env output, I can tell you exactly where the key is coming from right now.

jolly finch Feb 14, 2026, 12:13 PM

#

@ashen fern my full api flow is massed up don't know how to fix it now

ashen fernBOT Feb 14, 2026, 12:14 PM

#

If your API/model setup feels “messed up”, the fastest way out is to get back to a known-good minimal state, then add things back one at a time.

Right now your errors are mostly rate_limit → cooldown, which means OpenClaw is reaching the providers, but they’re refusing requests (quota/limits), so OpenClaw backs off.

Step 1: Get a clean diagnosis (safe to paste)

Run these on the gateway host and paste the output here (don’t paste any keys):

openclaw status --all
openclaw models status --json --agent main
openclaw config get env
openclaw config get agents.defaults.model

That tells us:

what model is actually primary
whether there are hidden fallbacks/image models

#

which providers have credentials configured
which profiles are in cooldown + until when

Step 2: Decide the ONE provider you want (otherwise you’ll keep bouncing)

Pick one and tell me which:

Moonshot Kimi: moonshot/kimi-k2.5 (uses MOONSHOT_API_KEY / moonshot token)
Kimi Coding: kimi-coding/k2p5 (uses KIMI_API_KEY)

If you keep both configured, when one hits rate limits it will try the other, then both end up in cooldown (what you’re seeing).

Step 3: Minimal “only Kimi” reset (non-destructive)

On the gateway host:

openclaw models fallbacks clear

#

openclaw models image-fallbacks clear
openclaw models set moonshot/kimi-k2.5   # or kimi-coding/k2p5
openclaw gateway restart

Then in the chat/UI session that’s failing, do:

/new
/model moonshot/kimi-k2.5 (or /model kimi-coding/k2p5)

(Session overrides are a super common reason it “keeps trying the other one”.)

Step 4: If you want a “hard reset” of old stored API keys (optional)

Only do this if you’re OK losing stored model creds (reversible via backup):

#

cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/main/agent/auth-profiles.backup.json
mv ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/main/agent/auth-profiles.json.disabled
openclaw gateway restart

Then re-add just your one Kimi key via:

openclaw models auth paste-token --provider moonshot --profile-id moonshot:default
# (or --provider kimi-coding if that’s what you use)

Do not paste the token into Discord; paste it into the CLI prompt.

#

Send me the output from Step 1 + tell me which one you want (moonshot or kimi-coding), and I’ll tell you the exact minimal set of keys to keep/remove and why you’re still seeing cooldown.

jolly finch Feb 14, 2026, 12:17 PM

#

@ashen fern okay so the limit from old account and i hadd new account api from config still it shows this new account api don't getting used.

is there way i can remove all other model and just use new model only?

unborn turret Feb 14, 2026, 12:17 PM

#

I’m running OpenClaw v2026.2.13 on a VPS. I get ‘Unsupported channel: telegram’ and ‘Unsupported channel: whatsapp’ errors. How can I enable chat/messaging channels? Is there a public plugin or new release?

ashen fernBOT Feb 14, 2026, 12:18 PM

#

Yeah — this is fixable, and what you’re seeing is a very specific thing:

Why the “old account” keeps getting used

OpenClaw uses credentials in this order:

auth profiles (stored keys) → env keys in config → models.providers.*.apiKey

So if you ever added Moonshot/Kimi via openclaw models auth …, that stored key wins, even if you put a “new key” into config.

Also: if the profile is in cooldown, OpenClaw will keep saying cooldown until it expires (even if you changed the key), unless you clear that cooldown state or use a new profile id.

Goal: use ONLY your new Moonshot key + ONLY one model

Do this on the gateway host.

1) Set ONLY one model (remove the second one being tried)

#

Pick ONE and stick to it (I’m assuming Moonshot):

openclaw models set moonshot/kimi-k2.5
openclaw models fallbacks clear
openclaw models image-fallbacks clear

Then in the chat you’re testing from: do /new (session overrides can keep pulling the other model).

2) Replace the stored Moonshot key (the one that actually “wins”)

This overwrites the old key in the auth store:

openclaw models auth paste-token --provider moonshot --profile-id moonshot:default

#

Paste your new Moonshot key when it prompts (don’t paste it in Discord).

3) Clear the cooldown immediately (optional but usually needed)

If you keep the same profile id (moonshot:default), the old cooldown timer may still be set. Easiest clean reset:

cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/main/agent/auth-profiles.backup.json
nano ~/.openclaw/agents/main/agent/auth-profiles.json

In that file, remove the usageStats entry for moonshot:default (or just delete the whole usageStats block). Save.

4) Restart

openclaw gateway restart

#

5) Verify which provider/model it’s using

openclaw models status --agent main
openclaw logs --follow

Send one test message and watch logs — it should show moonshot/kimi-k2.5 attempts.

If you want to “remove all other model API keys”

After the above works, you can also remove other keys from config env:

openclaw config get env
# then unset the ones you don't want, e.g.
openclaw config unset env.OPENROUTER_API_KEY

#

openclaw config unset env.OPENAI_API_KEY
openclaw config unset env.ANTHROPIC_API_KEY
openclaw gateway restart

If you paste the output of openclaw models status --agent main (no secrets), I can tell you exactly whether you still have multiple profiles/models active and what it will try next.

unborn turret Feb 14, 2026, 12:18 PM

#

@ashen fern I’m running OpenClaw v2026.2.13 on a VPS. I get ‘Unsupported channel: telegram’ and ‘Unsupported channel: whatsapp’ errors. How can I enable chat/messaging channels? Is there a public plugin or new release?

ashen fernBOT Feb 14, 2026, 12:20 PM

#

That error means the channel plugin isn’t loaded (so OpenClaw literally doesn’t know what “telegram” / “whatsapp” is yet). In v2026.2.x those connectors ship as bundled plugins, but they can be disabled until you enable them.

1) Check which plugins are loaded

On the VPS:

openclaw plugins list

2) Enable the bundled channel plugins + restart

openclaw plugins enable telegram
openclaw plugins enable whatsapp
openclaw gateway restart

If you have a plugin allowlist in config (plugins.allow), make sure it includes telegram and whatsapp, and that plugins.enabled isn’t set to false.

#

If something still doesn’t load:

openclaw plugins doctor

3) Then configure the channels (separately from “enabling”)

Telegram:

Put your BotFather token in config (channels.telegram.botToken) or use the CLI helper:
```
openclaw channels add --channel telegram --token "<bot_token>"
```

WhatsApp:

openclaw channels login --channel whatsapp

#

Docs:

Plugins enable/disable: https://docs.openclaw.ai/cli/plugins
Telegram channel: https://docs.openclaw.ai/channels/telegram
WhatsApp channel: https://docs.openclaw.ai/channels/whatsapp

#

Those errors mean the channel plugins aren’t loaded, so OpenClaw doesn’t recognize telegram / whatsapp as valid channel IDs yet.

On your VPS:

1) See what channel plugins are available/loaded

openclaw plugins list

2) Enable the bundled channel plugins + restart the gateway

openclaw plugins enable telegram
openclaw plugins enable whatsapp
openclaw gateway restart

If you have a plugin allowlist/denylist in config, make sure it isn’t blocking them:

#

plugins.enabled must not be false
plugins.allow (if set) must include telegram and whatsapp
plugins.deny must not include them

If anything looks weird:

openclaw plugins doctor

3) Then configure the channels (enabling != configured)

Telegram

Add token (either config or CLI):

openclaw channels add --channel telegram --token "<botfather_token>"

WhatsApp

#

Login via QR:

openclaw channels login --channel whatsapp

Docs:

Plugins: https://docs.openclaw.ai/cli/plugins
Telegram: https://docs.openclaw.ai/channels/telegram
WhatsApp: https://docs.openclaw.ai/channels/whatsapp

If you paste the output of openclaw plugins list (no secrets), I can tell you exactly what’s missing/blocked.

jolly finch Feb 14, 2026, 12:22 PM

#

@ashen fern in aith-profile i found this

{
"version": 1,
"profiles": {
"openrouter:default": {
"type": "api_key",
"provider": "openrouter",
"key": "key"
},
"moonshot:default": {
"type": "api_key",
"provider": "moonshot",
"key": "key"
},
"kimi-coding:default": {
"type": "api_key",
"provider": "kimi-coding",
"key": "key"
},
"minimax:default": {
"type": "api_key",
"provider": "minimax",
"key": "key"
}
},
"lastGood": {
"openrouter": "openrouter:default",
"moonshot": "moonshot:default",
"kimi-coding": "kimi-coding:default"

ashen fernBOT Feb 14, 2026, 12:22 PM

#

Yep — that file is the reason it’s messy. auth-profiles.json is the highest priority credential source, so if “old” keys are still in there, OpenClaw will keep using them even if you changed config env.

First: don’t paste that file contents again (it contains live secrets). If any real keys were posted publicly, rotate them.

The clean “use ONLY Moonshot (Kimi) new key” fix

Option A (fastest clean reset): disable the whole auth store, then add only Moonshot

On the gateway host:

# backup / disable old stored keys
cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/main/agent/auth-profiles.backup.json
mv ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/main/agent/auth-profiles.json.disabled

Now add ONLY your new Moonshot key (CLI will prompt you to paste it):

#

openclaw models auth paste-token --provider moonshot --profile-id moonshot:default
openclaw gateway restart

Then force the model:

openclaw models set moonshot/kimi-k2.5
openclaw models fallbacks clear
openclaw models image-fallbacks clear
openclaw gateway restart

Option B (surgical): edit the file and remove other providers

Edit:

#

cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/main/agent/auth-profiles.backup.json
nano ~/.openclaw/agents/main/agent/auth-profiles.json

In the JSON:

In "profiles", delete:
- openrouter:default
- kimi-coding:default (if you don’t want it)
- minimax:default
In "lastGood", remove those provider entries too.
If there is a "usageStats" section, delete the entries for removed providers, and also delete the moonshot:default cooldown entry if you want to clear cooldown.

Save, then:

#

openclaw gateway restart

Verify which API/provider is being used

openclaw models status --agent main
openclaw logs --follow

Send 1 test message and you should see it attempt moonshot/kimi-k2.5.

If you tell me: do you want only moonshot (recommended) or do you also want kimi-coding kept as a backup?

jolly finch Feb 14, 2026, 12:29 PM

#

@ashen fern new aith profile was made with the new api key still not working here is more error messages showing
I did restart as well

⚠️ Agent failed before reply: All models failed (4): moonshot/kimi-k2-0905-preview: ⚠️ moonshot returned a billing error — your API key has run out of credits or has an insufficient balance. Check your moonshot billing dashboard and top up or switch to a different API key. (rate_limit) | kimi-coding/k2p5: No API key found for provider "kimi-coding". Auth store: /Users/mdsariflislam/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /Users/mdsariflislam/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir. (auth) | minimax/MiniMax-M2.5: No API key found for provider "minimax". Auth store: /Users/mdsariflislam/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /Users/mdsariflislam/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir. (auth) | moonshot/kimi-k2.5: No available auth profile for moonshot (all in cooldown or unavailable). (rate_limit).
Logs: openclaw logs --follow

ashen fernBOT Feb 14, 2026, 12:30 PM

#

That error output actually contains the diagnosis — it’s not “old key still being used”, it’s:

Moonshot key is valid, but has no credits / insufficient balance
OpenClaw is still trying other models (kimi-coding / minimax / preview) because they’re still in your model chain somewhere

Let’s decode your lines:

What each line means

moonshot/kimi-k2-0905-preview: ... billing error — run out of credits / insufficient balance
→ Your Moonshot API key is being used and Moonshot is rejecting it for billing. You need to top up Moonshot or use a different Moonshot key that has credit.
moonshot/kimi-k2.5: No available auth profile for moonshot (all in cooldown or unavailable)
→ After billing/rate-limit failures, OpenClaw marks the profile disabled/cooldown for a while. Even if you fix billing, it may stay “unusable” until the timer expires unless you clear usageStats.
kimi-coding/k2p5: No API key found and minimax/...: No API key found
→ That’s expected if you removed those keys. The real problem is: why is it trying those models at all?

#

Fix path (minimal + deterministic)

Step 1) Make the agent try ONLY ONE model (Moonshot Kimi K2.5)

On the gateway host:

openclaw models set moonshot/kimi-k2.5
openclaw models fallbacks clear
openclaw models image-fallbacks clear
openclaw gateway restart

Then in the chat you’re testing from:

send /new
then /model moonshot/kimi-k2.5

#

This removes session overrides + stops it bouncing.

Step 2) Ensure your config doesn’t still list other models as fallbacks

Run:

openclaw config get agents.defaults.model

If it shows a fallbacks: [...] list, wipe it:

openclaw config set agents.defaults.model.fallbacks "[]" --json
openclaw gateway restart

Also check image model (often the hidden source of “extra models”):

#

openclaw config get agents.defaults.imageModel

Step 3) Fix Moonshot billing

This part is outside OpenClaw:

go to Moonshot billing dashboard and top up, or generate a key with credit.

If you created a new key, store it as the moonshot profile (don’t paste it here):

openclaw models auth paste-token --provider moonshot --profile-id moonshot:default
openclaw gateway restart

Step 4) If you topped up but it still says “unavailable/cooldown”

Clear the disabled/cooldown bookkeeping for moonshot:

#

cp ~/.openclaw/agents/main/agent/auth-profiles.json ~/.openclaw/agents/main/agent/auth-profiles.backup.json
nano ~/.openclaw/agents/main/agent/auth-profiles.json

In that file, delete usageStats entries for moonshot:default (or delete the whole usageStats block), save, then:

openclaw gateway restart

One quick question

Are you intentionally trying to use moonshot/kimi-k2-0905-preview? If not, we should also remove that from your config “models catalog” / any per-agent model override, because it should not be attempted if you’re set to kimi-k2.5 with no fallbacks.

If you paste the output of these (safe; no secrets):

#

openclaw models status --agent main
openclaw config get agents.defaults.model
openclaw config get agents.defaults.imageModel

…I can tell you exactly what is still pulling in kimi-coding/minimax/the preview model.

jolly finch Feb 14, 2026, 12:37 PM

#

@ashen fern yeah too problem with kimi change to midmax and works fine

ashen fernBOT Feb 14, 2026, 12:38 PM

#

Got it — that fits perfectly with the error you pasted earlier: your Moonshot/Kimi key is hitting billing/credit limits, so it keeps failing. MiniMax working means your gateway + channel setup is fine; it’s just the Kimi quota.

If you want to stick with MiniMax now, do this so it stops trying Kimi at all:

Set MiniMax as the only model + clear fallbacks:

openclaw models set minimax/MiniMax-M2.5
openclaw models fallbacks clear
openclaw models image-fallbacks clear
openclaw gateway restart

Start a fresh chat session (important if you previously forced a Kimi model in-session):

send /new
(optional) /model minimax/MiniMax-M2.5

Optional cleanup: remove Moonshot/Kimi keys so you don’t accidentally rotate back later

#

Remove moonshot:default / kimi-coding:default from ~/.openclaw/agents/main/agent/auth-profiles.json
(backup first)

When you’re ready to go back to Kimi later, you’ll need to top up Moonshot or use a key with enough credit, then re-add it.

If this solved your issue, please mark the solution in Discord (right‑click → Apps → ✅ Mark Solution) so others can find it.

jolly finch Feb 14, 2026, 12:39 PM

#

@ashen fern how do i upgrade my openclaw to dev so i can coonect my other worker agent to telegram channel

ashen fernBOT Feb 14, 2026, 12:39 PM

#

You can switch to dev, but heads-up: you usually don’t need dev to connect a second/worker agent to Telegram — that’s typically Telegram multi-account + bindings (and making sure the telegram plugin is enabled).

That said, here’s how to upgrade OpenClaw to dev safely:

Upgrade to dev (runs on the gateway host)

Check where you are:

openclaw --version
openclaw update status

Switch to dev (this will set up/ensure a git checkout, rebuild, run doctor, and usually restart the gateway):

openclaw update --channel dev

If you prefer the interactive flow:

#

openclaw update wizard

Verify after:

openclaw --version
openclaw status

Docs: https://docs.openclaw.ai/cli/update

If your goal is “worker agent talks via Telegram”

After you’re updated (or even before), make sure Telegram channel plugin is enabled:

#

openclaw plugins enable telegram
openclaw gateway restart

Then you configure two Telegram bot tokens under channels.telegram.accounts and route one accountId to your worker agent via bindings.

If you paste (redacting tokens) the output of:

openclaw plugins list
openclaw agents list --bindings
openclaw config get channels.telegram

…I’ll tell you exactly what config you’re missing for the worker Telegram bot.

jolly finch Feb 14, 2026, 12:45 PM

#

@ashen fern okay now that is out of the way, lets fix jax and connect him to the new bot. main bot will be stay active going to need you to help me connect new worker bot jax to new telegram

ashen fernBOT Feb 14, 2026, 12:46 PM

#

Cool — we can keep your main Telegram bot working and add a second Telegram bot that routes only to agent jax, all on the same Gateway/port.

The cleanest way is: add a second Telegram account (accountId=jax) + add a binding.

0) Verify basics (gateway host)

Run these on the machine running the gateway:

openclaw agents list --bindings
openclaw channels list

Confirm:

agent jax exists
Telegram channel is present

1) Add the NEW Telegram bot as a second Telegram account

#

Don’t paste the token in Discord — run this in your terminal on the gateway host:

openclaw channels add --channel telegram --account jax --name "Jax bot" --token "<BOTFATHER_TOKEN>"

(That creates channels.telegram.accounts.jax in config.)

Then restart:

openclaw gateway restart

2) Route that Telegram account to agent `jax` (binding)

Check what bindings you currently have:

#

openclaw config get bindings

If you don’t have custom bindings yet (or you’re OK replacing them), the minimal bindings look like this:

[
  { "agentId": "main", "match": { "channel": "telegram", "accountId": "default" } },
  { "agentId": "jax",  "match": { "channel": "telegram", "accountId": "jax" } }
]

If you paste your current bindings output here (no secrets), I’ll tell you the exact safe openclaw config set bindings ... --json command that preserves your existing routes.

Restart after any binding change:

#

openclaw gateway restart

3) Make sure DM policy allows you to chat (pairing)

Set Telegram DMs to pairing (if not already):

openclaw config set channels.telegram.dmPolicy pairing
openclaw gateway restart

Now DM the new Jax bot in Telegram with a normal message like hi (not just /start).

Then approve the pairing:

#

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

4) Test

DM main bot → should talk to agent main
DM jax bot → should talk to agent jax

If you still get “no pairing code”

Run on the gateway host while you DM the Jax bot:

openclaw logs --follow

If there are no Telegram log lines when you DM it, the token/account isn’t actually connected (wrong token or not loaded).

#

Send me the output of:

openclaw agents list --bindings
openclaw channels list
openclaw config get channels.telegram
openclaw config get bindings

(redact tokens) and I’ll tell you exactly what’s missing.

jolly finch Feb 14, 2026, 12:48 PM

#

@ashen fern here is the channel histoy

Chat channels:

Telegram jax: configured, token=config, enabled

ashen fernBOT Feb 14, 2026, 12:49 PM

#

Nice — that line means the Telegram “jax” account is configured + enabled, so the gateway knows about it.

Next we need to confirm two things:

Is the jax bot actually receiving Telegram updates (connected/healthy)?
Is your DM policy set to pairing (so you’ll get a pairing code)?

Run these on the gateway host and paste output (no tokens):

openclaw channels status --probe
openclaw pairing list telegram
openclaw agents list --bindings
openclaw config get channels.telegram.dmPolicy

What to do while checking

#

In Telegram, DM the jax bot a normal text message like: hi
(Not only /start — /start can be weird sometimes.)
On the gateway host, tail logs while you send it:

openclaw logs --follow

If no Telegram log lines appear at all when you DM jax → token is wrong, or that bot token is being used somewhere else (409 conflict / webhook), or the account isn’t actually running.
If logs show an inbound message but no pairing code, then dmPolicy isn’t pairing or you already hit the pending pairing cap (3).

Quick fix if dmPolicy isn’t pairing

openclaw config set channels.telegram.dmPolicy pairing
openclaw gateway restart

#

Then DM jax bot again and approve:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Send me the channels status --probe + pairing list telegram output and I’ll tell you exactly what’s blocking it.

jolly finch Feb 14, 2026, 12:51 PM

#

@ashen fern if i message telegram new bot nothing coming up now

ashen fernBOT Feb 14, 2026, 12:52 PM

#

If nothing at all shows up when you message the new Telegram bot, that’s before pairing — it means the gateway is not receiving updates for that bot account.

The two most common causes:

Wrong bot token (BotFather token mismatch) → Telegram API returns 401
The bot token is being used somewhere else / webhook conflict → Telegram returns 409 Conflict or webhook is set

Let’s prove which one in 60 seconds.

1) Tail logs while you DM the new bot (do this now)

On the gateway host:

openclaw logs --follow

Then DM the new bot: hi

#

Copy/paste the Telegram-related log lines you see right then.

2) Probe channel health

In another terminal:

openclaw channels status --probe

Paste the telegram probe section.

3) Quick Telegram-side reset (fixes webhook/conflict)

If logs show conflict / webhook, run this using the jax token (run on gateway host; don’t paste token here):

curl -s "https://api.telegram.org/bot<JAX_TOKEN>/deleteWebhook?drop_pending_updates=true"

#

Then restart gateway:

openclaw gateway restart

DM the bot again.

4) If logs show 401 Unauthorized

Then the token in config is wrong. Re-add it:

openclaw channels add --channel telegram --account jax --token "<JAX_TOKEN>"
openclaw gateway restart

#

Send me what you get from logs + channels status --probe and I’ll tell you the exact next step.

jolly finch Feb 14, 2026, 12:53 PM

#

@ashen fern

telegram jax: Config allows unmentioned group messages (requireMention=false). Telegram Bot API privacy mode will block most group messages unless disabled. (In BotFather run /setprivacy → Disable for this bot (then restart the gateway).)
telegram jax: Some configured Telegram groups are not numeric IDs (unresolvedGroups=2). Membership probe can only check numeric group IDs. (Use numeric chat IDs (e.g. -100...) as keys in channels.telegram.groups for requireMention=false groups.)

ashen fernBOT Feb 14, 2026, 12:53 PM

#

Those two lines are group-chat warnings, not DM pairing issues.

1) If you’re testing the new bot in a Telegram group

Telegram is probably not even delivering the messages to your bot because Privacy Mode is still ON.

Fix (for the jax bot):

In Telegram → open @BotFather
Run: /setprivacy
Pick your jax bot
Choose Disable
Remove + re-add the bot to the group (Telegram often won’t apply the new privacy setting until you re-add), or make the bot a group admin
Restart OpenClaw gateway:
```
openclaw gateway restart
```

#

After that, unmentioned group messages can reach the bot.

2) Fix the “unresolvedGroups=2” config issue

It means in channels.telegram.groups you used non-numeric keys (like a name). OpenClaw needs the numeric chat id, like -100....

Fast way to get it:

On the gateway host:
```
openclaw logs --follow
```
Send one message in that Telegram group
In logs, find chat.id: -100...

Then update your config so the group key is that numeric id (not the name), e.g.:

#

channels: {
  telegram: {
    groups: {
      "-1001234567890": { requireMention: false }
    }
  }
}

Restart the gateway after saving.

Quick question (so we don’t chase the wrong thing)

Are you trying to talk to the jax bot via DM or in a group?
If it’s DM and still nothing arrives, paste the Telegram part of:

#

openclaw channels status --probe

(That will show if the bot token is valid / conflicts / etc.)

jolly finch Feb 14, 2026, 12:54 PM

#

@ashen fern error gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} handler failed: Error: Session file path must be within sessions director

ashen fernBOT Feb 14, 2026, 12:55 PM

#

That Telegram handler error:

Session file path must be within sessions directory

is a known bug in 2026.2.12 that hits a lot when you use non-main agents (like jax) / multi-agent routing. It was fixed in 2026.2.13 (changelog fix #15141).

Fix (do this on the gateway host)

Confirm your version:

openclaw --version

Update to at least 2026.2.13 (or dev), then restart:

openclaw update --channel stable   # or: --channel dev
openclaw gateway restart

#Build a Worker Agent with Terminal, Telegram & Slack Integration

“Relay terminal conversation to both Telegram + Slack in real time”

Rough timeline (for a dev who’s already done Slack/Telegram bots)

Clarifying questions (these change scope a lot)

1) Create the new “order” agent

2) Connect Telegram specifically to that agent

Option A (recommended): Give the orders agent its own Telegram bot

Option B: Same Telegram bot, but route only a specific DM/group to “orders”

After config changes

1) First: what version are you on?

2) If you’re on 2026.2.12

3) If you’re NOT on 2026.2.12

1) Your worker agent is NOT “on an old version”

2) Update OpenClaw (fix is in 2026.2.13)

3) After it works: check auth for the worker agent (auth is per-agent)

Your worker agent is not “running an old version”

Update (recommended)

After updating

Fix (real fix): update to ≥ 2026.2.13, then restart

If you updated but it STILL shows 2026.2.12

Temporary workaround (until you update)

Can you run a specific agent?

Workarounds without installing beta (pick one)

Workaround A (often works): use a NEW session key for loki

Workaround B (more reliable): reset ONLY loki’s sessions (loses loki chat history)

The real fix (when you’re ready)

Why you’re seeing the session error

Fix options

Option 1 (no beta/dev): use a fresh session for loki (quick try)

Option 2 (no beta/dev): clear ONLY loki’s session index (more reliable, loses loki chat history)

Option 3 (real fix now): dev channel (not beta)

Workaround: don’t use loki’s main session from TUI

Even easier: start TUI directly on a fresh loki session

Why this helps

0) Don’t paste your bot token here

1) Add a Telegram “account” for Loki in config

2) Restart the gateway

3) DM the new Loki bot and approve pairing

Why this helps (and why TUI still errors)

If this Telegram bot should go ONLY to agent loki (single bot setup)

If you want TWO Telegram bots (one for main, one for loki)

About your current groups: { "@GROUP": ... }

Mental model

How bindings work (most-specific wins)

Example 1: route all Telegram to loki

Example 2: route a specific Telegram group to loki, rest to main

Example 3 (your case): route a specific Telegram bot account to loki

Why it matters

Prompt to give your main bot

Option A (recommended on stable): run Loki as a separate OpenClaw instance (separate profile)

1) Create a new profile config for Loki

2) Start Loki gateway

3) Pair your Telegram DM

Option B: wait for stable 2026.2.13

Quick note on safety

What OpenClaw can do (today)

Important limitation

But you can still get “this topic is only for him; no mentions needed”

Example (single Telegram bot; dedicate one topic)

How to find the group chat id and topic id

Also required: Telegram “privacy mode”

What you want (simple version)

How it works

What you have to do (steps)

One important limitation (so expectations are clear)

Prompt (fix main bot replying in Telegram topic without mentions)

Key point (so it’s not confusing)

What to do (simple steps)

1) Create a new topic for Loki

2) Add Loki’s Telegram bot to that group

3) Run Loki as a separate OpenClaw “profile” (separate instance)

4) (Optional but recommended) Disable your MAIN bot in Loki’s topic

How to get the IDs (fast)

1) Update OpenClaw to beta (and confirm it’s newer than 2026.2.12)

2) Connect Loki to a NEW Telegram bot (multi-account Telegram)

3) Pair your Telegram DM with the Loki bot

Quick way to confirm what beta points to

What to do instead (if you want it working now)

Option 1 (fastest): use dev (has the fix)

Option 2 (stable-only): run Loki as a separate profile / second instance

Option 1 (no beta/dev): use a fresh session for `loki` (quick try)

Workaround: don’t use loki’s `main` session from TUI

If this Telegram bot should go ONLY to agent `loki` (single bot setup)

About your current `groups: { "@GROUP": ... }`

Solution (stable, no dev): run a 2nd OpenClaw instance for Loki using `--profile`

2) Why `/new` “doesn’t work” in Slack

2) Add channel override in `openclaw.json`

3) Add a “Loki topic config” in `~/.openclaw/openclaw.json`

3) Run `openclaw config` for the worker instance