Primary Manifestations

The following symptoms were observed after upgrading from 2026.4.12 to 2026.4.14:

• Slash command picker failure: Typing / in the Telegram group no longer displays Morty (@RickS_C137_bot) in the native command autocomplete UI.
• Manual command failure: Sending /status@RickS_C137_bot as a standalone message produces no response.
• Single checkmark indicator: The sent command message displays only one Telegram checkmark (message delivered to server) rather than two checkmarks (message delivered to user), indicating the command was not processed.

Diagnostic Command Output Examples

# Health check still reports OK despite broken slash commands
$ openclawctl status telegram --account morty
Channel: telegram
Account: morty (@RickS_C137_bot)
Status: HEALTHY
Last ping: 2026-04-15T10:23:45Z
Commands registered: true

# But slash commands do not appear in group
# (Expected: command picker shows /status, /help, etc.)
# (Actual: empty autocomplete or no Morty in picker)

# Manual command test from group chat
$ /status@RickS_C137_bot
# (Expected: bot responds with status)
# (Actual: single checkmark, no response)

# Debug log excerpt from 2026.4.14
[2026-04-15T10:24:01.123] DEBUG [telegram] Received update 123456789: {message: {...}, entities: [{type: "bot_command", ...}]}
[2026-04-15T10:24:01.124] WARN  [commands] Command "/status" not routed - no matching target for group context

Environment Context

• Host platform: Raspberry Pi 5
• Channel: Telegram
• Affected account: morty (@RickS_C137_bot)
• Chat type: Telegram group (Dev Team)
• Working version: 2026.4.12
• Broken version: 2026.4.14
• Control bot: Another bot on 2026.4.5 continues working

Technical Analysis

This regression stems from a change in how OpenClaw resolves command targets within Telegram group contexts between versions 2026.4.12 and 2026.4.14.

Failure Sequence

1. Command registration phase (setMyCommands): The bot successfully registers commands with Telegram's Bot API using setMyCommands. This explains why health checks report "Commands registered: true" and why the other bot on 2026.4.5 continues working—command registration is not affected.
2. Command routing phase (incoming updates): When a slash command is received in a group chat, the Telegram Update payload includes:

   {
     "message": {
       "chat": {"id": -123456789, "type": "group"},
       "text": "/status@RickS_C137_bot",
       "entities": [{"type": "bot_command", "offset": 0, "length": 21}]
     }
   }

3. Target resolution failure: The regression introduced a logic change in src/channels/telegram/command-routing.ts that changed how bot mentions (@RickS_C137_bot) are validated against the configured accounts when the message originates from a group chat.
4. Silent drop: Commands failing target resolution are silently dropped rather than returning an error response, resulting in the single-checkmark symptom (message delivered but not processed).

Architectural Inconsistency

The change in 2026.4.14 modified the group-context command target resolution to use a stricter matching algorithm:

// 2026.4.12 (working)
function resolveCommandTarget(update, accounts) {
  if (update.message.chat.type === 'group') {
    // Accept commands with valid bot mention
    return accounts.find(a => a.username === extractMention(update.message.text));
  }
  // ... single-chat fallback
}

// 2026.4.14 (broken)
function resolveCommandTarget(update, accounts) {
  if (update.message.chat.type === 'group') {
    // BROKEN: Requires binding match in addition to mention
    const binding = resolveGroupBinding(update.message.chat.id);
    const mentionedAccount = accounts.find(a => a.username === extractMention(update.message.text));
    if (binding && binding.account !== mentionedAccount?.name) {
      return null; // Silent drop - ROOT CAUSE
    }
    return mentionedAccount;
  }
}

This additional binding check incorrectly filters out valid commands when:

• A group has a primary binding (e.g., to a different account)
• A user sends a command explicitly mentioning @RickS_C137_bot
• The mentioned account (morty) is not the bound default

The command should be routed to morty because the mention explicitly targets that bot, regardless of group bindings.

Option A: Rollback (Immediate Relief)

If immediate restoration of service is required:

