Summary

When a session has a deliveryContext pointing to a Telegram chat/topic, responses generated by the claude-cli backend are sometimes written to the session transcript (.jsonl) but never delivered to Telegram via the delivery-mirror pathway.

Observed behavior

• Session processes user message, generates assistant response via CLI backend
• Response appears in session transcript with provider: "claude-cli"
• No corresponding delivery-mirror message is created
• User never receives the response in Telegram
• Pattern is intermittent — some responses in the same session deliver fine

Conditions that seem to trigger it

• Sessions with long tool-call chains (multiple reads, searches, bash commands)
• Concurrent sessions competing for sessions.json.lock
• Sessions that hit pi-trajectory-flush cleanup timeouts
• After a SessionWriteLockTimeoutError event, subsequent sessions may silently fail delivery

Evidence from logs

[telegram] dispatch failed: SessionWriteLockTimeoutError: session file locked (timeout 10000ms)
[agent/embedded] agent cleanup timed out: step=pi-trajectory-flush timeoutMs=10000

After these errors, multiple sessions continued generating responses that were never delivered.

Expected behavior

The gateway should verify that each assistant response in a session with a deliveryContext is actually delivered. If delivery fails or doesn't fire, it should retry.

Workaround

We've deployed a launchd watchdog that removes stale sessions.json.lock files older than 30 seconds. This prevents the lock contention cascade but doesn't address the silent delivery failure itself.

Environment

• macOS (Darwin 25.4.0)
• OpenClaw installed via npm (global)
• Telegram channel plugin
• CLI backend with claude-opus models