ZeroClaw fragments Telegram memory by reply thread

zeroclaw-labs/zeroclaw issue #10237 is the inspected primary source: “[Bug]: Telegram reply-threads fragment conversation memory into per-thread history buckets.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- zeroclaw-labs/zeroclaw issue #10237 was created 2026-08-22T00:21:44Z and was open at inspection; its title is “[Bug]: Telegram reply-threads fragment conversation memory into per-thread history buckets.” - zeroclaw-labs/zeroclaw issue #10231 was created 2026-08-21T22:33:34Z and was open at inspection; its title is “[Bug]: Channels supervisor retries stale configuration.” - zeroclaw-labs/zeroclaw issue #10225 was created 2026-08-21T21:17:56Z and was open at inspection; its title is “[Bug]: ZeroCode RPC sessions cannot reach configured channels through channel-backed tools.” - The repository reported 32633 stars, 793 open issues, default branch master, and last push 2026-08-21T23:27:39Z. - The latest tagged-release baseline checked was v0.8.4 published 2026-08-02T21:00:00Z.

What changed

zeroclaw-labs/zeroclaw issue #10237 reports: Affected component Channels — Telegram (conversation history keying) Severity Medium — lost multi-turn context (functional; no data loss or security impact) Current behavior Conversation history is bucketed per history key computed in conversation_history_key (crates/zeroclaw-channels/src/orchestrator/mod.rs:618). With the default Sender conversation scope the key is: so any non-empty thread_ts forks the key. There is an explicit Matrix carve-out that treats thread_ts as a delivery anchor rather than a topic boundary (mod.rs:623), but **no equivalent for Telegram**. The Telegram parser (crates/zeroclaw-channels/src/telegram.rs:2591-2601, ChannelMessage at:2644) derives thread_ts (and the:tid suffix on reply_target) from message_thread_id **unconditionally** — without checking is_topic_message. Telegram sets message_thread_id not only for genuine forum topics but also for reply-threads in supergroups. As a result, when a user **replies** to one of the bot's messages, that turn lands in a separate, per-thread history bucket, isolated from the main chat conversation and from other reply-threads. A plain message or an @-mention (no message_thread_id) uses the base key and keeps context — so replies appear to "forget" the conversation while normal messages do not. Observed on a live self-hosted instance: for one supergroup + one sender, history is split across a base bucket and several per-thread buckets, e.g. (identifiers redacted): Each reply-thread is its own short-lived, empty-on-arrival memory. Expected behavior Replying to the bot should continue the same conversation and share its history

zeroclaw-labs/zeroclaw issue #10231 reports: Affected component runtime/daemon Severity S1 - workflow blocked Current behavior The channels component can repeatedly retry a stale configuration after an enabled, manually created agent and its referenced model-provider entry are both valid on disk. In this reproduction, the supervisor repeatedly failed with agents.ox.model_provider even though the saved agent referenced opencode.ox and that provider entry contained a non-empty model and credential. A full daemon restart cleared the loop without another config edit. The same saved agent and provider then completed RPC turns successfully. The channels supervisor captures a cloned config before entering its retry loop, so retries continue using the failed generation rather than resolving the current config. Expected behavior A supervised component retry should resolve the current config generation. Once the referenced provider entry becomes valid, channels should recover without requiring a full daemon restart. If configuration generations are intentionally immutable, applying a new generation should replace or restart the component supervisor atomically. Steps to reproduce Impact Affected users: operators changing provider or agent configuration while channels are supervised. Frequency: the retry loop persisted for more than ten minutes and cleared only after a full daemon restart. Consequence: configured channels remain unavailable even after the saved configuration becomes valid. Logs / stack traces ZeroClaw version 0.8.4, dogfood head 228cf35df7 based on upstream commit 9f99ced39. The relevant daemon-supervisor and channel-resolution

zeroclaw-labs/zeroclaw issue #10225 reports: Affected component zerocode/tui Severity S1 - workflow blocked Current behavior An agent running through a ZeroCode Code/RPC session cannot use configured external channels through channel-backed tools. The daemon can start and actively poll an enabled Git channel, but git_forge sees only the synthetic RPC back-channel: The same request works far enough to reach the tool, so this is not a missing-tool or agent-allowlist failure. Source inspection shows that the RPC session paths construct the agent, then register only rpc; unlike the dashboard WebSocket path, they never seed configured channels into the agent's late-bound tool handles. The same omission exists in both new-session construction and rehydration. Expected behavior ZeroCode Code/RPC sessions should retain the rpc back-channel for conversation-scoped interaction while also making enabled, agent-authorized configured channels such as git.github available to channel-backed tools. Steps to reproduce Impact Affected users: ZeroCode users invoking tools that route through configured external channels. Frequency: Always for the reproduced Code/RPC session path. Consequence: git_forge is unusable from ZeroCode even though the Git channel is correctly configured, authenticated, running, and authorized for the agent. Other tools backed by the same late-bound channel handles may have the same reachability gap. Logs / stack traces ZeroClaw version v0.8.4; the same RPC wiring is present on current master at 90531f07bd8c493eabd38205377143559ea1bfde Rust version rustc 1.97.0 (2d8144b78 2026-07-07) Operating system macOS 26.6.1

Why it matters

Channel identity is split across history, configuration generation and tool reachability. Users experience all three as a bot that forgot, ignored a valid fix or could not reach a configured service. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.

Current

The primary record was open when captured on 2026-08-22. The tagged-release baseline was v0.8.4 published 2026-08-02T21:00:00Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/zeroclaw-labs/zeroclaw/issues/10237. Supporting records are https://github.com/zeroclaw-labs/zeroclaw/issues/10231 and https://github.com/zeroclaw-labs/zeroclaw/issues/10225. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Separate forum topics from ordinary replies, resolve the current config generation on retry, and seed authorized configured channels into both new and rehydrated RPC sessions. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.