Summary

Add first-class support for long-running node-host commands that can report progress and intermediate updates back to the caller.

Problem to solve

Right now, node-host commands seem best suited for short-lived request/response work. That makes more persistent or interactive node-side tasks harder to support cleanly.

In practice, some workflows need a node-side command to stay alive for longer, send intermediate updates, and only return a final result at the end. Without a standard path for that, these workflows tend to drift toward integration-specific handling instead of using a reusable platform capability.

From a maintainer perspective, this feels less like “one integration wants a custom feature” and more like “the platform may be missing a useful primitive for longer-running node-side work.”

Proposed solution

A helpful direction might be to introduce a standard streaming or long-running command path alongside the existing one-shot node invoke flow.

We are not attached to a specific API shape, but something in this area would likely help:

keep the current one-shot node command behavior as-is add an opt-in path for commands that need to send progress or intermediate events let the caller receive those updates before the final result arrives keep the same overall security and lifecycle expectations as normal node commands

From our point of view, the important part is not the exact naming. It is having a shared mechanism that long-running node-host workflows can build on, instead of each integration needing its own special path.

If this ends up looking like a streaming variant of the current node invoke flow, that seems like it would address the need well. But we would defer to maintainer judgment on the right shape.

Alternatives considered

Keep solving this with integration-specific workarounds This can work for a single integration, but it does not feel like a good long-term platform pattern. It makes behavior less consistent and raises maintenance cost over time.

Use polling instead of intermediate updates Polling can sometimes approximate progress, but it tends to produce a worse user experience and extra overhead. It also still leaves long-running node-side workflows feeling like a workaround rather than a supported capability.

Impact

Reusable platform value: This would help more than one integration. It creates a better base for any node-side workflow that takes longer than a single request/response cycle. Lower maintenance cost: A shared capability is easier to maintain than multiple special-case implementations. Cleaner extensibility: It gives plugin authors a more natural path for long-running node-side behavior. Better UX: Users can see progress and intermediate updates instead of waiting for a single final response. Better architectural direction: It helps OpenClaw grow around reusable capabilities instead of accumulating one-off exceptions.

Evidence/examples

We ran into this through real remote agent workflows, where node-side work can stay active for a while and benefits a lot from progress-style updates instead of a single final reply.

So this request comes from a concrete implementation need, not just a hypothetical API preference.

Additional information

We do have a more detailed internal analysis of one possible path forward, but for upstream the main point is probably simpler:

A standard long-running / streaming node command capability seems like it would make the platform more generally useful, while also reducing pressure for integration-specific core handling.

If helpful, we can also share a more concrete example of the workflow that led us to this request.