openclaw - 💡(How to fix) Fix sessions_spawn: task prompt appears truncated/lost for some subagent runs (8 input tokens for 2k-char task) [1 participants]

Summary

When spawning subagents via sessions_spawn (runtime: "subagent", mode: "run"), the task prompt appears to be truncated or not delivered to the child process in some cases. The child completes "successfully" but produces output that is clearly not based on the task description — either hallucinated word-salad or a generic regurgitation of the spawn-time context.

Smoking gun

A spawn I made today with a ~2000-character task description came back with the following stats line:

Stats: runtime 2m5s • tokens 2.0k (in 8 / out 2.0k) • prompt/cache 40.6k

Eight input tokens for a 2000-character task is impossible if the task body was actually delivered to the model. The child appears to have been spawned with only the metadata envelope (label, model name, etc.), not the task field.

The output in that case was a raw dump of the current source file (which the child happened to have access to via prompt/cache 40.6k — the parent context bleeding through), not analysis of the requested commit diff.

Reproduction

I ran 7 spawns today across two models (5× github-copilot/gpt-4o, 2× claude-sonnet-4.6). All 7 produced shallow / hallucinated output. Tasks ranged from 1500 to 3500 characters, all with explicit deliverables, hard constraints, and time budgets.

Sample failure modes:

• gpt-4o: 19–26 second runtime, ~1.0–1.4k output tokens regardless of task complexity. Output is a plausible-sounding summary that name-checks terms from the task but contains no evidence of file reads, no specific line numbers, no concrete state setup.
• sonnet-4.6: 24s–2m5s runtime. One returned a raw source dump (the 8-input-tokens case above). Another returned literal word salad: "Investigating golblack-hop tightened APPROVAL quarantines / MAX777 forwarded envelopes netfront hookgroups triple proving parity context limits bridge-await tokens botnet reducers Meta shaping scale-back future future-positive veccoins".

Why this matters

Subagents that fail silently with "completed successfully" status corrupt the parent's decision loop. The parent has no way to distinguish a real kill from a hallucinated one without re-doing the work inline, which defeats the purpose of spawning.

For my use case (bug bounty hunting), I cleanly killed 16 hypotheses inline today using read / exec / forge test, but every single one of the 7 spawned subagents had to be discarded. ~30k subagent tokens wasted.

Suggested investigation paths

1. Inspect the payload that sessions_spawn actually sends to the child runtime when task is long. Compare bytes-on-the-wire vs the task argument.
2. Check whether sandbox: "require" (default for subagent runtime) has a payload size cap somewhere in the bridge.
3. Audit the lightContext codepath — even if not requested, something may be activating it for mode: "run" spawns.
4. Add an assertion in the spawn pipeline: if the child's first observed input tokens < len(task) / 4, log a warning and surface it back to the parent via the completion event.

Workaround

For now I'm doing all code-analysis work inline in the parent session. Subagents remain useful for shell-only / web-fetch tasks where the work isn't gated on the task description being received intact.

Environment

• OpenClaw main agent, model github-copilot/claude-opus-4.7
• Workspace: /home/yin/.openclaw/workspace
• Channel: webchat
• Date: 2026-04-23