Follow-up from #314, discussion thread: #314 (comment)
Rob asked whether shell exit content should be separated so terminal output can stream. We resolved this for the case where a full ahp-terminal: channel backs the command: a host emits a live ToolResultTerminalContent block while it runs, then a ToolResultTerminalCompleteContent block referencing the same resource when it exits.
That doesn't cover the lighter case — a plain shell child process with no subscribable terminal channel. There's currently no way for a host to stream partial output/progress for that kind of execution before the final TerminalComplete summary lands.
Problem
ToolResultTerminalContent implies a full terminal channel (cols/rows, command detection, etc.) — heavier than some shell tools want just to report incremental output.- Non-terminal-backed shells only get one shot: the final
preview in TerminalComplete, after the command has already exited.
Proposal (not fully speced yet)
- A lighter content type for incremental output from a running command that isn't backed by a full terminal channel. Naming isn't settled —
ToolResultShellProgressContent vs ToolResultTerminalProgressContent vs something else — depends on whether we want this to read as shell-specific or as part of the same terminal-content family as ToolResultTerminalContent/ToolResultTerminalCompleteContent.
- Needs to stay clearly distinct from
ToolResultTerminalCompleteContent, which is specifically the post-exit record.
Sequencing
We should land #322 (PTY / non-PTY capability detection) before this. Once clients can tell whether an execution is PTY-backed vs a plain child process, that same signal likely informs whether/how a progress block should behave — don't want to design streaming semantics twice.
Related
Follow-up from #314, discussion thread: #314 (comment)
Rob asked whether shell exit content should be separated so terminal output can stream. We resolved this for the case where a full
ahp-terminal:channel backs the command: a host emits a liveToolResultTerminalContentblock while it runs, then aToolResultTerminalCompleteContentblock referencing the sameresourcewhen it exits.That doesn't cover the lighter case — a plain shell child process with no subscribable terminal channel. There's currently no way for a host to stream partial output/progress for that kind of execution before the final
TerminalCompletesummary lands.Problem
ToolResultTerminalContentimplies a full terminal channel (cols/rows, command detection, etc.) — heavier than some shell tools want just to report incremental output.previewinTerminalComplete, after the command has already exited.Proposal (not fully speced yet)
ToolResultShellProgressContentvsToolResultTerminalProgressContentvs something else — depends on whether we want this to read as shell-specific or as part of the same terminal-content family asToolResultTerminalContent/ToolResultTerminalCompleteContent.ToolResultTerminalCompleteContent, which is specifically the post-exit record.Sequencing
We should land #322 (PTY / non-PTY capability detection) before this. Once clients can tell whether an execution is PTY-backed vs a plain child process, that same signal likely informs whether/how a progress block should behave — don't want to design streaming semantics twice.
Related