Claude CLI Issues

[magic crown]

Version:
OpenClaw 2026.4.26 (be8c246)

Environment:

• Linux gateway host, Node 22.22.2
• Gateway is reachable locally on the configured gateway port.
• Gateway is NOT managed by working systemd user service in this setup. openclaw gateway restart reports service disabled/systemd unavailable even though the gateway process is running.
• Gateway is supervised externally by a local watchdog/cron-style process that restarts it if it goes down.

Main issues:

1. Telegram direct chat sometimes receives queued/system exec completion messages/noisy tool output.
2. Claude/Opus routing is unstable. Default is intended to be Claude Opus via claude-cli, but OpenClaw sometimes marks anthropic:claude-cli disabled as billing / extra usage and auto-fallback pins the Telegram session to openai-codex/gpt-5.5.
3. Restart guidance is unclear for manually-supervised gateway/watchdog setups: openclaw gateway restart does not restart the live gateway process here.

Config change tried from a similar case:
{
"surfaces": {
"telegram": {
"silentReply": {
"direct": "allow"
}
}
}
}

Questions:

1. Is it expected that a Claude CLI extra-usage / large-context failure is classified as billing and disables the claude-cli profile for ~5 hours?
2. Should that also persist an auto fallback model override into the Telegram session, causing later replies to stay on Codex?
3. For a gateway supervised by a local watchdog/cron process rather than systemd, what is the recommended safe restart method after config changes?
4. Is surfaces.telegram.silentReply.direct = "allow" the correct fix for queued/system exec completion messages leaking into Telegram direct chat?

[timid vine]

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

[swift gorge]

I checked the docs/source — short version:

1. Yes-ish, but this smells inconsistent.
   Extra usage is required for long context requests is currently matched as a billing-shaped failure in the generic classifier, and billing disables start at 5h. But the Anthropic troubleshooting doc describes the exact HTTP 429 rate_limit_error: Extra usage... case as a long-context eligibility/rate-limit issue. If the original error really included 429 rate_limit_error and still became billing, that’s worth filing with redacted logs: https://github.com/openclaw/openclaw/issues
   Docs: https://docs.openclaw.ai/gateway/troubleshooting#anthropic-429-extra-usage-required-for-long-context

2. Yes, auto fallback pinning is currently expected.
   When a configured primary fails and fallback succeeds, OpenClaw persists modelOverrideSource: "auto" so the session doesn’t hammer the known-bad primary every turn. That can make the Telegram session keep using openai-codex/gpt-5.5. Clear it with a bare /new or /reset in that Telegram chat.
   Docs: https://docs.openclaw.ai/concepts/model-failover

3. For watchdog-managed gateways: restart through the thing that owns the process.
   Don’t assume openclaw gateway restart restarted anything if it reports systemd/service unavailable. Safest options:

   • use the watchdog/supervisor’s restart command, or
   • gracefully signal the verified gateway PID (SIGUSR1 for in-process restart if enabled; otherwise SIGTERM and let watchdog restart it).

   Avoid openclaw gateway --force while the watchdog is active unless you’re deliberately reclaiming a stale port, because it can race the supervisor. Also set OPENCLAW_SERVICE_REPAIR_POLICY=external for doctor/repair flows when an external supervisor owns lifecycle.
   Docs: https://docs.openclaw.ai/cli/gateway and https://docs.openclaw.ai/cli/doctor

4. surfaces.telegram.silentReply.direct = "allow" is valid, but scoped.
   It’s the right knob for suppressing bare NO_REPLY / clean empty / reasoning-only direct-chat fallback chatter:

{
  surfaces: {
    telegram: {
      silentReply: {
        direct: "allow"
      }
    }
  }
}

But it is not a blanket “hide all exec/tool completion output” switch. If the messages are real tool-progress previews, use channels.telegram.streaming.preview.toolProgress: false or streaming.mode: "off". If raw internal completion text is leaking, that’s likely a bug/routing issue, not just silent-reply policy.

[magic crown]

So is this then theoretically an issue with using a Claude subscription rather than a config / openclaw issue?