dsh-approval-review

0.6.4: the install half leaves the transaction too

0.6.2 fixed only the removal direction, and the live host immediately showed the other half: an enable is an HMR transaction as well, so the mount-time write that restores a missing preset was rejected with HMR transactions cannot be nested (log: access-mode preset check failed — could not write preset "approve-for-me"). Both directions now share one transaction-free writer: leave the store through hmr.executing.exit(...), then call configEditor.edit(), which QUEUES behind the running reload instead of failing. The first attempt is no longer delayed (the menu should not wait for it) and the retries cover a row that is replaced mid-reload. Two regression tests join it: a write issued while the mount runs inside the store must succeed, and an unleaveable context must report the failure.

0.6.3: which build is running is now in the log

Diagnosing 0.6.1/0.6.2 surfaced another trap: inside one host process a reinstalled plugin reuses the module it first imported — a different install source or disk path changes nothing, and the mount log looked identical. A "fixed" version could therefore never have been loaded while the retest said otherwise. This release makes the running build visible (the ready line carries v0.6.3) and has the uninstall cleanup state whether the HMR transaction context could be left before it gives up. Restart DSH Desktop after upgrading the plugin; without a restart the new code is not loaded.

0.6.2: uninstall cleanup actually leaves the reload transaction

0.6.1 only deferred the write to a timer, and the live retest still failed: the host marks "inside a transaction" with an AsyncLocalStorage store, and Node propagates that store into timers created inside the transaction — so the write stays nested however long it waits, and all three retries hit the same lock. 0.6.2 leaves the context through hmr.executing.exit(...) before scheduling anything (falling back to the old behaviour when that service is absent), after which configEditor.edit() queues on the host's own serialized path. A regression test reproduces the mechanism with a real AsyncLocalStorage: the unmount happens inside store.run(true, …) and the write still has to succeed.

0.6.1: uninstall cleanup no longer fights the host's reload lock (incomplete, see 0.6.2)

The first real uninstall of 0.6.0 exposed an ordering bug: the uninstall runs inside the host's HMR transaction, and writing the preset back into the profile patch takes that same lock, so the deletion failed with HMR transactions cannot be nested and the menu kept "Approve for me". The removal now runs outside the transaction and retries (0.25s / 1s / 3s); only three blocked attempts leave the entry behind, with an explicit warning in the log and in /approval-review status.

0.6: the access-mode entry can no longer disappear silently

The "Approve for me" entry lives in the permission row's preset table, and an id-targeted override replaces that whole row — so any later layer that restates the table (typically a profile patch pinning its own defaultPreset) drops it without a word: the menu lists three modes, the plugin's gate key is not in the catalog, and it claims nothing. This release adds two guards: a mount-time catalog check that names the cause in the startup log and in /approval-review status, and (by default) a managed entry written into the profile patch through configEditor — present while installed, removed on uninstall, no stale option. For a read-only deployment, manageAccessModePreset: false warns without ever writing. See the access-mode entry's lifecycle.

dsh-approval-review

English | 简体中文

Codex-style agent auto-approval for DeepSeek Harness. When an action crosses a boundary that the sandbox does not cover on its own, a second, independent reviewer model reads the proposed action and returns a verdict — so a human handles fewer routine prompts. Model judgements can still be wrong. Each reviewed decision leaves a full rationale in a dedicated Approvals tab.

This plugin implements the shape of Codex's Auto-review: an interactive approval request is routed to a reviewer agent instead of a person, the reviewer answers with a structured verdict, a denial is handed back to the calling model as reasoning rather than as a bare error, and a per-turn rejection circuit breaker stops the agent from looping on escalation attempts.

It is a reviewer swap, not a permission grant. The plugin never widens a sandbox, never invents a grant, and never removes a human from a decision it was not configured to take over. Requests it does not own are delegated with next(), unchanged.

0.5: Jev as an optional reviewer engine

reviewer.engine now chooses who reviews: the original LLM route, or TypeSafe's Jev (System One). Jev is a decision model — it answers typed questions with probabilities instead of writing prose — so one review is a single HTTP call with no tool loop. Measured on this plugin's own case set: ~0.9 s per review against 4–12 s for the LLM reviewer, and 16/16 agreement with the expected policy outcomes. Everything downstream of the verdict — risk gate, breaker, cache, ledger, Approvals tab — is shared by both engines.

To use Jev:

1. Store the key where the harness resolves credentials: the harness credential settings, or $DSH_HOME/.env as TYPESAFE_API_KEY=…. The plugin asks the credential store first (which itself layers the launch environment, the managed store and .env files) and falls back to the process environment; it re-resolves per review, so a rotated key applies to the next verdict with no restart.

2. Turn the engine on in your profile patch. An id-targeted override replaces the whole row config, so restate any key you still want:

   - id: approval-review
     config:
       reviewer:
         engine: jev
         jev:
           allowEgress: true
   

3. Restart the harness (the engine is read at mount) and run /approval-review status. It prints the engine, the access-mode gate and the model, so a silent ledger always has a visible cause.

Two guards are deliberate: allowEgress: true is required because Jev is a third-party endpoint and the evidence packet leaves the machine, and a selection that does not fit the engine in force is reported rather than forwarded. Pick any Jev model or LLM route from the Approvals tab — the choice carries its engine and applies to that session only. The full contract, including what each engine can and cannot do, is in Reviewer engines.

What it does

0.4 policy and compatibility

Risk and user authorization are assessed separately. Routine low/medium risk actions normally pass. High risk requires medium/high authorization, bounded scope and no prohibition; critical risk is denied. Escalation, outside-workspace paths and normal credential authentication are not intrinsically high risk. Missing evidence, truncated action arguments, timeouts and malformed answers delegate by default.

