openclaw - 💡(How to fix) Fix [Feature]: TaskFlow creation is missing from the public CLI and config surface [1 comments, 2 participants]

Summary

After upgrading OpenClaw from 2026.4.1 to 2026.4.2, TaskFlow is now partially exposed in the CLI through:

• openclaw tasks flow list
• openclaw tasks flow show <lookup>
• openclaw tasks flow cancel <lookup>

However, there is still no public way to create a TaskFlow:

• no openclaw tasks flow create
• no declarative TaskFlow config surface in openclaw.json
• no automatic mirrored flow creation from existing background tasks / cron jobs with durable ownerKey

This makes TaskFlow observable, but not authorable.

Problem to solve

TaskFlow exists in the runtime and is exposed for inspection/cancellation, but there is no public creation surface.

That means users can:

• list flows
• inspect flows
• cancel flows

But they cannot:

• create a managed flow
• declare a mirrored flow
• attach a flow to existing background tasks / cron jobs via ownerKey
• define TaskFlow behavior in openclaw.json

This blocks practical adoption of TaskFlow for real multi-step workflows such as durable stage pipelines, mirrored cron routines, and long-running orchestration across restarts.

Proposed solution

Expose at least one public authoring path for TaskFlow.

Preferred options:

1. Add a CLI creation command Example:

   • openclaw tasks flow create ...

   This should support:

   • managed mode
   • mirrored mode
   • stable ownerKey
   • step definitions
   • agent / session linkage

2. Add declarative config support in openclaw.json This would allow users to define TaskFlows as durable configuration, especially for recurring operational workflows.

3. Add opt-in automatic mirrored flow creation from existing tasks If cron jobs or background tasks already emit a stable ownerKey, OpenClaw could optionally materialize a mirrored TaskFlow for that key automatically.

Any of these would make TaskFlow practically usable instead of inspection-only.

Alternatives considered

1. Continue using only HEARTBEAT.md, cron jobs, and background tasks This works operationally, but it does not provide native TaskFlow state, revision tracking, or a durable multi-step flow abstraction.
2. Infer flows manually from background task history This is possible for humans, but not practical as a product workflow because users still cannot create or manage TaskFlows directly.
3. Auto-mirror existing tasks without a public creation surface This would help for some cron-based cases, but it would still not solve managed flows or explicit user-defined orchestration.
4. Use internal or undocumented behavior This is not reliable for production use and does not provide a supported public adoption path.

Impact

Without a public TaskFlow creation surface, the feature is difficult to adopt in real workflows.

Current impact:

• users can observe TaskFlow, but cannot actually model their own durable workflows
• multi-step pipelines still have to be implemented indirectly through heartbeat, cron, and custom orchestration logic
• mirrored flow use cases are blocked even when background tasks already expose stable ownerKey
• the docs create an expectation that TaskFlow is practically usable, while the public surface remains inspection-only

Product impact:

• durable orchestration remains harder than it needs to be
• advanced automation setups become more brittle and ad hoc
• users cannot fully benefit from TaskFlow for stage-based processes, recurring ops routines, or long-running workflows across restarts

Evidence/examples

No response

Additional information

No response