Bug: Session not automatically reset after lock failure

[arun-gupta]

Description

When the Telegram bridge fails with a session file lock error #831, the session is left in a broken state with accumulated "Tool not found" errors in the conversation history. On the next message, the agent resumes that corrupted context and behaves erratically (e.g., responding to "Hello" with "Let me open a new shell")

Reproduction Steps

1. Set up the Telegram bridge with nemoclaw start
2. Send a message that triggers the session lock error (code 255)
3. Send another message — the agent responds with unrelated tool invocations instead of a normal reply

Expected behavior:

After a lock failure, the bridge should either start a fresh session or discard the broken context before the next message.

Actual behavior:

The broken context persists and corrupts subsequent responses.

Workaround:

nemoclaw my-nemoclaw connect
rm /sandbox/.openclaw-data/agents/main/sessions/*.jsonl
rm /sandbox/.openclaw-data/agents/main/sessions/sessions.json
exit

Environment

• NemoClaw: v0.1.0
• OpenShell: 0.0.14
• OpenClaw: 2026.3.11 (29dc654)
• macOS: Apple M4 Pro (arm64)
• Container runtime: Docker Desktop
• Provider: nvidia-nim (NVIDIA Endpoint API)

Debug Output

Logs

Checklist

• I confirmed this bug is reproducible
• I searched existing issues and this is not a duplicate

[wscurran]

✨ Thanks for submitting this issue with a detailed summary, it addresses a bug with the session not being automatically reset after a lock failure, which could be related to the Telegram integration or session management.

---

Possibly related open PRs:
#862 fix: auto-reset telegram bridge session after lock failure,
#860 fix: queue telegram bridge messages per chat to prevent session lock contention,
#750 fix(setup-spark): clarify that onboard must be re-run after setup (fixes #738)

[dknos]

Related to #831 — clearing lock files at startup prevents this state entirely

The broken session state described here is a downstream effect of the lock failure in #831. If the lock files are cleared before the bridge starts, the agent never enters this broken state.

See our workaround in #831 — running find /sandbox/.openclaw-data -name "*.lock" -delete via SSH before starting any bridge process prevents both the initial lock failure and this residual broken session state.

If you're already in the broken state (accumulated "Tool not found" errors), deleting the session files directly resolves it:

SSH_CONF=$(mktemp)
openshell sandbox ssh-config my-assistant > "$SSH_CONF"
ssh -T -F "$SSH_CONF" "openshell-my-assistant" \
  'rm -f /sandbox/.openclaw-data/agents/main/sessions/*.lock
   rm -f /sandbox/.openclaw/agents/main/sessions/sessions.json'
rm -f "$SSH_CONF"

The agent will start a fresh session on the next message. Note: this clears conversation history, so back up sessions.json first if you want to preserve it.