fix: silently ignore streamTo for non-ACP runtime in sessions_spawn (closes #43556) by Br1an67 · Pull Request #47115 · openclaw/openclaw

Br1an67 · 2026-03-15T09:02:46Z

Summary

Problem: The streamTo parameter in the sessions_spawn tool schema is visible to all runtime modes. Schema-following models (e.g. gpt-5.4) automatically include streamTo: "parent" in every call. For runtime=subagent (the default), this triggers a 400 error: "streamTo is only supported for runtime=acp".
Why it matters: Makes sessions_spawn completely unusable for subagent-mode agents using schema-following models (~90% of spawn calls fail).
What changed: Instead of returning an error when streamTo is passed with non-ACP runtime, it is now silently ignored. The parameter only takes effect for runtime=acp.
What did NOT change (scope boundary): ACP runtime streamTo behavior unchanged; resumeSessionId still errors for non-ACP (it's a deliberate user error, not a schema-following artifact).

Change Type

Bug fix

Scope

Linked Issue/PR

Closes Bug: streamTo in sessions_spawn breaks subagent runtime #43556

User-visible / Behavior Changes

sessions_spawn with streamTo parameter and non-ACP runtime no longer returns an error. The parameter is silently ignored.

Security Impact

New permissions/capabilities? No
Secrets/tokens handling changed? No
New/changed network calls? No
Command/tool execution surface changed? No
Data access scope changed? No

Repro + Verification

Steps

Configure an agent with runtime=subagent using gpt-5.4
Have the agent call sessions_spawn — model includes streamTo:"parent" automatically

Expected

sessions_spawn succeeds, streamTo is silently ignored for subagent runtime

Actual

Previously returned 400 error: "streamTo is only supported for runtime=acp"

Evidence

Failing test/log before + passing after
All 9 sessions-spawn-tool tests pass
pnpm tsgo clean (only pre-existing ui type errors)
oxlint clean

Human Verification

Verified scenarios: streamTo with subagent runtime now succeeds; streamTo with ACP runtime still works
Edge cases checked: streamTo=undefined for non-ACP passes through unchanged
What you did NOT verify: runtime end-to-end testing with actual schema-following model

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.

Compatibility / Migration

Backward compatible? Yes (previously-erroring calls now succeed)
Config/env changes? No
Migration needed? No

Failure Recovery

How to disable/revert: revert this commit

Risks and Mitigations

None — silently ignoring an inapplicable parameter is strictly more permissive.

greptile-apps · 2026-03-15T09:04:12Z

Greptile Summary

This PR changes sessions_spawn so that a streamTo parameter passed with a non-ACP runtime is silently ignored instead of returning a 400 error. The fix addresses a real usability issue where schema-following models automatically inject streamTo: "parent" into every tool call (because the field is visible in the shared schema), causing ~90% of subagent-mode spawns to fail. The change is minimal and surgical: a single effectiveStreamTo variable (line 132 of sessions-spawn-tool.ts) gates the value on runtime === "acp", and the rest of the logic is unchanged.

Key observations:

The fix is correct — effectiveStreamTo is only consumed inside the runtime === "acp" branch (line 159), so its undefined value for non-ACP paths has no side-effects.
ACP + streamTo behavior is entirely unchanged; existing test coverage for that path (line 101-139 in the test file) still passes.
The asymmetry with resumeSessionId (which still hard-errors for non-ACP) is intentional and well-reasoned in the PR description — resumeSessionId is an explicit user decision, while streamTo is schema noise from the model.
The updated test verifies the success path but does not assert that streamTo is absent from the spawnSubagentDirect call arguments, which would make the "silently ignored" contract more explicit and regression-proof.

Confidence Score: 5/5

Safe to merge — the change is strictly additive (previously-erroring calls now succeed) with no impact on existing working paths.
The fix is a one-liner that computes a narrowed value only used in the ACP code path, so there is no risk of regression for ACP callers. Subagent callers benefit from the fix. The only gap is a minor test assertion that could be added for extra rigor, but it does not affect correctness.
No files require special attention.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/agents/tools/sessions-spawn-tool.test.ts
Line: 240-243

Comment:
**Test doesn't verify `streamTo` is stripped from subagent call**

The test confirms that `spawnSubagentDirectMock` was called and the result has `status: "accepted"`, but it doesn't assert that `streamTo` was NOT forwarded to `spawnSubagentDirect`. While `spawnSubagentDirect` never accepted `streamTo` in its interface (so the real behavior is correct), adding a `toHaveBeenCalledWith` assertion would make the intent of the "silently ignored" behavior explicit and protect against future regressions where someone accidentally wires `streamTo` through the subagent path.

```suggestion
    expect(result.details).toMatchObject({
      status: "accepted",
    });
    expect(hoisted.spawnSubagentDirectMock).toHaveBeenCalledWith(
      expect.not.objectContaining({ streamTo: expect.anything() }),
      expect.any(Object),
    );
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: f457e0f}

greptile-apps · 2026-03-15T09:04:16Z

    expect(result.details).toMatchObject({
-      status: "error",
+      status: "accepted",
    });
-    const details = result.details as { error?: string };
-    expect(details.error).toContain("streamTo is only supported for runtime=acp");
-    expect(hoisted.spawnAcpDirectMock).not.toHaveBeenCalled();
-    expect(hoisted.spawnSubagentDirectMock).not.toHaveBeenCalled();
+    expect(hoisted.spawnSubagentDirectMock).toHaveBeenCalled();


Test doesn't verify streamTo is stripped from subagent call

The test confirms that spawnSubagentDirectMock was called and the result has status: "accepted", but it doesn't assert that streamTo was NOT forwarded to spawnSubagentDirect. While spawnSubagentDirect never accepted streamTo in its interface (so the real behavior is correct), adding a toHaveBeenCalledWith assertion would make the intent of the "silently ignored" behavior explicit and protect against future regressions where someone accidentally wires streamTo through the subagent path.

Suggested change

expect(result.details).toMatchObject({

status: "error",

status: "accepted",

});

const details = result.details as { error?: string };

expect(details.error).toContain("streamTo is only supported for runtime=acp");

expect(hoisted.spawnAcpDirectMock).not.toHaveBeenCalled();

expect(hoisted.spawnSubagentDirectMock).not.toHaveBeenCalled();

expect(hoisted.spawnSubagentDirectMock).toHaveBeenCalled();

expect(result.details).toMatchObject({

status: "accepted",

});

expect(hoisted.spawnSubagentDirectMock).toHaveBeenCalledWith(

expect.not.objectContaining({ streamTo: expect.anything() }),

expect.any(Object),

);

Prompt To Fix With AI

This is a comment left during a code review. Path: src/agents/tools/sessions-spawn-tool.test.ts Line: 240-243 Comment: **Test doesn't verify `streamTo` is stripped from subagent call** The test confirms that `spawnSubagentDirectMock` was called and the result has `status: "accepted"`, but it doesn't assert that `streamTo` was NOT forwarded to `spawnSubagentDirect`. While `spawnSubagentDirect` never accepted `streamTo` in its interface (so the real behavior is correct), adding a `toHaveBeenCalledWith` assertion would make the intent of the "silently ignored" behavior explicit and protect against future regressions where someone accidentally wires `streamTo` through the subagent path. ```suggestion expect(result.details).toMatchObject({ status: "accepted", }); expect(hoisted.spawnSubagentDirectMock).toHaveBeenCalledWith( expect.not.objectContaining({ streamTo: expect.anything() }), expect.any(Object), ); ``` How can I resolve this? If you propose a fix, please make it concise.

vivimvi · 2026-03-16T02:35:47Z

why check windows error?

…loses openclaw#43556) Schema-following models (e.g. gpt-5.4) include streamTo:"parent" in every sessions_spawn call because it is visible in the tool schema. For runtime=subagent this caused a 400 error. Now streamTo is silently ignored for non-ACP runtimes instead of rejecting the request. Co-authored-by: Copilot <[email protected]>

openclaw-barnacle · 2026-03-16T04:41:27Z