Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Failed companion reconnection loop fills session context budget [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#62177•Fetched 2026-04-08 03:08:01
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
bo-bluebo-blue
Participants
bo-bluebo-blue

When the companion app cannot connect to the gateway (e.g., due to a pairing rejection — see #62176), it retries aggressively. The failed connection attempts appear to consume session context budget, leaving insufficient room for the agent's bootstrap content (SOUL.md, MEMORY.md) to be loaded.

This caused Bo and Tom agents to be unable to read their identity/memory files via Telegram — the sessions showed minimal context (appeared full/exhausted) despite no meaningful conversation having occurred.

Root Cause

When the companion app cannot connect to the gateway (e.g., due to a pairing rejection — see #62176), it retries aggressively. The failed connection attempts appear to consume session context budget, leaving insufficient room for the agent's bootstrap content (SOUL.md, MEMORY.md) to be loaded.

This caused Bo and Tom agents to be unable to read their identity/memory files via Telegram — the sessions showed minimal context (appeared full/exhausted) despite no meaningful conversation having occurred.

RAW_BUFFERClick to expand / collapse

Summary

When the companion app cannot connect to the gateway (e.g., due to a pairing rejection — see #62176), it retries aggressively. The failed connection attempts appear to consume session context budget, leaving insufficient room for the agent's bootstrap content (SOUL.md, MEMORY.md) to be loaded.

This caused Bo and Tom agents to be unable to read their identity/memory files via Telegram — the sessions showed minimal context (appeared full/exhausted) despite no meaningful conversation having occurred.

Steps to Reproduce

  1. Trigger a condition where the companion app's WebSocket is repeatedly rejected (e.g., the OS update pairing issue in #62176)
  2. Let it retry for several minutes
  3. Observe that agent sessions (particularly Telegram) show depleted context
  4. Agents report they cannot read MD files forwarded to them

Expected Behavior

Failed WebSocket connection attempts from the companion app should not consume agent session context. Connection-layer failures should be isolated from the agent's conversation/context budget.

Actual Behavior

  • 941 rejected connection attempts accumulated in ~5 minutes
  • Agent sessions showed minimal remaining context
  • Agents could not process files or load bootstrap content
  • Required manual session reset from the companion app to recover

Environment

  • OpenClaw 2026.4.5 (3e72c03)
  • macOS 26.4.0
  • Gateway mode: local, port 18789
  • Context pruning: cache-ttl, 5m TTL, keepLastAssistants: 5

Suggested Fix

Connection-layer retry failures should not be written into agent session context. The reconnection loop should be bounded (exponential backoff, max retries) and its state tracked separately from agent conversation history.

extent analysis

TL;DR

Implement exponential backoff with a bounded retry limit for the companion app's WebSocket connection attempts to prevent aggressive retries from consuming session context budget.

Guidance

  • Review the connection-layer retry mechanism to ensure it does not write failures into agent session context, as this is not the expected behavior.
  • Consider implementing exponential backoff to slow down retries over time, reducing the load on the session context.
  • Introduce a maximum retry limit to prevent indefinite retry loops and bound the reconnection attempts.
  • Verify that the reconnection loop's state is tracked separately from agent conversation history to prevent context exhaustion.

Example

No specific code example is provided due to the lack of detailed implementation details in the issue, but the concept would involve modifying the retry mechanism to include exponential backoff and a max retry count, similar to common practices in WebSocket connection handling.

Notes

The suggested fix implies modifying the companion app's connection retry logic, which may require additional testing to ensure it does not introduce new issues, such as increased latency or failed connections due to the backoff strategy.

Recommendation

Apply a workaround by implementing exponential backoff with a bounded retry limit, as this directly addresses the identified issue of aggressive retries consuming session context, allowing for a more controlled and less resource-intensive reconnection strategy.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#installation#tensor shape#autograd error#model save/load#conversation history

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING