feat(managed-agent): show the pending tool call's input on Hosted approval Actions #13160

What would you like to be added?

A pending Hosted permission Action should carry a bounded preview of the exact tool input it asks about, on both the public and WebShell Actions routes, so whoever answers it can see what will run.

Where main is today

• The Harness already stores the input. Before asking, HostedWorkspaceToolTurn publishes the call's exact input as a durable managed-tool-input resource and records it as the wait's invocationRef (packages/cli/src/serve/hosted-workspace-tool-turn.ts, the approval loop that calls resources.publish('managed-tool-input', …)).
• The Action record does not reference it. The action.changed payload and its managed-action-options resource are closed shapes that Java validates key by key: requestId, kind, source, inputRevision, optionsRef, state, decisionRef, and v, requestId, turnId, functionCallId, toolName, policyRevision, inputRevision, createdAt, expiresAt, options (ManagedActionStore). Java therefore cannot read the input, and the public and WebShell Action views carry only toolName and functionCallId.
• The transcript deliberately omits arguments. HarnessEventProjector.safeToolData copies only toolCallId, callId, title, status and name into tool-call Items. That is a reasonable default for the transcript and is not what this issue proposes to change.
• The WebShell card is ready. feat(web-shell): show and answer Hosted tool approvals in the Managed panel #13107 shows a pending approval's arguments when a transcript tool row carries them and otherwise says they are unavailable. Against a real Hosted deployment it always takes the second branch today, so a person approves write_file, edit or, once enabled, a Shell command without seeing its input.

Proposed slice

1. Harness. Add the input reference to the Action, either as a new key in the action.changed payload or as a field of a v: 2 options resource, so Java can resolve it. Keep v: 1 readable.
2. Java. Resolve the managed-tool-input resource for a requested Action and expose a bounded preview on PublicAction and WebShellPermissionAction: the JSON input truncated to a fixed byte limit (for example 8 KiB) with a truncated flag and the full byte length. A resource that is missing or fails validation yields no preview and never fails the Action read. The new fields are added to the OpenAPI contract and the generated WebShell types.
3. WebShell. When the transcript has no arguments for the call, show the Action's preview in the approval card, marked as truncated when it is.

Out of scope

• Projecting arguments into the transcript or Items.
• Secret redaction beyond the byte bound. If a redaction policy is required before this ships, it should be decided here first.
• Following answer operations to terminal settlement, restart recovery at await_action, and question or vote Actions. These are the other remaining D6 items in the proposal(serve): Define Managed Agent dual-path architecture and staged delivery #12380 snapshot.

Acceptance

• A Hosted write_file or edit approval read through either surface carries a preview equal to the start of the exact input the tool would receive, with truncated set correctly at the byte limit.
• A large input stays within the bound; a missing or invalid input resource yields an Action without a preview rather than an error.
• The WebShell card shows the preview when the transcript has no arguments, and the transcript's own projection is unchanged.
• Contract tests cover the new fields on both surfaces; the generated WebShell types are regenerated, not hand-edited.

Why is this needed?

Approval is part of the first Hosted slice's release boundary in #12380, and an approval made without seeing the input is not a meaningful control. It also gates public Hosted Shell (#12952): a Shell call must not be approved blind. The #12380 delivery snapshot lists "publish tool-call Items, project bounded/redacted arguments … to the durable transcript/card" under remaining D6 work with no implementation PR. This issue proposes the narrower card path, which needs neither a transcript policy change nor the output-projection line.

Additional context

• Stage tracker: feat(managed-agent): Stage D follow-ups for durable lifecycle, Turns, Actions, durable admission and AgentDefinition #12867 (D6). Overall plan and snapshot: proposal(serve): Define Managed Agent dual-path architecture and staged delivery #12380.
• UI that consumes the preview: feat(web-shell): show and answer Hosted tool approvals in the Managed panel #13107.
• I'd like to implement this (Harness, Java and WebShell parts) once the D6 owner agrees with the shape, in particular the byte bound and whether redaction must come first.