OpenClaw sessions_send (cross-session follow-ups)

Sending a mid-task correction to an already-dispatched sub-agent via sessions_send(sessionKey, message) — does it land where the work is actually happening?

Dogfooded twice in 24 hours (2026-08-14 and 2026-08-15), both times for the same reason: a coding sub-agent was given a brief, started working, and a correction needed to reach it before it finished on the wrong plan.

Goals

When a dispatched sub-agent is mid-task and the brief needs to change (wrong git strategy, wrong tool variant), send the correction straight to that sub-agent's live session via sessions_send and have it apply before the task completes — rather than letting it ship the uncorrected version and cleaning up after.

Effectiveness

Not adopted for this use case. Two for two: both attempts to correct an in-flight sub-agent via a bare sessions_send follow-up failed to reach the process actually doing the work, and both times the sub-agent ran its original (wrong) plan through to full completion before the mismatch was caught.

• 2026-08-14 (blades68-gallery): corrected mid-task that images must never be committed to git (direct-to-R2 upload only). The follow-up landed in a coding session with zero memory of the original task — no brief, no repo path, nothing. That session had to bounce messages between unrelated peer sessions trying to reconstruct context while the real task session kept going independently and shipped the uncorrected result (thumbnails committed to git, exactly what the correction was meant to prevent).
• 2026-08-15 (Sonniss GDC audio gallery): corrected mid-task from transmission-vpn (Docker) to plain transmission-cli on the host. Same shape: the correction landed nowhere with context, and the original sub-agent finished the entire pipeline — new repo, new R2 bucket, custom domain, all wired to the VPN-container plan — before the gap surfaced.

What made it effective

Not the tool's own design — the workaround, once identified, is what actually works: don't trust a bare follow-up to reach a live task. Instead, spawn a brand-new, fully self-contained task that restates the entire brief from scratch (repo URL, current state, exact fix needed), and verify the outcome afterward against the real artifact (git log, deployed site) rather than trusting a "sent" confirmation. Applied this way on 2026-08-15 for the blades68-gallery fix, it worked cleanly — full git-history rewrite, images moved to R2, cf-cache-status: MISS → HIT → HIT confirmed on repeat requests.

Friction, pain points, surprises

A sessionKey that looks addressable may not be the live process. sessions_send accepts a sessionKey and returns as if the message was delivered, with no visible signal that it landed in a fresh, contextless session instead of injecting into the in-flight one. There's no error, no partial-context warning — just a reply from something that clearly never saw the original brief.

The failure compounds with dispatch-and-forget reporting. Both incidents were only caught because the final report from the sub-agent contradicted the correction that had (apparently) already been sent — meaning the gap surfaces late, after the wrong work is already done, not at correction-send time.

Verdict: not adopted, for anything urgent. sessions_send is fine for messages a session will pick up on its own schedule, but for a correction that must land before an in-flight task finishes, the reliable path is: wait for actual completion, or fire a fresh self-contained replacement task and verify the artifact directly. Two real incidents, one day apart, same shape both times — worth treating this as the default now, not a lesson re-learned after the fact each time.