Context
Implementer feedback from building a computer-use (GUI/browser automation) server on the Tasks extension (SEP-2663, 2026-07-28 revision). Filing as an issue since the SEP PR is merged/final.
Problem
The Tasks extension gives a running task a lifecycle (working → input_required → completed/failed) and a terminal result, but no standard surface for partial output while the task is still running. tasks/get returns status, not the in-progress trace, log, or incremental artifacts. Today the only home for that data is a private _meta blob — which, by definition, no other client can render.
For most long-running tools this is a minor gap. For computer use it is the core of the product: watching the run — each observe/click/type step, each screenshot, each approval — is most of the value of a long autonomous session. With no interoperable surface, every client reinvents live-run visibility, and cross-client interop is lost precisely for the tasks users most want to watch.
What we observed implementing it
- We hand-rolled SEP-2663 server-side (the extension packages don't yet compose with the v2 SDK) and found nowhere in the vocabulary to put an in-flight trace.
resources/subscribe / subscription notifications work well on the v2 SDK — the transport for streaming already exists; it just isn't connected to tasks.
Proposal
Define a task-scoped log resource convention: a task MAY advertise a resource URI (e.g. task-log://{taskId}) whose reads return ordered partial-output records and which supports subscriptions for incremental push. This reuses existing resource + subscription machinery rather than adding a new method. Records should carry a monotonic sequence number so a reconnecting client can resume without gaps.
Interim, we plan to dual-emit: a vendor-private _meta key plus the task-log://{taskId} resource shape above, degrading gracefully to tasks/get polling for clients that support neither.
Questions for the WG
- Is a standard partial-output surface in scope for the Tasks extension, or deliberately delegated to resources?
- If delegated, would the WG bless a canonical
task-log:// resource shape + ordering guarantee so it's interoperable rather than per-vendor?
- Is
resources/subscribe the intended streaming transport for task progress?
Context
Implementer feedback from building a computer-use (GUI/browser automation) server on the Tasks extension (SEP-2663, 2026-07-28 revision). Filing as an issue since the SEP PR is merged/final.
Problem
The Tasks extension gives a running task a lifecycle (
working→input_required→completed/failed) and a terminal result, but no standard surface for partial output while the task is still running.tasks/getreturns status, not the in-progress trace, log, or incremental artifacts. Today the only home for that data is a private_metablob — which, by definition, no other client can render.For most long-running tools this is a minor gap. For computer use it is the core of the product: watching the run — each observe/click/type step, each screenshot, each approval — is most of the value of a long autonomous session. With no interoperable surface, every client reinvents live-run visibility, and cross-client interop is lost precisely for the tasks users most want to watch.
What we observed implementing it
resources/subscribe/ subscription notifications work well on the v2 SDK — the transport for streaming already exists; it just isn't connected to tasks.Proposal
Define a task-scoped log resource convention: a task MAY advertise a resource URI (e.g.
task-log://{taskId}) whose reads return ordered partial-output records and which supports subscriptions for incremental push. This reuses existing resource + subscription machinery rather than adding a new method. Records should carry a monotonic sequence number so a reconnecting client can resume without gaps.Interim, we plan to dual-emit: a vendor-private
_metakey plus thetask-log://{taskId}resource shape above, degrading gracefully totasks/getpolling for clients that support neither.Questions for the WG
task-log://resource shape + ordering guarantee so it's interoperable rather than per-vendor?resources/subscribethe intended streaming transport for task progress?