GitHub review with DeepSeek Harness: DSH plugin webhook

The DeepSeek Harness github-review overlay adds a signed GitHub endpoint to dsh web: when a pull request in a configured repository moves from draft to ready for review, a rule creates a titled root Session under that repository's Web Workspace and starts a read-only review prompt — it listens on 127.0.0.1:3081 by default and authenticates with DSH_GITHUB_WEBHOOK_SECRET (source).

What the DeepSeek Harness GitHub review overlay is and what to prepare

This is an optional overlay that turns the "PR moves to formal review" event into an automatic read-only code review session; four prerequisites must be in place first (source). Check each one:

1. Local checkout — prepare a repository directory that DeepSeek Harness can register as a Web Workspace. Expected: the overlay defaults to the launch directory as the Workspace, and you can also specify one explicitly.
2. High-entropy webhook secret — generate a secret and reference it through the DSH_GITHUB_WEBHOOK_SECRET credential. Expected: the Secret on the GitHub side uses the same value.
3. Public entry point — prepare a TLS reverse proxy or tunnel that forwards a single public URL to the loopback listener. Expected: GitHub can reach your /github endpoint.
4. GitHub-side subscription — the webhook subscribes to the Pull requests event with content type application/json. Expected: only PR-related events are delivered.

Reviews read code and may use plugin capabilities. To give a review session plugins (skills or tools, for example), browse community plugins on DSH Plugin Hub, then merge them into the same profile as shown below.

Generate the secret, launch DeepSeek Harness, and expose the /github endpoint

Generate and fix the secret first, then launch with --patch to load the overlay; the main Web UI and /api stay on 3080 while the overlay attaches a second listener that registers only POST /github (source). Steps:

1. Generate and save the secret — run export DSH_GITHUB_WEBHOOK_SECRET="$(openssl rand -hex 32)", print it with printf '%s\n' "$DSH_GITHUB_WEBHOOK_SECRET", and reuse the same value after a restart. Expected: a fixed secret makes signature verification stable.
2. Launch from a dev checkout — point DSH_GITHUB_REVIEW_WORKSPACE at the repository, then run pnpm dsh web --patch apps/cli/config/examples/github-review/cordis.yml. Expected: the overlay loads and listens on 3081.
3. Use an absolute path for installed builds — run dsh web --patch /absolute/path/to/github-review/cordis.yml. Expected: same result as the dev checkout.
4. Make it a permanent profile — put github-ready-review-rule.mjs next to $DSH_HOME/profiles/web/cordis.patch.yml, append the needed lines from cordis.yml into that patch, then just run dsh web. Expected: the bundled CLI already includes both webhook packages, so only the overlay needs activating.
5. Expose the endpoint — the overlay mounts a second WebServer in an isolated realm, registering only POST /github and returning 404 elsewhere. Let a reverse proxy pass only that path, for example Caddy:

hooks.example.com {
  route {
    @github path /github
    reverse_proxy @github 127.0.0.1:3081
    respond 404
  }
}

6. Fill in the GitHub webhook — set Payload URL to https://hooks.example.com/github, Content type to application/json, Secret to the value from the previous step, Events to Pull requests, and turn Active on. Expected: the GitHub side is ready.

DeepSeek Harness GitHub review rule behavior and delivery semantics

The rule accepts only origin primary-github, repository deepseek-harness/deepseek-harness, event pull_request, and action ready_for_review; it passes the exact head SHA and selected PR fields to the review prompt and forbids changing files, branches, PRs, or GitHub state (source). Key points:

1. Session parameters are read-only — the Session request selects the standard agent preset and the read-only permission preset. Expected: the review reads but never writes, so it will not touch your code.
2. The workspace is normalized — workspacePath is normalized through WorkspaceRegistry.create(), and the first matching delivery creates the Workspace if it does not exist; later deliveries reuse it. Expected: the same repository reliably lands in the same workspace.
3. 202 is not a successful session — the HTTP response is deliberately weaker than the Agent result: 202 only means the signature and JSON were accepted and a rule invocation was scheduled in memory. Expected: do not read 202 as "Session created".
4. Delivery is stateless — the webhook runtime stores no delivery or execution state, so a duplicate delivery may create another Session, and a crash can lose a rule invocation that had not accepted a prompt. Expected: once the prompt is accepted, the work is owned by the normal Session logs, persistence, Workspace, and Agent lifecycle.
5. It is programmable — run() is ordinary trusted JavaScript that can query internal policy services before returning a Session request, or map a repository name to a different local path. Expected: useful for wiring in your own enterprise review policy.

Notes and common questions

1. The secret is inbound-only: DSH_GITHUB_WEBHOOK_SECRET verifies only data coming from GitHub; it grants no outbound GitHub access to rule code or the created Agent. Configure that separately if needed.
2. Watch for duplicate triggers: the stateless design means a redelivered event can add another session; mind GitHub's redeliveries.
3. Keep ports apart: 3080 is the main Web UI and 3081 is the review overlay; use DSH_GITHUB_WEBHOOK_PORT to change it.
4. Session logs and data location: review sessions are stored in the same session store; see Where DeepSeek Harness sessions are stored and how to query them.
5. No outbound network: if DeepSeek Harness sits behind a proxy, both webhooks and model calls go through it; see Configure a network proxy for DeepSeek Harness.

Sources: Create review sessions via GitHub Webhook (official docs), dsh CLI README (official repo)