Skip to content

fix: prevent context bleed in thread/topic sessions#53489

Open
ttfnrob wants to merge 1 commit intoopenclaw:mainfrom
ttfnrob:fix/thread-session-context-isolation
Open

fix: prevent context bleed in thread/topic sessions#53489
ttfnrob wants to merge 1 commit intoopenclaw:mainfrom
ttfnrob:fix/thread-session-context-isolation

Conversation

@ttfnrob
Copy link
Copy Markdown

@ttfnrob ttfnrob commented Mar 24, 2026

Problem

Thread and topic sessions (Telegram forum topics, Slack threads, Discord threads) were inheriting the full parent group session context via createBranchedSession(). This caused new threads to see orphaned assistant messages and tool results from unrelated conversations in the same group — but NOT the user messages that triggered them.

The resulting asymmetric context is confusing, breaks isolation, and makes it impossible to start clean conversations via threads.

Reproduction steps (as documented in #758):

  1. Have a multi-turn conversation in a group channel — agent makes tool calls, produces assistant responses
  2. Start a new thread/topic in the same group
  3. In the new thread, ask what context the agent sees
  4. Observe it contains assistant messages and tool results from the parent session that it should not have

Root Cause

forkSessionFromParentRuntime() in session-fork.runtime.ts calls manager.createBranchedSession(leafId) which copies the parent transcript into the thread's JSONL file. The pi-mono branching logic carries assistant messages and tool results but not the user messages that triggered them — producing asymmetric, leaked context in every new thread.

Fix

Write a clean session file for thread/topic forks instead of branching from the parent transcript. Thread sessions are already isolated by:

  • Their session key (:topic:/:thread: suffix)
  • Their own dedicated JSONL file (<sessionId>-topic-<threadId>.jsonl)

The parentSession header is preserved in the new file for audit/lineage purposes. Each thread now starts with a clean slate — only workspace bootstrap files (SOUL.md, AGENTS.md, etc.) provide shared context, which is the correct behaviour.

Testing

Related

Thread and topic sessions were inheriting the full parent group session
context via createBranchedSession(). This caused new threads to see
orphaned assistant messages and tool results from unrelated conversations
in the same group — but NOT the user messages that triggered them.
The resulting asymmetric context is confusing and breaks session isolation.

The fix: write a clean session file for thread/topic forks instead of
branching from the parent transcript. Thread sessions are already isolated
by their session key (:topic:/:thread: suffix) and their own JSONL file.
The parentSession header is preserved for audit/lineage purposes.

Fixes openclaw#758
Reported also on Slack and Telegram forum topics.

Co-authored-by: Protostar <protostar@openclaw>
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Mar 24, 2026

Greptile Summary

This PR fixes context bleed in thread/topic sessions (Slack threads, Telegram forum topics, Discord threads) by replacing createBranchedSession() — which copied the parent transcript and produced asymmetric context — with a direct writeFileSync that writes only a clean header record. The parentSession field in the header preserves the lineage link without pulling in any transcript content.

  • The old code passed leafId to createBranchedSession, which copied assistant messages and tool results but not the user messages that triggered them, leaving every new thread with confusing orphaned context.
  • The new code creates a UUID-backed JSONL file with just the session header, cwd, and a parentSession pointer. Thread isolation is already enforced by the :topic:/:thread: session key suffix, so no additional gating is needed.
  • The flag: "wx" exclusive-create flag on writeFileSync is correct — it prevents clobbering an existing file while the UUID collision probability is negligible.
  • Error handling is unchanged: any failure silently returns null, consistent with the pre-existing pattern.
  • No other call sites are affected; base group sessions continue to use their own paths.

Confidence Score: 5/5

  • This PR is safe to merge — the fix is targeted, well-scoped, and correctly addresses the root cause without affecting any other session paths.
  • Single-file change with a clear, correct fix. The new logic is simpler than what it replaces, the comments explain the reasoning thoroughly, and the parentSession lineage field is preserved. No regressions expected for base group sessions. No unhandled edge cases introduced.
  • No files require special attention.

Reviews (1): Last reviewed commit: "fix: prevent context bleed in thread/top..." | Re-trigger Greptile

@hyperlook
Copy link
Copy Markdown

Feishu topic mode (group chats with chat_mode=topic) has the same context bleed issue. When creating a new topic thread in a Feishu group, the thread session inherits parent group context via createBranchedSession(), causing orphaned assistant messages and tool results from unrelated conversations to appear in the thread. This breaks session isolation for Feishu topics, same as #758. Please add Feishu to the affected channels list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: Slack thread sessions have unpredictable context inheritance/bleed

2 participants