Host-owned atomic, lossless pre-submit hold/resume for human text and ordered attachments

[ysr666]

Problem (verified in official Host implementation)

A third-party DSH plugin cannot safely refuse an ordinary human prompt (including ordered images/files) before model execution without risking silent data loss.

In the current upstream source, packages/api/session-controller/src/commands.ts admits uploaded files and enqueues the UserMessage. packages/core/agent-loop/src/agent.ts then claims the inbox message before calling agent/pre-step. Its reject decision closes a blocked Turn after the claim, without restoring the original work. packages/core/agent/src/runtime-types.ts explicitly documents that the claimed input ends there. The rejection tests confirm no model call, not byte-preserving recovery.

Conversely packages/client/ui-conversation/src/client/service.ts exposes conversation.send(text) forwarding independently to Session.prompt; ComposerBlocks only disables the browser input UI and cannot stop independent tabs/clients/direct API callers.

This is distinct from the official Goal block/resume lifecycle for future automatic Goal rounds, which works and which we have validated in native DSH.

Request: a Host-owned, version-negotiated atomic submission hold

Would the maintainers support a Host-owned pre-submit admission/recovery API?

1. Before any Agent inbox claim or model call, the official Host durably retains the original authenticated-human attempt, exact text bytes, ordered images/file references, and an opaque attempt ID. The plugin receives a privacy-minimized decision request, not raw prompt data by default.
2. Policy result allow/warn/hold(reason). A held receipt is successful only if persistent retention and a visible, actionable localized notice are confirmed. Fail/unsupported -> warn/allow; never consume or silently lose input.
3. Host RPC status(receipt) and resumeOnce(receipt, human authorization) release the exact original attempt once, including after Host cold restart, duplicate requests and multi-tab races. Disable/revoke remains user-controllable.
4. Web, Desktop, SDK, direct Session.prompt and alternate Conversation.send paths negotiate and share the same authoritative admission boundary. No forced tool termination.

Minimum native acceptance before an external plugin can use it

Synthetic text + image + file submitted via a real installed DSH Host and UI, consented hold -> zero model calls, exact payload and file SHA256/order preserved -> Host restart -> race two resume requests -> exactly one message and one model call. Validate visible warning and authenticated human provenance, and old-Host safe fallback.

This is a request for a Host implementation, not a claim that our app has enabled this. We have isolated published-artifact negative probes through @deepseek-ai/dsh 0.2.1-alpha.5, along with positive native official Goal tests. Source/evidence and a concrete consumer acceptance suite are in:

• [P0][DSH enforcement] Real input refusal, same-client visible notice and manual resend E2E ysr666/agent-picket#80
• [1.0][Integration Review] Converge verified DSH/Claude and Host-consent PR lanes without release ysr666/agent-picket#177

We are ready to contribute Host integration tests / implementation against a maintainer-reviewed interface. We deliberately keep destructive agent/pre-step.reject DISABLED for ordinary human-input enforcement. No actual user data, keys or model calls are involved in our reproductions.

[ysr666]

2026-10-19 update — our consumer requirement is now simpler than the original lossless hold request.

The Agent Picket maintainer has explicitly approved refuse + manual resend for ordinary requests: a request rejected before any model/tool execution need not be saved, held, recovered, or automatically replayed. After resuming the union, the user will manually resend text and re-upload attachments. We are not asking upstream to implement durable resumeOnce() solely for this integration anymore; the original proposal may still be useful independently.

On genuine published DSH 0.2.1-alpha.5 and 0.2.1-rc.2 SDK AgentLoop, our isolated tests confirm that agent/pre-step -> {kind:'reject'} produces a blocked turn and zero model/tool calls; manually resubmitting text and an image starts a new turn, and omitted prior attachments are never automatically replayed. This establishes reject semantics, not safe user-visible notification/provenance.

The smaller remaining official Host API gap:

1. packages/core/agent/src/runtime-types.ts exposes only agent, messages, turn, step, and signal in agent/pre-step. A message's source.kind === 'user' is a claimed role, not an authenticated submitting Web window / Desktop client / CLI / SDK identity. One tab's visible warning must never authorize rejecting a different client's request in the same Session.
2. turn/end.reason.kind === 'blocked' carries no localized, actionable Picket refusal explanation. We need an official per-attempt, authenticated-origin-bound, client-visible notice/acknowledgment path stating: This request was not executed; resume first, then manually resend text and re-upload attachments. The confirmation must identify the same submitting client and request before destructive refusal is permitted, or the Host must itself deliver a guaranteed visible refusal reason.
3. On unsupported/disconnected clients, unknown origin, missing notice, revoked consent, or cross-tab races, plugins must allow normal work, not silently discard. No model call on genuinely rejected input, no replay after resume, and no interruption to in-flight tools.

A minimal versioned Host admission provenance/notice extension would be sufficient for this consumer; the large lossless queue is no longer a prerequisite. We have implemented metadata-only Host refusal attribution and UI notices in Agent Picket Draft PR #177, but production ordinary-input rejection remains OFF because the initiating-client/notice proof is not provided by the current Host. We can help validate a maintainer-approved public API and real Web/CLI/SDK negative cases.

[antst]

The same claim-before-decision ordering also reproduces for steering, not only for a human prompt, on 0.2.2-rc.3.

Reproduction: a turn is running and a message is sent to it with agent.steer (void; the item is durably spliced into next-step). An agent/pre-step listener returns { kind: 'reject' } for the step that claims it. Observed once, with a scripted model adapter: the claim's agent/inbox/spliced removal, then turn/end blocked. At idle the message is in neither pending list, no user/message carries it, and no model request contained it. The sender's steer call had already returned normally.

Source, @deepseek-ai/dsh-agent-loop@0.2.2-rc.3 lib/index.js: Inbox.claim :103-111 removes the whole next-step batch (:104); preStep claims at :683, before tool resolution, prompt assembly and the waterfall (:686-698); on reject (:712-715) it returns without restoring; turn() (:759-762) ends the turn blocked before step() appends any user/message (:873-879). 0.2.1-rc.2 has the same order (:906, :922, :960-962).

The types disagree for this case. @deepseek-ai/dsh-agent@0.2.2-rc.3 lib/types/runtime-types.d.ts:224-225, on steer: "A rejected step leaves steering parked in the inbox until the next wake". :296-298, on agent/inbox/claimed: the claimed message "ends here: it is neither discarded nor re-emitted as a user/message". A steer claimed into the rejected step follows the second. dsh-goal-round-driver@0.2.2-rc.3 lib/index.js:99-106, 313-315 re-prepends the other claimed messages to next-step before returning reject, which matches the first.

Which one is intended for a claimed steer? If parking is, claiming after the decision (or restoring the claimed items on reject) would deliver it; if consumption is, the steer text could say so.

Related: the comment on #7053 about reject swallowing the prompt, and #6964 (same window on the error path).