Symptom

Telegram outbound messages from OC get rate-limited / throttled by some ISPs after a sustained run, while a similarly-configured bun-based Telegram plugin running on the same machine has zero throttle problems.

Concretely:

• OC sends Telegram API requests with User-Agent: undici (no version) — the Node.js global fetch default
• A bun-based plugin sends User-Agent: Bun/1.3.12 and does not get throttled
• Smoking-gun differentiator was UA. JA3 TLS fingerprint is a contributor but UA is dominant: it's a low-cardinality, easily-fingerprinted string that some consumer-ISP layer-7 inspection rules block aggressively.

Diagnosis

The OC Telegram extension uses grammy + undici 8.2.0. When resolveTelegramFetch (in extensions/telegram/src/fetch.ts, built to dist/fetch-*.js's resolveTelegramTransport / resolveTelegramFetch) wraps the global fetch, it never overrides the User-Agent header. undici's default User-Agent: undici flows out on every request.

The relevant build artifact in the installed package (v2026.5.10-beta.1):

• dist/fetch-DBz2-saB.js:441-628 — resolveTelegramTransport / resolveTelegramFetch
• dist/send-C7GFnTds.js:485-503 — resolveTelegramClientOptions passes the wrapped fetch into the grammy Bot client

Reproduction

1. Run OC's Telegram channel for an extended period on an ISP that does layer-7 UA-based throttling (in our case a consumer UK ISP)
2. After 1-N hours, getUpdates / sendMessage requests start returning network errors / hang, while the same machine's bun-based Telegram plugin keeps flowing
3. Capture outbound TLS to api.telegram.org — UA in the request is bare undici

Suggested fix

In resolveTelegramTransport, wrap the returned fetch so every outbound request forces:

init.headers['User-Agent'] = `OpenClawBot/${pkgVersion}`;

(or any innocuous versioned UA, e.g. mimic the bun client's Bun/<version> for parity).

Optionally also strip the obvious "Node fetch" giveaway headers when present:

• Sec-Fetch-Mode
• Accept-Language: *

Implementation sketch (inside resolveTelegramTransport, after const sourceFetch = ... is computed):

const FORCED_UA = `OpenClawBot/${require("../../package.json").version}`;
const originalSourceFetch = sourceFetch;
const stampedSourceFetch = (input, init) => {
  const next = { ...(init || {}) };
  const h = new Headers(next.headers || {});
  h.set('User-Agent', FORCED_UA);
  h.delete('Sec-Fetch-Mode');
  if (h.get('Accept-Language') === '*') h.delete('Accept-Language');
  next.headers = h;
  return originalSourceFetch(input, next);
};
// then use stampedSourceFetch in place of sourceFetch below

Both sourceFetch direct calls and the per-attempt sourceFetch(input, withDispatcherIfMissing(...)) path need to go through the stamped wrapper.

Workaround for now

We're shipping a local patch via a per-install patcher script that idempotently sed-injects the UA-forcing wrapper into the built dist after each OC install/update. Happy to upstream a proper PR if there's interest — wanted to file the issue first so the design constraints (versioned UA, no header-strip surprises for users with custom apiRoot proxies, etc.) can be discussed.

Environment

• OC v2026.5.10-beta.1
• Node v22.22.2
• macOS arm64
• ISP: UK consumer broadband with layer-7 UA inspection