[Bug] Parallel fork subagents experiencing context bleed and hallucinating off-topic responses with zero tool calls

Bug Description
Title: Fork subagent returned a confident, well-formatted answer with zero tool calls, on the wrong topic (context bleed between parallel forks)

What happened:
I launched two independent research subagents in parallel, both via the Agent tool with subagent_type "fork" (Claude Code's "fork yourself into a background agent" primitive), in the same message. Each fork had a
distinct, self-contained research prompt:

• Fork A: research whether OpenClaw's native memory can be disabled or delegated to an external provider.
• Fork B: research and compare architectures for a custom notification channel (Telegram Bot API vs WhatsApp Cloud API vs PWA push vs static dashboard+email).

Fork A completed first, in ~50 seconds, and reported tool_uses: 0 in its usage metadata (no WebSearch/WebFetch calls were made). Despite doing no actual research, it returned a long, well-structured,
confident-sounding answer — complete with a "Recommendation" section and a "Pontos cegos" (blind spots) section in my own house style — but the content was entirely about Fork B's topic (notification channel /
WhatsApp vs custom app), not Fork A's assigned topic (OpenClaw memory). The text was even phrased in first person as if it were me (the orchestrator) continuing the conversation with the user directly ("A pesquisa
está rodando em paralelo... te aviso quando voltar com o achado"), rather than as a subagent returning its own isolated result.

In short: a fork with zero tool calls fabricated a plausible-looking, on-brand answer to a question it wasn't asked, apparently by picking up context/tone from a sibling fork launched in the same batch and continuing
the conversation as if it were the parent orchestrator, instead of executing its own isolated task.

I did not treat this as a valid finding — I have a standing project rule (self-authored, in my global CLAUDE.md) that any delegated-agent result with zero recorded tool calls must be treated as an unexecuted
hypothesis, not a fact, even when the text sounds confident and complete. That rule is exactly why I caught this instead of writing the fabricated content into a permanent decision document. I discarded the result,
relaunched the same fork with an explicit warning about the prior failure and an instruction to make at least 3 real tool calls and stay strictly on-topic, and the retry came back correctly (10 real tool calls,
on-topic, well-sourced).

Why this matters:

• The failure is silent from the harness's perspective: nothing errored, no exception was thrown, the agent "completed successfully." Only manually checking tool_uses in the usage metadata revealed the problem. A

user or a less defensive orchestration flow would have no signal that anything was wrong — the response reads as a legitimate, well-researched answer.

• It's worse than a blank/refused response: an empty or error response is obviously wrong and gets caught; a fluent, on-brand, wrong-topic answer is the kind of failure that slips into a permanent artifact (in my

case, almost a project decision document) unless someone is specifically checking for it.

• This happened specifically when two forks were launched in parallel in the same tool-call batch. I don't have a confirmed root cause, but the pattern (Fork A answering Fork B's question, in the orchestrator's own

conversational voice) suggests some cross-talk or context confusion between sibling forks spawned together, or a fallback where the fork defaults to "continue the conversation naturally" instead of "execute the
isolated task in my prompt" under some condition I haven't isolated.

Repro shape:

1. In a single message, call the Agent tool twice with subagent_type: "fork", each with a distinct, detailed research prompt requiring real tool use (WebSearch/WebFetch).
2. Wait for both to complete.
3. Check tool_uses in each returned usage block, and check whether the returned content actually matches the prompt that specific fork was given.

Evidence:

• Session: Claude Code CLI, 2026-08-26.
• Faulty agent: agentId ab6268431c02cfa6d, task label "Pesquisa memória nativa do OpenClaw" — duration_ms: 49980, tool_uses: 0, subagent_tokens: [REDACTED]
• Sibling agent (correct topic, launched in the same batch): agentId a8c25fe4ce7481154, task label "Pesquisa canal de notificação próprio" — tool_uses: 7, on-topic, well-sourced.
• Retry of the faulty agent (after explicit correction): agentId a7ff0e4d7b610a07d — tool_uses: 10, on-topic, well-sourced, correctly answered the original OpenClaw memory question.

Suggested improvement:
Surface tool_uses (or a "did this agent actually use tools" signal) more prominently in the Agent/fork tool result, or add an automatic sanity check that flags/warns when a subagent given a tool-requiring research
task returns with zero tool …
Note: Content was truncated.