This is not a full Codex Guardian implementation. Default direct review can inspect local metadata, directory entries and text with at most four read-only calls; it delegates when evidence remains insufficient. The inspector permits workspace paths and exact outside paths named in the action, excludes credential stores, bounds reads to 16 KiB and listings to 100 entries, and never executes shell commands. Optional subagents still inherit DSH presets. The default breaker records the tool refusal, then cancels the host turn while retaining pending user input. Only host approval/request events are covered. Custom policyText replaces the semantic policy but cannot bypass the code-level critical-risk denial or high-risk authorization gate.

Upgrading changes the default reviewer mode, risk ceiling, breaker action and cache setting; explicit profile overrides still win. Recorded rationale retains its original language while UI labels follow the current locale.

Policy comparison and test evidence

Install

No build step on install. The repository carries the built bundles (lib/) and package.json declares no prepare script, because pnpm blocks a git dependency's prepare/install build scripts (ERR_PNPM_GIT_DEP_PREPARE_NOT_ALLOWED) and that fails the entire install. dsh plugin add github:... therefore works with no allowBuilds entry in the profile's pnpm-workspace.yaml.

You only build when working from a source clone: pnpm build (and prepack runs it automatically before a publish).

# npm (published releases)
dsh plugin --profile <profile> add dsh-approval-review

# a local checkout
dsh plugin --profile <profile> add /path/to/dsh-approval-review

# a git pin
dsh plugin --profile <profile> add "github:LAwLi3tCoding/dsh-approval-review#<sha>"

Then restart and confirm the row composed:

dsh --profile <profile> --dump-config | grep -A6 'id: approval-review'

The desktop profile is managed by the Electron app and refuses dsh plugin; add the dependency and bundle entry by hand there, or drive it from the app's plugin manager.

Configuration

All tunables live in the bundle's cordis.patch.yml row, so they are changeable without touching code. An id-targeted override replaces the whole config row — restate every key you still want, or the omitted ones silently return to their schema defaults.

The access-mode entry's lifecycle

The "Approve for me" entry lives in the permission row's preset table. An id-targeted override replaces that whole row, so any later layer that restates the table — typically a profile patch pinning its own defaultPreset — silently drops the entry this package ships. The menu then lists three modes, the plugin's gate key is not in the catalog, and it claims nothing while the log says nothing.

Two guards fix that:

1. Self-check. At mount the plugin reads the live catalog (permissionPresets.catalog()). A missing gate key is named in the startup log, and the Access-mode catalog line of /approval-review status keeps reporting the conclusion — missing, written, or only fixable by hand.
2. Managed entry (manageAccessModePreset: true, the default). Through the configEditor service the plugin writes the missing entry into the profile patch — the layer no later override can shadow — and adopts an identical entry a human already pasted there instead of writing a duplicate. On uninstall it deletes that entry again: installing adds the menu option, uninstalling removes it, and no stale option is left behind.

Ownership stays narrow, so the plugin never touches somebody else's preset:

• Only a byte-identical definition is owned. Renamed or retuned entries are treated as the operator's, kept on uninstall, and reported in one log line. The preset table is never emptied.
• The uninstall signal is the profile's own dsh.profile.bundles. A normal app exit unmounts plugins too, and there the bundle is still listed, so the entry survives a restart as it should.
• A refused write (an id also pinned by a home patch or a command-line overlay is rejected by configEditor) is a warning, not a mount failure, and /approval-review status shows the reason.

For a deployment whose configuration is read-only, set manageAccessModePreset: false: the self-check still warns, and nothing is ever written.

Reviewer engines: llm and jev

reviewer.engine chooses who answers a review. llm (the default) is the original path: one model call — or a read-only subagent — reads the evidence packet and returns the verdict JSON. jev posts the same packet to TypeSafe's System One endpoint and reads typed answers back, with the decisions (prohibition hit, uncertainty, bounded scope) applied in code. Everything downstream of the verdict — the risk gate, the breaker, the cache, the ledger and the card — is shared by both engines.

Jev never touches DSH's model routes: it is a direct HTTP call with a bearer key, so it does not appear in the model picker and needs no provider registration. The typesafe/<model> value shown in the ledger is a label the plugin synthesizes for its own audit record, not a DSH route; /approval-review model <id> still works and overrides the model name or version sent to TypeSafe.

A selection from the picker carries its engine: typesafe/<model> reviews with Jev, <provider>/<model> reviews with that LLM route, a bare <model> keeps the engine already in force and replaces only the model, and default returns to the deployment's own reviewer. That is what makes every listed row mean something — including switching a Jev deployment back to an LLM for one session, which the header pill and the ledger both follow. Two limits hold: a session may switch to Jev only when the deployment acknowledged egress (jev.allowEgress), and the Jev endpoint receives a bare model name, so a value that still contains / after the typesafe/ marker is stripped is reported and ignored rather than forwarded.

What differs in practice:

• One HTTP call per review, no tool loop. Jev cannot inspect local state, so a request whose decisive fact is not in the evidence becomes uncertain and follows onUncertain (a human prompt by default) instead of being investigated. reviewer.mode and reviewer.inspectLocalState do not apply.
• reason is composed in code from the answers — for example Denied: prohibition "disclosure of secrets or private data" (0.97); risk critical; authorization unknown; permit 1.00 — in the configured output language. reviewer.policyText does not apply: the ruling policy lives in the per-question rubric.
• The evidence packet leaves the machine, which is what allowEgress acknowledges. Redaction is unchanged (key-name based, plus a best-effort pass over unparsable payloads); it does not scrub secrets out of free text.
• **The key is resolved through the harness