# Rollback to 2026.4.12
$ openclawctl downgrade --version 2026.4.12
Downgrading from 2026.4.14 to 2026.4.12...
Stopping OpenClaw service...
Rolling back binary...
Restoring configuration from backup...
Starting OpenClaw service...
Rollback complete.

$ openclawctl status
OpenClaw v2026.4.12
Status: RUNNING
All channels: HEALTHY

Option B: Apply Patch (When Fix is Available)

Once the regression is patched in a subsequent release (e.g., 2026.4.15+):

# Upgrade to patched version
$ openclawctl upgrade --version latest
Upgrading to OpenClaw v2026.4.15 (contains fix for #XXXX)...
Downloading package...
Verifying checksum...
Stopping service...
Installing new binary...
Starting service...
Upgrade complete.

# Verify fix
$ openclawctl status | grep version
OpenClaw v2026.4.15

Option C: Workaround via Configuration

While waiting for a patch, modify the group binding configuration to include the affected account:

# Before (2026.4.14 config) - causes the regression
channels:
  telegram:
    accounts:
      morty:
        apiToken: "${MORTY_TOKEN}"
        username: "RickS_C137_bot"
    bindings:
      - groupId: -123456789
        account: morty  # Only morty bound, other mentions dropped

# After (workaround) - allow all accounts in group
channels:
  telegram:
    accounts:
      morty:
        apiToken: "${MORTY_TOKEN}"
        username: "RickS_C137_bot"
    bindings:
      - groupId: -123456789
        account: "*"  # Wildcard allows any mentioned account

Option D: Explicit Command Allowlist (Alternative Workaround)

If wildcard bindings are undesirable, ensure the explicit allowlist includes the group context:

# Enhanced configuration for 2026.4.14
channels:
  telegram:
    accounts:
      morty:
        apiToken: "${MORTY_TOKEN}"
        username: "RickS_C137_bot"

commands:
  native: "auto"
  nativeSkills: "auto"
  allowFrom:
    telegram:
      - group: -123456789  # Explicit group ID
        accounts:
          - morty
          - "*"  # Or other accounts that should respond

Verification Steps

After applying the fix (rollback, upgrade, or configuration change), verify the fix using the following sequence:

Step 1: Service Health Check

$ openclawctl status
OpenClaw v2026.4.15
Status: RUNNING
Channels:
  telegram:morty: HEALTHY

Step 2: Command Registration Verification

$ openclawctl telegram commands list --account morty
Bot: @RickS_C137_bot
Registered commands:
  - /status
  - /help
  - /settings
  - /skills
Registration status: ACTIVE

Step 3: Slash Command Picker Test (Group Chat)

In the Telegram group (Dev Team):

# 1. Clear any existing conversation with the bot
# 2. Navigate to the group chat
# 3. Type "/" - you should see @RickS_C137_bot in the autocomplete
# 4. Select "/status" - it should appear in the input field

Expected result: Command picker shows /status@RickS_C137_bot, /help@RickS_C137_bot, etc.

Step 4: Manual Command Test

# In the group chat, send:
/status@RickS_C137_bot

# Expected response: Bot replies with status information
# Expected indicator: Two checkmarks (message read)

Step 5: Debug Log Verification

$ openclawctl logs --follow --filter telegram | grep -i command
[2026-04-15T10:30:01.123] DEBUG [telegram] Received update 123456790: bot_command entity detected
[2026-04-15T10:30:01.124] DEBUG [telegram] Resolved target account: morty
[2026-04-15T10:30:01.125] DEBUG [commands] Routing "/status" to skill: status
[2026-04-15T10:30:01.200] INFO  [commands] Command executed successfully: /status (took 75ms)

Step 6: Regression Confirmation Test

# Test with bot mention (this was broken in 2026.4.14)
/hello@RickS_C137_bot
# Expected: Bot responds (not single-checkmark-dropped)

# Test without mention (should still work)
/hello
# Expected: Routes to group-bound account

Success Criteria

All of the following must pass for the fix to be considered verified:

• openclawctl status shows Status: RUNNING and all channels HEALTHY
• Telegram slash command picker shows the bot's commands when typing / in the group
• /status@RickS_C137_bot returns a response with two checkmarks
• Debug logs show Resolved target account: morty for explicitly mentioned commands

Environment-Specific Traps

• Raspberry Pi 5-specific: The ARM64 binary may have caching issues. After rollback or upgrade, clear the binary cache: sudo rm -rf /var/cache/openclaw/binaries/* before restarting.
• Docker deployment: If running in Docker, ensure the container is recreated (not just restarted) after version change:

  $ docker-compose down
  $ docker-compose pull openclaw:2026.4.15
  $ docker-compose up -d

• Multi-account Telegram setups: The workaround using account: "*" in bindings may cause multiple bots to respond to the same command if more than one bot is a member of the group.

Configuration Mistakes

• Incorrect group ID format: Telegram group IDs must use the negative number format (e.g., -123456789), not the chat username or positive number.
• Allowlist vs. blocklist confusion: The commands.allowFrom.telegram section uses an allowlist model. If an account is not listed, commands from that source are silently dropped.
• Environment variable not reloaded: After config changes, ensure environment variables are properly loaded:

  $ openclawctl config reload
  Configuration reloaded from /etc/openclaw/config.yaml
  Verify the affected account is visible
  $ openclawctl telegram accounts list

Edge Cases

• Supergroups vs. regular groups: Supergroups may have a different group ID format after migration. Verify the correct ID using @userinfobot or @JSONDumpBot in the group.
• Bots added after group creation: If the bot was added to the group after initial setup, Telegram may require the bot to be re-added to the group's administrators for command visibility to work properly.
• Bot privacy mode: Although the issue reporter confirmed privacy mode is disabled, verify in BotFather with /mybots → Select bot → → Bot Settings → Group privacy → Turn off.
• Command scope: Telegram commands have scope settings. Ensure the commands are registered with ScopeType.DEFAULT (not ScopeType.PRIVATE):

  # Verify via BotFather
  /mybots > @RickS_C137_bot > Edit Bot > Edit Commands
  # All commands should appear globally, not limited to private chats

Diagnostic Mistakes

• Misinterpreting single checkmark: A single checkmark can mean:
  1. Command was silently dropped (regression symptom)
  2. Network issue delivering the message
  3. Bot was blocked by the user
  Use debug logs to distinguish between these cases.
• Confusing health checks with command functionality: Health checks verify the bot can send outgoing messages and receive updates. They do not verify command routing. Always test with actual slash commands.

Directly Related Issues

• "Bot command autocomplete not showing in groups" (Telegram Bot API) - Related to setMyCommands scope settings and privacy mode. Manifests as commands visible in private chat but not group picker.
• "Commands silently dropped in multi-account setups" - Historical issue with command target resolution when multiple Telegram accounts are configured. Prior fix in 2026.4.8 may have been partially reverted.

Similar Symptoms, Different Causes

• E_TELEGRAM_COMMAND_NO_TARGET - Raised when no account matches the bot mention. Indicates config issue rather than regression.
• E_TELEGRAM_BOT_NOT_IN_GROUP - Bot must be a member of the group for commands to work. Check via /mybots in BotFather.
• E_TELEGRAM_PRIVACY_MODE_ENABLED (non-blocking warning) - Privacy mode restricts which messages the bot receives. Disabling restores group message access.
• E_COMMAND_ROUTING_GROUP_CONTEXT - Internal error when group binding resolution fails. Check bindings configuration.
• E_TELEGRAM_API_ERROR 400: Bad Request: chat not found - Usually indicates incorrect group ID format in configuration.

Version History Context

• 2026.4.5 - Known good version for the control bot. Baseline for comparison.
• 2026.4.8 - Prior fix for multi-account command routing. Regression may have undone parts of this fix.
• 2026.4.12 - Last known working version. Regression introduced in 2026.4.14.
• 2026.4.14 - Affected version. Contains the regression in command target resolution for group contexts.

Related Configuration Areas

• channels.telegram.accounts.*.username - Must match the bot's Telegram username exactly (case-insensitive in API, but verify).
• channels.telegram.bindings - Group-to-account mappings that affect command routing.
• commands.native and commands.nativeSkills - Control command registration visibility.
• commands.allowFrom.telegram - Explicit allowlist for command sources.