dsh-plugin-confirm-check

dsh-plugin-confirm-check

Confirm Mode for the DeepSeek Harness (dsh): task-level permission instead of per-file gating.

Before starting work that can permanently change something (code edits, config writes, git commits, installs, deletions, ...), the agent files one complete permission application - a short description of what it is about to do, which code paths it touches, and which mutating capabilities it needs. After the user approves, everything inside that direction runs uninterrupted. A background observer only compares later actions with the grant and reports drift in the periodic summary reminder. Nothing is ever blocked: Confirm Mode trusts the model and controls the overall direction, it does not gate individual operations.

What needs an application

Drift = a mutating action outside the declared direction (a write outside the declared paths, or a mutating command category that was not declared). At 5 drift events the next summary reminder asks the agent to check the direction and file a fresh application instead of silently widening scope.

Model-facing reminders

There is no permanent prompt section. The mode reaches the model as one-off user-role reminders injected at accepted steps (agent/pre-step), so each reminder is also a durable session event:

While the mode is off, mission_permission short-circuits without asking the user (outcome off), so a stray call never pops an approval request.

Repository layout

package.json      plugin manifest (dsh.bundle.patch, dsh.client, exports["./client"])
cordis.patch.yml  bundle patch: inserts the host row
lib/index.js      host half: tools, observers, /confirm-mode command, step reminders
lib/client.js     client half: the "Confirm Mode: on/off" composer toggle

Installation

This package is a profile bundle: package.json declares dsh.bundle.patch, and cordis.patch.yml inserts the host row. One command installs it into a profile — it links the package, registers the bundle and enables the row — and the change applies immediately through HMR:

plugin_manager action=install_bundle target=E:\dsh\dsh-plugin-confirm-check

Do not write the profile's package.json or cordis.patch.yml by hand, and do not copy or Junction the package into $DSH_HOME\profiles\node_modules.

Why the old copy/Junction method broke on Desktop 0.2.0: a package placed or linked in $DSH_HOME\profiles\node_modules resolves its @deepseek-ai/* peers against that same shared directory, which the Desktop module resolver treats as an obsolete fallback and rejects. install_bundle links the package under the profile instead, so peers resolve from the app's own install.

Alternative: an agent preset (per session)

To give Confirm Mode to one preset instead of the whole profile, add the same row to an existing user preset at $HOME\.dsh\.agent-presets\<id>\agent.cordis.yml, or copy the shipped cordis preset and edit the copy. Watch out for the picker: the session-mode picker is the preset ROSTER — every preset directory appears there as a session mode labeled by its preset.yml name. Create a standalone preset (with its own preset.yml) only if you want that extra picker entry on purpose.

Validate the composition with the harness preset tools (standingKeyFor) before relying on it.

Verify

• the row include:confirm-mode reports enabled: true, fiberPhase: "active" (plugin_manager action=list_plugins), then
• refresh the browser once: the Confirm Mode: on/off toggle appears next to the access control (Full access / Read Only).

The toggle and the grant state are process-wide: switching the mode off in one session switches it off for every session. session-mode picker is the preset ROSTER — every preset directory appears there as a session mode labeled by its preset.yml name. Installing this package never adds a mode by itself; only a preset directory does.

Validate the composition with the harness preset tools (standingKeyFor) before relying on it. For a preset mount, start a session on that preset and refresh once if the toggle does not show up.

Usage

For the agent (model tools)

• mission_permission - file the one complete permission application before permanent changes: summary (the paragraph the user approves), optional paths (code/config prefixes), capabilities (files-write, commands), duration. The user decides once; the tool reports which answer it got: approved, rejected, custom (the user typed an answer of their own), unanswered (skipped), cancelled (card closed), delegated (a subagent cannot ask), or off.
• permission_status - read-only view of the current grant and the drift log.

For the user

• Composer toggle Confirm Mode: on/off (next to Full access / Read Only). Off = monitoring stops, reminders stop, and mission_permission short-circuits without asking (the two model tools remain registered).
• /confirm-mode on|off|toggle|status - the same switch as a command.
• The application itself is an ordinary question card: pick Approve or Reject, or type your own answer in the free-text field to answer with conditions, a narrower scope, or a correction. A typed answer replaces the options (the harness's single-select answer rule: free text overrides the selection), and the model receives it verbatim.

Card presentation

The application renders through the harness's generic question card - the only card that offers a free-text answer. That card styles its markdown detail block for a short note (no heading scale, margin: 0 2px inside an unpadded body), unlike the plan-review card it replaced (padding: 12px 16px, 14px type). Two consequences are handled here:

• buildPlanText emits no markdown headings: ##/### arrive as full-size headings with 32px outer margins, which dwarf the card's own title and push the options and the free-text field below the fold. The plan is a compact **Goal** / **Paths** / **Capabilities** / **Scale** block plus one blockquote line of approval semantics.
• The client half insets that block to 16px ([data-question-scroll]>div:first-child:not([role])), because the harness ships it at 2px while the card's header sits at 24px and its option list at 12px. Delete the rule once the harness pads the block itself; the selector is structural, so a harness class-name change only makes it stop matching. The rule rides the same style tag as the toggle, rewritten on every client load, so a hot-reloaded half never renders with a stale stylesheet.

Configuration

Constants at the top of lib/index.js:

• DRIFT_WARN (5) - drift events before the summary reminder asks for a new application.
• SUMMARY_EVERY (5) - turns between summary reminders while the mode is on.
• DOC_EXTS - extensions treated as plan/note writes (never monitored).
• READ_ONLY_PREFIXES - command prefixes treated as read-only.

Grants are keyed by session and live in memory: they do not survive a process restart. The on/off toggle is process-wide under a host-plane mount, and per-session under a preset mount (each session mounts its own row instance).

License

MIT