openclaw - 💡(How to fix) Fix [Bug]: CLI backend (claude-cli/sonnet-4-6) + Telegram: agent stalls during file Read tool call against a wrapper path; only generic "Something went wrong" reaches Telegram [1 comments, 2 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Bot agent on the Claude-CLI backend (claude-cli/claude-sonnet-4-6) stalls for ~3 minutes during a file Read tool call against a wrapper path and surfaces only the generic "Something went wrong" message to Telegram, with no per-tool-call entries in the gateway log.

Steps to reproduce

1. From a Telegram client, send /Users/ali/.alimango/bin/ops/alimango_help.sh to the bot.
2. Bot replies: ⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.
3. /new then a fresh greeting → bot replies normally.
4. Repeat the wrapper send → same generic error.
5. ps aux during processing shows multiple openclaw worker processes burning 80–116% CPU, then dropping to idle without producing a Telegram reply other than the generic error.
6. The wrapper itself is not the problem — local shell execution outside the agent succeeds instantly: $ /Users/ali/.alimango/bin/ops/alimango_help.sh prints the expected wrapper-list output.

Expected behavior

The bot agent should either:

• run the approved wrapper and return stdout to Telegram, or
• fail fast with a clear tool error explaining why the file read / exec is not allowed.

It should not run for ~3 minutes and surface only the generic Telegram error.

Actual behavior

The Telegram message reaches the agent and starts a Claude CLI backend turn. The turn stalls/fails during tool handling before any wrapper exec is attempted — specifically during a file Read call against the wrapper path. Telegram receives only the generic "Something went wrong" message.

OpenClaw version

2026.4.23 (a979721)

Operating system

macOS 26.3.1 (arm64) — M1 Mac mini

Install method

npm-global (/opt/homebrew/lib/node_modules/openclaw); node 25.9.0

Model

claude-cli/claude-sonnet-4-6

Provider / routing chain

Telegram (polling) → OpenClaw gateway (local loopback ws://127.0.0.1:18789) → claude-cli backend (Claude Code CLI v2.1.123 subprocess at /opt/homebrew/bin/claude) → Anthropic API. Auth profile: anthropic:claude-cli, type oauth, status expiring (~8h runway). tools.exec.host = node is configured for downstream wrapper-exec via the paired node host's system.run, but the failure occurs in the agent's tool-handling phase before any exec is reached.

Additional provider/model setup details

• Single agent main, single Telegram session agent:main:telegram:direct:<chat>
• agents.defaults.model.primary = claude-cli/claude-sonnet-4-6
• tools.exec.host = node
• Anthropic auth: anthropic:claude-cli profile, type oauth, captured via openclaw models auth login --provider anthropic --method cli after claude /login on the same host
• Node: paired, connected, caps browser, system, commands system.run, system.run.prepare, system.which, browser.proxy
• Exec approvals are configured for 6 exact wrapper paths under /Users/ali/.alimango/bin/ops/alimango_*.sh
• openclaw plugins doctor → "No plugin issues detected"
• Gateway service running, reachable, admin-capable
• Bot's claude subprocess starts with --strict-mcp-config --mcp-config <path>/mcp.json --allowedTools mcp__openclaw__* (so the MCP loopback bridge is set up)

Logs, screenshots, and evidence

OpenClaw session record for `agent:main:telegram:direct:<chat>`:
- `status: failed`
- `runtimeMs: 191786`
- `modelProvider: claude-cli`
- `model: claude-sonnet-4-6`
- `authProfileOverride: anthropic:claude-cli`

Claude transcript `~/.claude/projects/-Users-ali--openclaw-workspace/<session>.jsonl`:
- Telegram message was received and dequeued.
- Claude read `skills/alimango/SKILL.md`.
- Claude attempted `Read` on `/Users/ali/.alimango/bin/ops/alimango_help.sh`.
- No subsequent tool result or assistant final response appears before OpenClaw marks the run failed.

The wrapper path is outside the OpenClaw workspace (`/Users/ali/.openclaw/workspace`) but inside the same user account and is locally readable/executable.

OpenClaw main gateway log (`/tmp/openclaw/openclaw-YYYY-MM-DD.log`) does NOT contain `agent/cli-backend`, `claude live session`, or per-tool-call entries for the failed turns — only generic config-reload and bonjour-warning noise.

Earlier in this session, before changing `tools.exec.host` from `gateway` to `node`, gateway logs showed repeated:
`gateway/ws ⇄ res ✗ nativeHook.invoke errorCode=INVALID_REQUEST errorMessage="native hook relay not found"`
The gateway never logs a "relay registered/ready" line. Unclear what is supposed to register the native hook relay subsystem.

Impact and severity

• Affected: single-user M1 Mac mini install; Telegram channel; any agent-routed wrapper-exec attempt.
• Severity: blocks workflow — the entire intended use case (Telegram bot executes approved ops wrappers and returns stdout) is unusable.
• Frequency: always — every wrapper-path message reproduces the same ~3-minute stall and generic reply.
• Consequence: ~191s of agent runtime + multi-process CPU burn per failed attempt; user has no signal beyond a generic error and must consult Claude transcripts to learn the failure occurred during a Read tool call.

Additional information

Possibly related:

• #72338 — "Gateway CPU spin causes Telegram replies to stall and status probe to time out" — same high-CPU-then-stall pattern at agent-turn granularity.
• The CLI-backends doc explicitly states tools are not injected directly into CLI backends and recommends ACP Agents for full tool support including system.run. The Read tool stall observed here suggests the MCP loopback bridge has a tool-call edge case (file Read against a path with no further file-system context) that surfaces as a silent ~3-minute stall rather than a clean tool-error or fast denial.

Open questions for maintainers:

1. Is the Claude-CLI backend's MCP loopback expected to handle Read tool calls against arbitrary paths reliably, or is Read only expected to work within a workspace scope?
2. Is the documented "ACP Agents" path the only intended route for Telegram-bot → wrapper-exec chains on current versions, or is the CLI-backend route supposed to support it?
3. What registers the "native hook relay" subsystem the gateway expects on nativeHook.invoke? Is this an automatically-registered component or does it require a separate plugin install?

Happy to attach more logs / config snippets / a redacted openclaw.json / Claude transcript excerpt if useful.