OpenClaw Issue Draft: fixed workbench reuse succeeds, but timeout / announce can return stale previous-round results

Suggested title

[Bug]: sessions_send into reused fixed workbench succeeds and executes in-place, but timeout / announce may surface stale previous-round results

Summary

When reusing an existing agent workbench session via sessions_send(sessionKey=...), the target session can successfully receive the new user message, execute the new task in the same session, and produce a correct new final answer in its transcript. However, the runtime timeout / completion announce sent back to the caller may incorrectly contain stale content from the previous round.

This creates a misleading failure mode:

• session reuse actually works
• no new session is created
• the target transcript contains the new task and new answer
• but the caller sees an old result and may incorrectly conclude that reuse failed

Environment

• OpenClaw local install via npm package path /opt/homebrew/lib/node_modules/openclaw
• macOS arm64
• Control UI / webchat surface
• tools config includes:
  • tools.sessions.visibility = "all"
  • tools.agentToAgent.enabled = true
  • tools.agentToAgent.allow includes main, pm, frontend, etc.

Repro steps

1. Create two reusable workbench sessions for child agents (for example pm and frontend).
2. First round: dispatch a task into each workbench, e.g. "today's international headlines".
3. Second round: dispatch a different task into the same existing sessionKey via sessions_send, e.g. "today's AI headlines".
4. Observe that:
   • no new session key is created
   • the target .jsonl transcript receives the second-round user message with provenance.kind = inter_session
   • the target transcript continues executing and eventually produces a correct second-round final answer
   • but timeout / announce returned to the caller may contain the first-round result instead of the second-round result

What we verified from transcripts

We verified this directly from local session JSONL logs.

Reused session behavior is correct

• original session keys remained unchanged
• second-round user messages were appended into the original transcript
• second-round tasks executed successfully in-place
• no extra session key was created for the second round

Wrong part is the caller-facing returned content

The stale content appears in timeout / announce delivery, not in the target transcript.

Example symptoms

• caller sends: "第二轮任务：查今天的热点 AI 新闻"
• target transcript stores that exact message
• target transcript later produces correct AI-news output
• caller receives old first-round "international headlines" content instead

Expected behavior

The caller-facing timeout / announce path should reflect either:

1. the latest actually produced result for the current message, or
2. a neutral timeout status without replaying stale previous-round content

It should never surface previous-round answer content as if it were the current round result.

Actual behavior

The current round may time out at the caller side while still later surfacing a stale previous-round answer payload, even though the target transcript already shows the new round was accepted and executed.

Impact

This makes reusable workbench sessions look broken even when they are functioning correctly. It also misleads operators into thinking they need to respawn new sessions, which can worsen session explosion.

Extra note

This bug is especially confusing because it appears only after the permissions/configuration chain has already been fixed. In our case:

• visibility problems were resolved
• agentToAgent.allow problems were resolved
• fixed workbench reuse then started working
• but timeout / announce still falsely suggested failure