dsh-plugin-auto-answer

Unattended DSH sessions don't stall on ask_user_question.

When nobody answers a question within a configurable window, this Host plugin claims the request with the option the asker recommended — the (Recommended) / （推荐） label — and the agent keeps working. If you do answer in time, your answer passes through untouched and the plugin never intervenes.

Host-only bundle: nothing renders in the page, no browser half, no dependencies.

Known UI behaviour, by design — not a bug: with a browser page attached, the question card stays on screen after an automatic answer until you dismiss it (「提交」/「跳过」 or a page reload). The answer is already recorded and the turn has continued; see “The question card stays on screen after an automatic answer” below.

Install

# from GitHub (no build step: the source is the artifact)
dsh plugin --profile web add github:AK-blank/dsh-plugin-auto-answer

# from a local checkout while developing
dsh plugin --profile web add /absolute/path/to/dsh-plugin-auto-answer

dsh plugin add writes the package into the profile and selects its bundle layer, so the row shows up in the GUI's Plugins page and in dsh --profile web --dump-config (# == dsh-plugin-auto-answer → id: auto-answer).

Installing a new bundle activates it through HMR. Replacing an installed copy of this plugin needs a dsh web restart: Host module code is cached per process, so a changed lib/index.js is not reloaded by a re-apply.

How it works

ask_user_question is dispatched as the user-questions/request waterfall. The browser UI answers it by rendering a question card; in a headless run nothing answers it at all.

This plugin registers in front of that chain (prepend) and calls next() — it is a proxy, not a veto:

what happens	result
a human answers inside the window	their answer wins, unchanged
nobody answers before the deadline	the recommended option is submitted
the next answerer fails outright (NO_PROVIDER with no page, transport ended)	the window keeps running, then the recommended option is submitted
the tool's own timed window expired (ASK_TIMED_OUT)	the recommended option is submitted immediately instead of returning pending
the turn is cancelled (ASK_ABORTED, signal aborted)	propagated — a cancelled turn is never answered

The listener is registered with { global: true, prepend: true }. The global flag is not optional: Agent events are scope-filtered by the context a listener was registered on, and a plugin installed through the plugin manager is applied inside one agent's scope — without it the plugin would only answer the session that installed it.

Which option counts as "recommended"

• An option label ending in (Recommended), （推荐）, (推荐) or （Recommended）, case-insensitively. The option does not have to be first.
• The label is submitted verbatim: the marker stays in the answer, because it is the value the asker offered.
• Multi-select questions take every marked option.
• No marked option → fallback decides: first (default), last, or none (never answer, leave the question to a human).
• A question without options has nothing to choose: freeText: skip submits an empty selection — the protocol's own "skipped" answer — while block leaves it open.
• plan-review intents are ignored by default: approving a plan is a decision with consequences. planReview: approve / decline opt in explicitly.
• A batch is answered only when every question in it can be answered; the answer contract requires one item per question, and a partial batch would hide a human decision.

Config

All keys are optional; the row's config overrides the defaults.

key	default	meaning
enabled	true	master switch; false registers no listener at all
timeoutSeconds	120	window before the recommended option is chosen (5 – 86400)
fallback	first	first | last | none when no option is marked
freeText	skip	skip | block for questions without options
planReview	ignore	ignore | approve | decline for plan reviews

# in the profile's cordis.patch.yml, after every bundle layer
- id: auto-answer
  name: 'dsh-plugin-auto-answer'
  config:
    timeoutSeconds: 90
    fallback: first

With the tool's own timed mode, keep timeoutSeconds below tool-ask-user's timeout; otherwise the tool returns pending first and this plugin's answer never applies. The default blocking tool has no such constraint.

Observability

Host logs in dsh web are not visible in the terminal, so the plugin writes an optional JSONL trace:

DSH_AUTO_ANSWER_LOG=/tmp/auto-answer.jsonl dsh web

{"at":"2026-10-18T03:31:56.138Z","event":"armed","agentId":"session-…","timed":false,"questions":1,"timeoutMs":20000,"picks":[{"id":"color","selected":["蓝色 (Recommended)"]}]}
{"at":"2026-10-18T03:32:16.141Z","event":"answered","agentId":"session-…","reason":"window-elapsed","timeoutMs":20000,"picks":[{"id":"color","selected":["蓝色 (Recommended)"]}]}

Events: armed, answered, delegated (a human answered), delegate_error, failed. A broken trace path never breaks the question it describes.

Verified behaviour

Offline self-test (node selftest.mjs) — 39 checks over the package contract, config normalisation, the recommendation rules, the registration options, the timer races, and "No unhandled rejection / no leaked timer".

Real installation path: installed into a throwaway profile with dsh plugin add, confirmed as a bundle layer and row in dsh --profile … --dump-config, and visible on the GUI's Plugins page under 已安装 → 无人值守自动应答.

End-to-end on a live host (blocking tool as shipped):

• unattended: 20 s window, question left open — the trace shows armed → answered exactly 20.003 s later with the recommended option, and the turn finished in 22 s with "你最终选择了蓝色（Recommended）。"
• attended: 60 s window, the human picked the non-recommended option 24 s in — the trace shows armed → delegated (answered-by-ui), the turn finished with "你最终选了香蕉。", and the card collapsed to 1/1 已回答 normally.

The question card stays on screen after an automatic answer — this is not a bug

Expected behaviour, by design. Please don't file an issue for it.

ask_user_question is answered through a waterfall: the browser Client renders the question card and waits for the human's own submission, while the Host waits for whoever answers. This plugin answers on the Host when the window elapses, and the Host has no message that tells a Client its question was settled elsewhere. The card therefore stays where it was:

• it remains in the transcript, and still occupies the composer;
• the session row may keep reading 「等待回答」 (waiting for an answer).

Nothing else is affected. The ask_user_question result already carries the picked answer, the turn continues and finishes normally, and the recorded session data is correct — the stale card is browser state, not session state.

Dismiss it by clicking 提交 (submit) or 跳过 (skip), or by reloading the page. Submitting a stale card is harmless: the request was already settled, so no late answer is injected and no error is raised (verified). Reloading also clears the session-row label.

A Host-side plugin cannot remove that card: the card belongs to the Client's own request, and only the Client settles it. If a future plugin should close it automatically, that needs a Client-side change.

Out of scope

The plugin does not touch approval/request (tool approvals): auto-approving a command is a different risk class, and it is deliberately out of scope.

Development

node selftest.mjs     # offline: no Harness, no timer left behind, no browser

lib/index.js exports normalizeConfig, isRecommendedLabel, decideQuestion, planRequest, createRuntime (with injectable now / setTimer / clearTimer / trace) and apply — the self-test drives the same functions the Harness loads.

MIT.

Disclaimer

Unofficial plugin: not affiliated with, endorsed by, or supported by DeepSeek. "DeepSeek" and "DeepSeek Harness" are names/trademarks of their respective owners.