OpenClaw closes delivery pin lifetime hole across revocations and retries

OpenClaw merged PR #151244 on September 18, 2026, rechecking delivery ownership before executing post-delivery pin requests in channel adapters. Under previous behavior, the synchronous assertion verifying message delivery authorization was evaluated when the initial send was dispatched, but discarded before the downstream pin hook fired. If a delivery owner was revoked immediately after sending, or if the request stalled during an account throttle wait, connection fallback, or HTTP 429 backoff, the Telegram adapter could still execute the pin on an unauthorized or revoked conversation. The fix forwards the core assertion callback directly into Telegram's request guard and ensures that revoked owners cleanly abort pending pins. In tandem, PR #150734 advances agent access to paired-node workspaces without copying files locally, relying on service-level authentication rather than broad interactive shell permissions.

The facts

- PR #151244 was merged into openclaw/openclaw on September 18, 2026, resolving issue #151190. - The fix passes the synchronous assertDirectAdapterHandoff callback to Telegram's assertPlatformSendAuthorized guard before any pin request is transmitted. - Prevents orphan pin requests from firing during HTTP 429, HTTP 421, or connection fallback retry loops after an owner closure. - Distinguishes optional pin failures, which leave the message marked as successfully delivered, from required pin failures, which retain the accepted receipt in partial failure without queue resending. - Concurrent PR #150734 allows agents to read and edit documents on paired nodes using existing file transfer channels without maintaining local duplicate workspaces.

Why it matters

In agent chat operations, message delivery and post-delivery channel actions are distinct operations with different latency profiles. When an agent sends a message and subsequently requests a pin, that pin request can be delayed by platform rate limits or transport retries. If the agent's delivery owner is revoked or the session is cancelled while the pin is waiting, firing that pin anyway violates authorization boundaries and leaks execution into zombie channels. Ensuring that ownership assertions survive until the final platform API call settles makes channel lifecycles strictly consistent across asynchronous network edges.

Current

Inspected on 2026-09-18. The OpenClaw stable-channel baseline is v2026.9.4 published 2026-09-11T03:46:22Z. The primary source was merged 2026-09-18T00:55:24Z when captured. Mainline merges, open proposals and packaged releases are distinct availability states; the release baseline does not establish that a proposal has shipped.

Evidence

Primary evidence: openclaw/openclaw PR #151244 (https://github.com/openclaw/openclaw/pull/151244). Supporting context: openclaw/openclaw issue #151190 (https://github.com/openclaw/openclaw/issues/151190); openclaw/openclaw PR #150734 (https://github.com/openclaw/openclaw/pull/150734). The source bodies and linked context were inspected. Test results quoted from contributors remain attributed reports, not independently reproduced experiments.

Operator take

Chat adapters often treat auxiliary actions like pinning, typing indicators, and reactions as fire-and-forget side effects. This fix demonstrates why auxiliary actions must respect the same cryptographic or token-backed ownership assertions as the initial message payload. Operators deploying OpenClaw across Telegram and multi-channel bots should verify that retry policies cannot outlive session revocation, particularly when dealing with shared or tenant-isolated chat infrastructure.

Caveat

The delivery assertion check prevents new pin attempts after revocation, but pin requests already accepted by Telegram's HTTP edge will settle according to Telegram's platform timing. Required pin failures preserve accepted receipts in partial failure states, requiring application-level handling to avoid duplicate message retries.