<div align="center">

🖱️ dsh-click


Cross-platform native desktop control for DeepSeek Harness — Windows first.

Look at the screen, then act — every click gated, every action audited.

      

English · 简体中文 · Español · Português · हिन्दी

</div>

---

Compatibility

| Surface | Status | |---|---| | Harness | DeepSeek Harness 0.1.1-rc.2 | | Node | ^22.19.0 \|\| >=24.0.0 | | Platforms | Windows first (UIAutomation + Win32 input, via a bundled PowerShell helper); macOS/Linux backends are reserved and fail closed with a clear reason | | Model | Text-only models fully supported (screen_read returns structured text); vision models additionally get screen_shot images |

What you get

dsh-click gives the harness a complete observe → act loop over native desktop applications:

• screen_shot — screenshot of a window (or the primary screen), downscaled to a configurable bound. With a vision-capable model the result carries the image; otherwise a text description keeps text-only models working.
• screen_read — the structured observation: the window's accessibility tree (element ids, types, names, rectangles, supported patterns) plus pixel-location hints with colors — plain text, no image model required.
• click / type / scroll / key — window-scoped actions addressed by element id or coordinates. Delivery prefers UIA invoke, falls back to posted window messages — and never steals foreground focus.
• app_list / app_launch — enumerate running applications and their windows; launch one by name or path.

Every mutating action crosses one safety boundary:

1. Freshness — the action must cite a basedOn observation; the window is re-captured right before acting and the action is refused if the screen changed (pixel-hash check + max-age bound). 2. Approval — ctx.approval gates every action by default; window-title/executable regexes can allowlist specific windows (still audited). 3. Process identity — the owning process's pid and executable path are verified before and after the act; a change refuses the outcome loudly. 4. Audit — observations and actions land in the session log as dsh-click/observed / dsh-click/action events (sanitized, log-only).

model                           harness
  │ screen_read ──▶ observationId (+ elements, pixels)         ← structured text
  │ click {basedOn, target} ──▶ freshness check ──▶ approval ──▶ helper (UIA)
  │                             pixel hash changed? ── refuse + re-observe
  │                             pid/exe changed after act? ── PROCESS_CHANGED
  │ ◀── canonical JSON + audit events (dsh-click/action)

Quick start

# 1. install the bundle into your profile
dsh plugin --profile web add "github:PerryLink/dsh-click#main"

# or from npm (published releases)
dsh plugin --profile web add dsh-click

# 2. restart and verify the row
dsh --profile web --dump-config | grep -A2 'id: dsh-click'

Then ask the agent to look at a window and act — the approval prompt appears for every mutating action:

> Open Notepad, type "hello", then read back what is on screen.

Install & uninstall

• git channel (latest main): dsh plugin --profile web add "github:PerryLink/dsh-click#main" — the prepare script builds with production dependencies only.
• npm channel (published releases): dsh plugin --profile web add dsh-click.
• tarball channel: pnpm pack in this repo, then dsh plugin --profile web add ./dsh-click-<version>.tgz.
• uninstall: dsh plugin --profile web remove dsh-click (or remove the row from the profile patch).

> If pnpm reports ERR_PNPM_IGNORED_BUILDS for this package (esbuild's harmless platform-binary validation), add allowBuilds: { esbuild: true } to your pnpm-workspace.yaml — the dsh CLI prints the exact snippet.

Configuration

All tunables are Schemastery Config fields (changeable from cordis.yml). An id-targeted override replaces the whole row — restate every key you need. cordis.patch.yml documents each key inline.

Example override in your profile patch:

- insert:
    - id: dsh-click
      name: dsh-click
      config:
        requireApproval: true
        autoApproveWindows: ['^Notepad']
        focusFallback: never

Tools & surfaces

Permissions & data

• Permissions: mutating actions cross the official ctx.approval seam — the plugin never re-implements or bypasses it. The allowlist only ever skips the ask for specific windows; it cannot disable the freshness or process-identity checks.
• Data: the plugin stores nothing on disk except the screenshots the attachment store keeps (content-addressed, under the harness's own attachment policy). Observations are cached in memory (LRU, bounded). No network requests, no credential storage.
• Session log: dsh-click/observed and dsh-click/action are log-only audit events carrying sanitized window/process facts — titles, paths, and free text are redacted and length-capped before they are written or shown.

Security boundaries

• Observe before act, every time. Actions must cite a fresh observation; a changed screen (pixel hash) or an expired observation is refused with a model-readable reason demanding re-observation.
• Approval is the default. requireApproval: true unless you explicitly opt specific windows in; every action — allowed or not — is audit-logged.
• No foreground stealing. The helper never brings a target window to the foreground (focusFallback: 'never' by default); input is delivered through UIA or posted messages so background windows are not disturbed.
• Process identity is re-verified immediately before and after each action; a mid-act process swap fails the outcome (PROCESS_CHANGED).
• Sanitized output. Control characters are stripped, tabs collapse, credential-shaped values (keys, tokens, JWTs, bearer headers) are redacted before anything reaches the model or the log.
• Fail closed. Unsupported platforms, a missing subprocess service, or an unavailable helper refuse every call loudly — profiles keep booting everywhere.

Known limitations

• Windows first. macOS and Linux backends are reserved; on those platforms every call fails closed with a clear reason.
• Text-only fidelity. screen_read depends on the application exposing UIAutomation; apps without an accessible tree yield pixel hints only. Coordinate clicks remain available.
• Posted-input apps. Some applications ignore posted window messages (games, some Electron surfaces); key reports this honestly instead of pretending success.
• Session audit on harness builds through rc.8. The audit events are appended with the two-argument Session.append form (the 0.1.0-rc.6–0.1.0-rc.8 peers expose no append-envelope option for plugin events); on those builds the events are required-on-read, and a static-whitelist session reader (rc.6–rc.8 KNOWN_SESSION_EVENT_TYPES) refuses to resume a log containing them unless auditSessionEvents is false.

Development

pnpm install        # node ^22.19 || >=24
pnpm run typecheck  # tsc: src + tests against the local harness checkout
pnpm run typecheck:ci  # tsc against the published 0.1.1-rc.2 types (no paths)
pnpm test           # vitest: 56 tests, 8 suites (helper smoke runs on Windows)
pnpm run build      # tsdown bundle + tsc declarations (lib/)
pnpm run verify:self-contained  # dependency specs resolve from the registry
pnpm run verify:artifacts       # built ESM face + native helper present
pnpm pack           # the published tarball

Topics

dsh, dsh-plugin, deepseek-harness, deepseek, cordis, computer-use, windows-automation, uiautomation, desktop-control, screen-reader

Contributors

• @PerryLink — creator and maintainer: tool surface, action safety boundary, Windows native helper, sanitizers, and the five-language docs.

PerryLink DSH Plugin Family

This project is one of the 29 DeepSeek Harness plugins maintained by PerryLink. If this one helps you, the others likely will too:

License

[Apache License 2.0](LICENSE) © 2026 dsh-click contributors