Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Telegram plugin commands can fail with 'Something went wrong' when command handler result is undefined in v2026.4.27 [5 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#74800•Fetched 2026-05-01 05:41:16
View on GitHub
Comments
1
Participants
2
Timeline
13
Reactions
3
Author
githubdulonggithubdulong
Participants
clawsweeper[bot]clawsweeper[bot]githubdulonggithubdulong
Timeline (top)
cross-referenced ×6mentioned ×3subscribed ×3commented ×1

After upgrading to v2026.4.27, Telegram custom/plugin commands such as /bf and /asset can surface:

Something went wrong while processing your request. Please try again.

In my case these are local routing/plugin commands (non-AI scripts). The underlying script can still run, but Telegram returns the generic error.

Error Message

telegram dispatch failed: TypeError: Cannot read properties of undefined (reading 'continueAgent') message processed: channel=telegram chatId=telegram:652005781 messageId=95188 sessionId=unknown sessionKey=agent:main:main outcome=error duration=808ms error="TypeError: Cannot read properties of undefined (reading 'continueAgent')"

Root Cause

After upgrading to v2026.4.27, Telegram custom/plugin commands such as /bf and /asset can surface:

Something went wrong while processing your request. Please try again.

In my case these are local routing/plugin commands (non-AI scripts). The underlying script can still run, but Telegram returns the generic error.

Fix Action

Fix / Workaround

telegram dispatch failed: TypeError: Cannot read properties of undefined (reading 'continueAgent')
message processed: channel=telegram chatId=telegram:652005781 messageId=95188 sessionId=unknown sessionKey=agent:main:main outcome=error duration=808ms error="TypeError: Cannot read properties of undefined (reading 'continueAgent')"

PR fix notes

PR #74834: fix: 5 targeted bug fixes (gemini-cli, plugin commands, openrouter thinking, cron summary, LLM-only tools)

Description (problem / solution / changelog)

Summary

Five independent targeted fixes, each addressing a distinct bug:

1. fix(google): remove unsupported --skip-trust flag from gemini-cli backend (#74749)

gemini-cli >= 0.38.x dropped --skip-trust. Passing it causes yargs to exit non-zero on every call, resulting in 100% failure rate for the gemini CLI backend. Removed from both args and resumeArgs.

2. fix(plugins): guard against undefined plugin command handler result (#74800)

Plugin command handlers typed as Promise<PluginCommandResult> can return undefined at runtime. The caller in commands-plugin.ts immediately destructures result.continueAgent, crashing with Cannot read properties of undefined. Added a ?? {} fallback at the execution boundary.

3. fix(openrouter): add resolveThinkingProfile with xhigh for reasoning models (#74788)

OpenRouter had no resolveThinkingProfile, so /think xhigh was rejected for all models including openrouter/deepseek/deepseek-v4-pro. Added a profile that exposes xhigh for models with reasoning: true (unless explicitly excluded via isOpenRouterProxyReasoningUnsupportedModel).

4. fix(cron): prefer finalAssistantVisibleText over raw error text in task summary (#74807)

When a cron agentTurn run had only error payloads (tool call failed, agent self-corrected but never sent an explicit reply via messaging tool), fallbackSummary fell through to pickSummaryFromOutput(firstText) where firstText was the tool error. Now prefers finalAssistantVisibleText as an intermediate fallback before resorting to raw payload text.

5. fix(agents): skip tool allowlist guard for LLM-only runs (#74810)

buildEmptyExplicitToolAllowlistError raised an error when callableToolNames was empty, even when disableTools: true. LLM-only runs intentionally disable tools, so an empty callable set is expected. Added early return when disableTools === true.

Testing

Each fix is independently testable:

  • #74749: pnpm test -- src/agents/cli-backends.test.ts
  • #74800: Trigger any plugin command whose handler returns undefined
  • #74788: pnpm test -- src/agents/pi-embedded-runner/openrouter-model-capabilities.test.ts
  • #74807: pnpm test -- src/cron/isolated-agent
  • #74810: pnpm test -- src/agents/tool-allowlist-guard

🤖 Generated with Claude Code

Changed files

  • extensions/google/cli-backend.ts (modified, +2/-10)
  • extensions/openrouter/index.ts (modified, +18/-0)
  • src/agents/cli-backends.test.ts (modified, +2/-10)
  • src/agents/tool-allowlist-guard.ts (modified, +4/-0)
  • src/cron/isolated-agent/helpers.ts (modified, +10/-2)
  • src/plugins/commands.ts (modified, +1/-1)

PR #74838: fix(plugins): guard against undefined plugin command handler result

Description (problem / solution / changelog)

Summary

Targeted single-fix PR.

Closes #74800

🤖 Generated with Claude Code

Changed files

  • src/plugins/commands.ts (modified, +1/-1)

PR #74856: fix(plugins): normalize undefined handler return to prevent TypeError on Telegram plugin commands

Description (problem / solution / changelog)

Problem

Plugin command handlers are third-party JS — they can omit an explicit return statement, causing executePluginCommand to resolve to undefined. Two downstream callers read properties immediately without a null guard:

  • commands-plugin.ts:59: result.continueAgent → TypeError: Cannot read properties of undefined (reading 'continueAgent')
  • bot-native-commands.ts:1213: result.channelData (via shouldSuppressLocalTelegramExecApprovalPrompt) → same TypeError

The user sees: Something went wrong while processing your request. Please try again.

Fixes #74800

Solution

Normalize at the executor boundary (commands.ts): coerce nullish handler return to {} so all callers are protected without individual null guards at every call site.

Add defensive null guard in commands-plugin.ts and bot-native-commands.ts for belt-and-suspenders safety (protects against mocked/wrapped executors that bypass the central normalization).

Files changed

  • src/plugins/commands.ts — rawResult ?? {} at executor return
  • src/auto-reply/reply/commands-plugin.ts — const safeResult = result ?? {}
  • extensions/telegram/src/bot-native-commands.ts — ?? {} on executePluginCommand result
  • src/auto-reply/reply/commands-plugin.test.ts — regression test: undefined handler result → no throw
  • extensions/telegram/src/bot-native-commands.test.ts — regression test: Telegram native path with undefined result → no throw

Test

pnpm test src/auto-reply/reply/commands-plugin.test.ts extensions/telegram/src/bot-native-commands.test.ts extensions/telegram/src/bot-native-commands.registry.test.ts

All 29 tests pass (5 + 24).

Changed files

  • extensions/telegram/src/bot-native-commands.test.ts (modified, +7/-0)
  • extensions/telegram/src/bot-native-commands.ts (modified, +16/-15)
  • src/auto-reply/reply/commands-plugin.test.ts (modified, +18/-0)
  • src/auto-reply/reply/commands-plugin.ts (modified, +3/-2)
  • src/plugins/commands.ts (modified, +4/-2)

PR #74989: Handle undefined plugin command results without failing Telegram command dispatch

Description (problem / solution / changelog)

Fixes #74800.

This hardens plugin command result handling so command handlers that intentionally perform side effects and return no payload are treated as no-op replies instead of dispatch failures.

Changes:

  • normalize nullish/non-object plugin command handler results at the shared executePluginCommand boundary
  • defensively normalize plugin command results in the generic command reply path and Telegram native command path before reading result fields
  • preserve existing continueAgent: true behavior and strip continueAgent from delivered reply payloads
  • add regression coverage for undefined plugin command results in the central command executor, shared command dispatch, and Telegram native command handling

Validation:

  • pnpm test src/plugins/commands.test.ts src/auto-reply/reply/commands-plugin.test.ts extensions/telegram/src/bot-native-commands.test.ts extensions/telegram/src/bot-native-commands.registry.test.ts
  • pnpm check:changed

Changed files

  • extensions/telegram/src/bot-native-commands.test.ts (modified, +18/-4)
  • extensions/telegram/src/bot-native-commands.ts (modified, +24/-15)
  • src/auto-reply/reply/commands-plugin.test.ts (modified, +23/-0)
  • src/auto-reply/reply/commands-plugin.ts (modified, +8/-3)
  • src/plugins/commands.test.ts (modified, +19/-0)
  • src/plugins/commands.ts (modified, +8/-1)

PR #75353: fix(plugins): guard against undefined plugin command handler result

Description (problem / solution / changelog)

Resubmit of #74838 (rebased on current main). Closes #74800

🤖 Generated with Claude Code

Changed files

  • src/plugins/commands.ts (modified, +1/-1)

Code Example

telegram dispatch failed: TypeError: Cannot read properties of undefined (reading 'continueAgent')
message processed: channel=telegram chatId=telegram:652005781 messageId=95188 sessionId=unknown sessionKey=agent:main:main outcome=error duration=808ms error="TypeError: Cannot read properties of undefined (reading 'continueAgent')"

---

const shouldContinue = result.continueAgent === true;
const { continueAgent: _continueAgent, ...reply } = result;

---

Plugin command "/bf" conflicts with an existing Telegram command.
Plugin command "/asset" conflicts with an existing Telegram command.

---

if (!result || typeof result !== 'object') {
  return { shouldContinue: false, reply: undefined };
}
RAW_BUFFERClick to expand / collapse

Summary

After upgrading to v2026.4.27, Telegram custom/plugin commands such as /bf and /asset can surface:

Something went wrong while processing your request. Please try again.

In my case these are local routing/plugin commands (non-AI scripts). The underlying script can still run, but Telegram returns the generic error.

Environment

  • OpenClaw version: 2026.4.27 (cbc2ba0)
  • Surface: Telegram direct chat
  • Host: macOS
  • Affected commands: /bf, /asset (from a local plugin / master-control extension)

Observed logs

I found this error in the gateway log:

telegram dispatch failed: TypeError: Cannot read properties of undefined (reading 'continueAgent')
message processed: channel=telegram chatId=telegram:652005781 messageId=95188 sessionId=unknown sessionKey=agent:main:main outcome=error duration=808ms error="TypeError: Cannot read properties of undefined (reading 'continueAgent')"

Relevant runtime location:

  • /Users/mutu/.openclaw/tools/node-v22.22.0/lib/node_modules/openclaw/dist/commands-handlers.runtime-zHxWFlUO.js:3374

The code there appears to do:

const shouldContinue = result.continueAgent === true;
const { continueAgent: _continueAgent, ...reply } = result;

If result is undefined, this crashes before Telegram can respond normally.

Additional context

The same startup also reports command conflicts such as:

Plugin command "/bf" conflicts with an existing Telegram command.
Plugin command "/asset" conflicts with an existing Telegram command.

However, the immediate user-facing failure seems to be the unguarded access to result.continueAgent, not the conflict log itself.

Expected behavior

If a plugin/custom command handler returns undefined or no reply payload, OpenClaw should not crash. It should either:

  • treat it as { shouldContinue: false, reply: undefined }, or
  • emit a clear plugin-handler error instead of the generic Telegram failure.

Actual behavior

Telegram users receive:

Something went wrong while processing your request. Please try again.

and logs show a TypeError on continueAgent.

Suggested fix

Add a null/undefined guard around the handler result in the command handling path before reading result.continueAgent.

For example, conceptually:

if (!result || typeof result !== 'object') {
  return { shouldContinue: false, reply: undefined };
}

Notes

I also previously hit another nearby undefined-payload crash in the same upgrade line, so this may be part of a broader defensive-handling regression around Telegram/plugin command reply plumbing.

extent analysis

TL;DR

Add a null/undefined guard around the handler result in the command handling path to prevent the TypeError on continueAgent.

Guidance

  • Verify that the result object is not null or undefined before accessing its properties, as suggested in the issue.
  • Check the command handling path in the commands-handlers.runtime-zHxWFlUO.js file to ensure that the guard is applied correctly.
  • Test the fix with different plugin/custom commands to ensure that it resolves the issue.
  • Consider adding additional error handling to emit a clear plugin-handler error instead of the generic Telegram failure.

Example

if (!result || typeof result !== 'object') {
  return { shouldContinue: false, reply: undefined };
}
const shouldContinue = result.continueAgent === true;
const { continueAgent: _continueAgent, ...reply } = result;

Notes

This fix may be part of a broader defensive-handling regression around Telegram/plugin command reply plumbing, so additional testing and verification may be necessary.

Recommendation

Apply the suggested workaround by adding a null/undefined guard around the handler result, as it directly addresses the TypeError on continueAgent and prevents the generic Telegram failure.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

If a plugin/custom command handler returns undefined or no reply payload, OpenClaw should not crash. It should either:

  • treat it as { shouldContinue: false, reply: undefined }, or
  • emit a clear plugin-handler error instead of the generic Telegram failure.
#environment variable#network issue#logging issue#authentication issue#prompt issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Telegram plugin commands can fail with 'Something went wrong' when command handler result is undefined in v2026.4.27 [5 pull requests, 1 comments, 2 participants]