Return confirmed terminal action execution results to the agent

[vanzue]

Problem

Terminal-action proposals currently stop at user confirmation, not command completion.

A typical flow is:

1. The agent proposes a terminal command.
2. The user confirms the recommendation card.
3. WTA dispatches the command to the target terminal pane.
4. The proposal CLI immediately receives a final confirmed response.
5. The agent treats the tool call as complete and ends its turn.
6. The command then runs in the terminal pane, but its output, exit code, or failure is never returned to the agent.

This creates an important semantic gap:

confirmed currently means "the action was accepted for dispatch," not "the command ran successfully."

In an observed Debug session on July 30, 2026:

13:16:27  Prompt forwarded to the agent
13:16:37  Agent submitted a terminal-action proposal
           "Find machine-wide PowerToys packages"
13:16:47  Proposal tool completed after confirmation
13:16:48  Agent ended the turn
afterward  The confirmed command failed in the terminal pane

The failure was visible to the user in the terminal, but the agent received neither the command output nor its exit status. Consequently, it could not explain the error, correct the command, or continue the task.

This affects the core closed-loop experience. A terminal agent that proposes and executes a command must be able to observe that command's result; otherwise, confirmation becomes the end of the automation loop even when the command fails.

Required behavior

• Keep the proposal's existing single user-confirmation boundary.
• Correlate an executed send action with the command that runs in the target pane.
• Wait for command completion when shell integration can identify it.
• Return a bounded, structured result to the owning agent session, including:
  • completion status;
  • exit code, when available;
  • relevant stdout/stderr or terminal output;
  • timeout, cancellation, or unavailable status.
• Allow the agent to reason about the result and continue the same task, especially after a non-zero exit.

Commands that are only inserted, interactive commands, long-running processes, and panes without compatible shell integration need explicit fallback behavior rather than being reported as successful.

Proposed implementation

The short-lived propose-terminal-actions CLI already remains connected until it receives the final proposal response. Instead of resolving confirmed as soon as ChoiceExecution is queued, WTA could distinguish the following lifecycle states:

validated -> confirmed -> dispatched -> completed
                                      -> failed
                                      -> timed_out
                                      -> unavailable

For executable send actions:

1. Assign an execution correlation ID when the confirmed proposal is dispatched.
2. Bind it to the trusted target pane and expected shell command boundary.
3. Use shell integration, such as OSC 133 command start/completion markers, to observe completion and exit code.
4. Capture a bounded output span associated with that command.
5. Keep the proposal CLI request alive until the result is available.
6. Return the structured execution result through CLI stdout so the agent's existing tool invocation receives it and can continue within the current turn.

Example final response:

{
  "phase": "execution",
  "status": "completed",
  "proposal_id": "...",
  "exit_code": 1,
  "output": "Get-AppxPackage: Access is denied...",
  "truncated": false
}

If reliable completion tracking is unavailable, return an explicit result such as completion_unavailable; do not imply that confirmation or dispatch means success.

Output must be size-limited and safely correlated to the confirmed command so unrelated pane content is not returned.

Acceptance criteria

• A confirmed command that exits non-zero returns its exit code and relevant output to the agent.
• The agent can react to that result without requiring the user to manually describe the terminal error.
• confirmed is not presented as command success.
• Output from unrelated commands or panes is never attached to the result.
• Insert-only and non-command actions retain appropriate existing behavior.
• Missing shell integration, interactive commands, cancellation, and timeout produce explicit statuses.
• Existing proposal validation, trusted pane routing, and the single user-confirmation boundary remain intact.

Related work

• Agents lack a secure, turn-scoped path for proposing terminal actions #524 provides the secure, turn-scoped terminal-action proposal path on which this execution-result loop depends.
• Route WTA CLI terminal-action proposals directly to Helpers #484 implements the direct Helper proposal transport.