@permission-protocol/mcp-guard 0.1.0 → 0.2.0

package/CHANGELOG.md

@@ -0,0 +1,45 @@
+# Changelog
+
+## 0.2.0 — security hardening (breaking)
+
+Fixes the findings of the October 2026 MCP Guard audit.
+
+### Breaking changes and migration
+
+- **Strict config.** Unknown keys, duplicate rules, `countdown_seconds` on a rule that is not `reversibility: reversible`, and `cap_usd` without `amount_arg` now fail at startup. Remove any `tools:` block (it was never read) and add `amount_arg` to capped rules:
+  ```yaml
+  - { id: spend, tool: spend, action: require_approval, cap_usd: 50, amount_arg: amount_usd }
+  ```
+- **Spend caps read only `amount_arg`.** `_pp.amount_usd` and the `amount_usd`/`amount` fallbacks are gone. A missing or non-numeric amount is a hard stop.
+- **All methods are gated.** `resources/read`, `prompts/get`, `resources/subscribe` and unknown methods now follow the rules and `default_action` (a `default_action: block` policy blocks them unless a `method:` rule allows them). Plumbing still passes through.
+- **Malformed input is refused.** Unparseable lines get `-32700`; JSON-RPC batches and malformed frames get `-32600`. Nothing is forwarded raw.
+- **Approval UI needs its token.** It listens on 127.0.0.1 only; open the URL printed at startup (`…/#t=<token>`). API clients send `Authorization: Bearer <token>`; `PP_APPROVAL_TOKEN` (32+ characters) supplies it. Cross-origin access (`?api=` on another origin) no longer works.
+- **Post-release undo is removed** (`/api/undo` returns 404). Use Hold before a countdown releases. Verify-lane items can only be acknowledged.
+- **Receipt v2.** New signed envelope; v1 receipts are rejected by the verifier. Receipts carry `args_sha256` and argument names, never raw arguments.
+- **Keys moved** from `./.keys` to `~/.config/mcp-guard/keys` (or `$PP_KEYS_DIR`). Key ids are now `pp-dev-<fingerprint>`. Re-export and re-pin the public key: `mcp-guard export-key`.
+- **`verify` requires `--pubkey` and `--scope`.** The verifier no longer generates or discovers a key, and empty `--scope-*` values are errors.
+- **GitHub commit-status poster removed** (`PP_GITHUB_TOKEN`). Gate merges with the Permission Protocol GitHub App's `permission-protocol/approval` check.
+
+### Added
+
+- `mcp-guard verify` and `mcp-guard export-key` subcommands.
+- `--operator <name>`: approvals record `{kind: human, id, via: local-token}`; countdown and standing-rule releases record `{kind: policy}`.
+- `approval_ttl_seconds` and `receipt_ttl_seconds` config keys (default 900 each). Expired held requests answer the agent with `-32004`; denials with `-32003`.
+- The approval UI and the Permission Deck show every argument the server will receive (`args_full`) and the scope an approval signs for (`scope`).
+- The wrapped server no longer inherits `PP_*` environment variables (approval token, webhook secret, receipt token).
+- `merge_pr` scope ref is derived only from the PR number; `_pp.requires_input` no longer moves an irreversible hold out of the Decide lane.
+- GitHub webhook deduplicates `X-GitHub-Delivery`.
+- `templates/github-actions/receipt-gate.yml`: a deploy gate that takes its verifier, key and receipt only from trusted sources.
+- CI workflow running build, tests and the end-to-end demo drivers.
+
+### Fixed
+
+- Approval API: no authentication, all interfaces, `Access-Control-Allow-Origin: *`.
+- Spend-cap bypass through `_pp.amount_usd`.
+- Receipt signatures that covered only part of the receipt and could be re-split across fields.
+- Self-gate CI that trusted the key, receipt and verifier from the pull request (workflow removed).
+- Fail-open forwarding of unparseable lines and batches.
+- Approving a webhook PR after it was denied (and approving repeatedly).
+- Countdown releases producing receipts indistinguishable from human approval.
+- Raw tool arguments in stderr, receipts and the CORS-open receipts API.
+- Enforcement module: a missing or invalid policy meant "nothing protected"; duplicate signer names counted as separate approvals.

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Permission Protocol
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -4,13 +4,13 @@
 
 [MCP](https://modelcontextprotocol.io) (Model Context Protocol) is how AI agents call tools — like APIs, databases, or deployments. MCP has no built-in access control. MCP Guard adds that layer.
 
-Define what's allowed, blocked, or requires approval — in a single YAML file. MCP Guard sits between your MCP client and server, enforces the rules, and logs every decision as an audit receipt.
+Define what's allowed, blocked, or requires approval — in a single YAML file. MCP Guard sits between your MCP client and server, enforces the rules, and records every decision as a signed receipt.
 
-Without MCP Guard, your agent can call any tool. With it, every action is checked. **MCP Guard does not just log — it blocks execution before it happens.**
+Every tool call, resource read and prompt fetch goes through your policy; only protocol plumbing (`initialize`, `ping`, list calls, notifications) passes untouched. **MCP Guard does not just log — it blocks execution before it happens.**
 
 → **Blocks** unsafe tool calls before they execute
 → **Holds** sensitive actions for human approval
-→ **Logs** every decision as an immutable receipt
+→ **Signs** every decision as an Ed25519 receipt that names who authorized it
 → **Observe mode** — audit what would be blocked before enforcing
 
 <p align="center">
@@ -21,7 +21,7 @@ Without MCP Guard, your agent can call any tool. With it, every action is checke
 
 ```bash
 # Install
-npm install @permissionprotocol/mcp-guard
+npm install @permission-protocol/mcp-guard
 
 # Create a policy file
 cat > pp.config.yaml << 'EOF'
@@ -39,19 +39,18 @@ EOF
 mcp-guard --config pp.config.yaml -- node my-mcp-server.js
 ```
 
-That's it. Your agent can no longer delete user data. Production deploys require approval. Everything is logged to `pp-receipts.jsonl`.
+That's it. Your agent can no longer delete user data. Production deploys require approval. Every decision is signed and logged to `pp-receipts.jsonl`.
+
+`default_action: allow` lets any tool without a rule run, and the guard warns about it at startup. Use `block` or `require_approval` to fail closed.
 
 ## 60-Second Demo (no MCP server needed)
 
+See MCP Guard block dangerous tool calls in real-time, no setup required:
+
 ```bash
-git clone https://github.com/permission-protocol/mcp-guard
-cd mcp-guard
-npm install
-npm run demo
+npx @permission-protocol/mcp-guard demo
 ```
 
-Sends three tool calls through the guard and shows: one allowed, one blocked, one held. No setup required.
-
 ## Architecture
 
 ```
@@ -66,29 +65,47 @@ Sends three tool calls through the guard and shows: one allowed, one blocked, on
                               (audit trail)
 ```
 
-MCP Guard intercepts JSON-RPC messages on stdin/stdout. When it sees a `tools/call` request:
+MCP Guard parses every JSON-RPC message on stdin and forwards only what it parsed and evaluated, re-serialized:
 
-1. Looks up the tool name in the config rules
-2. If **allowed** → forwards to the real server
-3. If **blocked** → returns a JSON-RPC error (`-32001`) directly
-4. If **held for approval** → returns a JSON-RPC error (`-32002`) directly
-5. Emits a receipt for every decision (stderr + jsonl file)
-
-All other JSON-RPC methods pass through transparently.
+1. A line that is not a single JSON-RPC 2.0 object (invalid JSON, a batch array, a malformed frame) gets an error and is never forwarded.
+2. Plumbing passes through: `initialize`, `ping`, `notifications/*`, `tools/list`, `resources/list`, `resources/templates/list`, `resources/unsubscribe`, `prompts/list`, `logging/setLevel`, `completion/complete`.
+3. Everything else — `tools/call`, `resources/read`, `prompts/get`, `resources/subscribe` and any method MCP Guard does not know — is decided by the rules, then `default_action`.
+4. **Allowed** → forwarded (agent metadata under `_pp` is stripped first). **Blocked** → error `-32001`. **Held** → waits for a human (or returns `-32002` without an approval UI).
+5. Every decision emits a signed receipt (one stderr line + `pp-receipts.jsonl`).
 
 ## Config Reference
 
 ```yaml
 # pp.config.yaml
-default_action: allow  # "allow" or "block" — applies when no rule matches
-mode: enforce          # "enforce" (default) or "observe" (log only, never block)
+default_action: block        # allow | block | require_approval — when no rule matches
+mode: enforce                # "enforce" (default) or "observe" (log only, never block)
+approval_ttl_seconds: 900    # held requests expire after this (default 900)
+receipt_ttl_seconds: 900     # signed receipts expire after this (default 900)
 
 rules:
-  - id: unique-rule-id        # Human-readable identifier
-    tool: tool_name            # Exact match on MCP tool name
-    action: allow              # allow | block | require_approval
+  - id: unique-rule-id       # unique identifier
+    tool: tool_name          # exact tool name (tools/call rules)
+    action: allow            # allow | block | require_approval
+
+  - id: hold-reads
+    method: resources/read   # govern another method (no "tool" field)
+    action: require_approval
+
+  - id: hold-email
+    tool: send_email
+    action: require_approval
+    reversibility: reversible  # reversible | irreversible (default: irreversible)
+    countdown_seconds: 300     # reversible only: auto-release unless someone holds it
+
+  - id: spend
+    tool: spend
+    action: require_approval
+    cap_usd: 50                # under the cap: runs now, shows in Verify; at/over: hard stop
+    amount_arg: amount_usd     # required with cap_usd: the argument the tool actually charges
 ```
 
+The loader is strict: an unknown key, a duplicate rule, a countdown on an irreversible rule, or `cap_usd` without `amount_arg` fails at startup instead of being ignored. A missing or non-numeric amount is a hard stop. Agent metadata under `_pp` (`confidence`, `requires_input`) can route a card to a different lane but can never turn a held or blocked call into an allowed one, and `requires_input` never changes how an irreversible hold is presented.
+
 ### Modes
 
 | Mode | Behavior |
@@ -104,45 +121,72 @@ Use `observe` mode to audit what *would* be blocked before turning enforcement o
 |--------|----------|-------------------|
 | `allow` | Forward request to server | — |
 | `block` | Reject immediately | `-32001` |
-| `require_approval` | Reject with hold status | `-32002` |
+| `require_approval` | Hold for approval (or reject without an approval UI) | `-32002` |
+
+Other errors the agent can receive: `-32003` denied by a human, `-32004` approval request expired, `-32005` release refused (receipt failed verification), `-32700` / `-32600` / `-32602` malformed input.
 
 ## Receipts
 
-Every `tools/call` decision generates an immutable receipt:
+Every decision produces a signed receipt (v2): a small **envelope** that is signed, plus a **display** block for people that is not.
 
 ```json
 {
-  "receipt_id": "550e8400-e29b-41d4-a716-446655440000",
-  "timestamp": "2026-03-20T15:30:00.000Z",
-  "agent_id": "my-agent",
-  "tool_name": "delete_user_data",
-  "decision": "blocked",
-  "reason": "Matched rule \"block-dangerous-delete\"",
-  "rule_id": "block-dangerous-delete",
-  "request_payload_hash": "sha256-hex-string",
-  "target_server": "node my-mcp-server.js",
-  "mode": "enforce"
+  "envelope": {
+    "v": 2,
+    "receipt_id": "rcpt_mg_mvtj9td5_63c091bfe0e7",
+    "method": "tools/call",
+    "tool": "deploy",
+    "args_sha256": "<sha256 of the canonical arguments the server received>",
+    "scope": { "scope": "deploy:production", "ref": null, "sha": "a1b2c3d4" },
+    "decision": "allowed",
+    "approval": { "kind": "human", "id": "rod", "via": "local-token" },
+    "actor": "my-agent",
+    "rule_id": "deploy",
+    "policy_sha256": "<sha256 of pp.config.yaml>",
+    "mode": "enforce",
+    "issued_at": "2026-10-29T15:30:00.000Z",
+    "expires_at": "2026-10-29T15:45:00.000Z",
+    "nonce": "<random>",
+    "key_id": "pp-dev-3c1d2e4f5a6b7c8d"
+  },
+  "signature": { "alg": "ed25519", "key_id": "pp-dev-3c1d2e4f5a6b7c8d", "value": "<hex>" },
+  "display": { "summary": "…", "reason": "…", "risk_tier": "high", "target_server": "node server.js", "arg_keys": ["env", "sha"], "viewer_url": "…" }
 }
 ```
 
-Receipts are written to:
-- **stderr** — for real-time monitoring
-- **pp-receipts.jsonl** — append-only audit file
+- The signature covers `pp-mcp-guard-receipt-v2\n` + canonical JSON of the whole envelope, so no authority field can be edited or re-split.
+- `approval` says who authorized the action: `human` (the approval UI operator) or `policy` (a rule, a standing spend cap, or a countdown).
+- Receipts never contain raw arguments — only `args_sha256` and the argument names, plus the scope identifiers a scoped receipt is bound to (environment, ref, commit SHA). Raw arguments appear only in the authenticated approval UI, which shows every argument and the scope an approval signs for.
+- The signing key lives in `~/.config/mcp-guard/keys` (or `$PP_KEYS_DIR`), never in the working directory. Its id is derived from the public key. MCP Guard refuses to start if the private key is readable by others.
 
-The `request_payload_hash` is a SHA-256 of the full request params, so you can verify what was sent without storing sensitive arguments.
+Receipts are written to stderr (one summary line), `pp-receipts.jsonl` (or `$PP_SHARED_RECEIPTS_PATH`), and optionally POSTed to `$PP_RECEIPT_ENDPOINT` (with `$PP_RECEIPT_TOKEN` as bearer auth).
 
-**[→ Visualize your receipts](https://permission-protocol.github.io/mcp-guard/)** — paste a receipt or upload `pp-receipts.jsonl` to see a visual summary.
+### Verifying a receipt
+
+```bash
+# Once: export the public key and commit it on your default branch
+mcp-guard export-key .pp/mcp-guard.pub.pem
+
+# In CI: verify offline against the pinned key
+mcp-guard verify --receipt-file receipt.json --pubkey .pp/mcp-guard.pub.pem \
+  --scope deploy:production --scope-sha "$GITHUB_SHA"
+```
+
+The verifier requires `--scope`, accepts only the keys you pin, requires an unexpired `allowed` receipt, checks scope exactly, and refuses scoped receipts that no human approved (pass `--allow-policy-approval` to accept them). Exit 0 = authorized, 1 = refused, 2 = missing input. See `templates/github-actions/receipt-gate.yml` for a deploy workflow that takes the verifier, key and receipt only from trusted places.
 
 ## CLI
 
 ```
 mcp-guard [options] -- <server command>
+mcp-guard verify --receipt-file <path> --pubkey <pem> [--scope s] [--scope-ref r] [--scope-sha h]
+mcp-guard export-key [out.pem]
 
 Options:
-  --config <path>     Path to config file (default: ./pp.config.yaml)
-  --agent-id <id>     Agent identifier for receipts (default: "unknown")
+  --config <path>         Path to config file (default: ./pp.config.yaml)
+  --agent-id <id>         Agent identifier for receipts (default: "unknown")
+  --operator <name>       Approver name recorded on receipts (default: OS username)
   --mode <mode>           enforce or observe (overrides config file)
-  --approval-port <port>  Enable approval UI on this port (e.g. 3100)
+  --approval-port <port>  Enable the approval UI on 127.0.0.1:<port>
   -h, --help              Show help
 ```
 
@@ -174,29 +218,27 @@ With:
 }
 ```
 
-## Approval Flow (v0.1)
+## Approval Flow
 
-When a tool call matches a `require_approval` rule, MCP Guard can hold the request open and wait for human approval via a web UI — instead of rejecting immediately.
+When a call matches a `require_approval` rule, MCP Guard can hold it open and wait for a human in a local web UI instead of rejecting it.
 
 ```bash
-# Start with approval UI on port 3100
 mcp-guard --config pp.config.yaml --approval-port 3100 -- node my-mcp-server.js
-
-# Open http://localhost:3100 to see pending approvals
+# stderr: [mcp-guard] Approval UI: http://127.0.0.1:3100/#t=<token>
 ```
 
+Open the exact URL printed at startup. The part after `#t=` is a per-process access token; it never leaves the browser except as the `Authorization: Bearer` header on API calls.
+
 **How it works:**
-1. Agent calls a tool that requires approval
-2. MCP Guard holds the JSON-RPC response open (does NOT return an error)
-3. The tool call appears in the approval UI at `http://localhost:<port>`
-4. Human clicks **Approve** → request is forwarded to the server, response returned to the agent
-5. Human clicks **Deny** → JSON-RPC error (-32002) returned to the agent
+1. Agent calls a tool that requires approval; MCP Guard holds the response open.
+2. The call appears in the UI with every argument the server will receive.
+3. **Approve** → MCP Guard signs a receipt naming you as the approver, verifies it, then forwards the call.
+4. **Deny** → the agent gets error `-32003`. A decision is final: approving a denied call returns 409.
+5. No decision within `approval_ttl_seconds` → the agent gets error `-32004`.
 
-When `--approval-port` is **not** set, `require_approval` tools return an error immediately (original behavior, no change).
+**Security of the approval channel:** it listens on 127.0.0.1 only, rejects any other `Host` header, sends no CORS headers, and requires the token on every API route except the HMAC-signed GitHub webhook. `PP_APPROVAL_TOKEN` (32+ characters) supplies the token instead of generating one. The wrapped server is started without any `PP_*` environment variables, so a tool that echoes its environment cannot leak the token.
 
-The approval UI auto-refreshes every 3 seconds and shows:
-- Pending tool calls with collapsible arguments
-- Recent decision history (last 20)
+When `--approval-port` is **not** set, `require_approval` calls return `-32002` immediately.
 
 ## Why not just use X?
 
@@ -210,7 +252,7 @@ The approval UI auto-refreshes every 3 seconds and shows:
 
 - **Not a dashboard.** It's a proxy. It sits in the data path and enforces rules.
 - **Not a scanner.** It doesn't analyze your code or model outputs. It gates tool calls.
-- **Not compliance theater.** Every decision has a cryptographic receipt.
+- **Not compliance theater.** Every decision has an Ed25519-signed receipt that names who authorized it.
 - **Not a replacement for good architecture.** It's one layer in a defense-in-depth strategy.
 
 Agents shouldn't be able to execute arbitrary actions without an explicit decision point.

package/SECURITY.md

@@ -0,0 +1,40 @@
+# Security Policy
+
+This repository contains MCP Guard, the Permission Protocol stdio policy proxy for MCP tool calls.
+
+## Reporting a vulnerability
+
+**Do not open public issues for security vulnerabilities.**
+
+Email: security@permissionprotocol.com
+
+Include a description, steps to reproduce, and your assessment of impact. We acknowledge reports within 48 hours and keep you informed through resolution.
+
+Machine-readable contact: https://www.permissionprotocol.com/.well-known/security.txt
+
+## Threat model
+
+MCP Guard assumes the agent behind the MCP client is untrusted: it controls every tool argument, can send any bytes on stdin, and may be able to reach local ports. MCP Guard defends against that agent:
+
+- **Input:** only single, well-formed JSON-RPC 2.0 objects are evaluated, and only the evaluated object is forwarded (re-serialized). Batches and unparseable lines are refused.
+- **Policy:** every method except protocol plumbing is decided by the rules. Agent metadata (`_pp`) can add human attention but never removes it; spend caps read only the argument the rule names.
+- **Approval channel:** loopback only, Host-checked, no CORS, and a per-process bearer token delivered in the URL fragment. Decisions go through one state machine; final states never change.
+- **Receipts:** Ed25519 over a domain-separated canonical envelope, with expiry, nonce and approver. Verifiers trust only pinned keys and refuse scoped receipts no human approved.
+- **Keys:** kept in the operator's config directory with owner-only permissions; MCP Guard refuses to start if the private key is exposed.
+
+Out of scope for the local dev signer: an agent running as the **same OS user** with arbitrary shell access can read that user's files and process memory, including the signing key and the approval token. For that threat, run the agent as a different user or use the managed Permission Protocol signer, where approval and signing happen outside the agent's machine.
+
+## Safe harbor
+
+We will not pursue or support legal action against good-faith security research that:
+
+- respects user privacy and does not access, modify, or destroy data that is not yours;
+- avoids service disruption (no denial of service, no spam);
+- gives us reasonable time to remediate before public disclosure.
+
+If you are unsure whether something is in scope, ask first at the address above.
+
+## Notes
+
+- There is no formal bug bounty program today. With your permission, we credit reporters in release notes.
+- Our security and compliance posture is published at https://www.permissionprotocol.com/trust.

package/dist/src/approval-server.d.ts

@@ -1,4 +1,70 @@
-import type { Receipt } from './receipt.js';
+import { type PendingAction } from './pending.js';
+import type { Lane } from './engine.js';
+import type { Reversibility } from './config.js';
+import { type Approval, type Receipt } from './receipt.js';
+/**
+ * The local approval channel.
+ *
+ * - Listens on 127.0.0.1 only and rejects any Host header but its own (DNS rebinding).
+ * - Sends no CORS headers: other origins cannot read or drive it.
+ * - Every /api route except the GitHub webhook needs `Authorization: Bearer <token>`.
+ *   The token is generated per process (or supplied via PP_APPROVAL_TOKEN) and reaches
+ *   the browser only in the URL fragment printed at startup; GET / holds no secret.
+ * - Every decision goes through the pending-queue state machine, so final states hold.
+ */
+export declare const MIN_TOKEN_LENGTH = 32;
 export declare function pushReceipt(receipt: Receipt): void;
-export declare function setOnApprove(cb: (id: string) => void): void;
-export declare function startApprovalServer(port: number): void;
+export interface ApprovalHooks {
+    /** Release a held request the human approved: sign, forward, return the receipt. */
+    release?: (action: PendingAction, approval: Approval) => Receipt;
+}
+export interface ApprovalServerOptions {
+    port: number;
+    /** Bearer token; defaults to PP_APPROVAL_TOKEN, else 32 random bytes. */
+    token?: string;
+    /** Recorded as the approver on human decisions; defaults to the OS username. */
+    operator?: string;
+    hooks?: ApprovalHooks;
+    /** For receipts issued on webhook-sourced decisions. */
+    receiptTtlSeconds?: number;
+    policySha256?: string;
+}
+export interface ApprovalServerHandle {
+    token: string;
+    operator: string;
+    /** Resolves with the bound port once listening. */
+    ready: Promise<number>;
+    close: () => Promise<void>;
+}
+/** The QueueItem shape from the API contract (backend ⇄ console). */
+export interface QueueItem {
+    id: string;
+    tool_name: string;
+    lane: Lane;
+    reversibility: Reversibility;
+    countdown_seconds?: number;
+    countdown_remaining?: number;
+    confidence?: number;
+    summary: string;
+    args_preview: string;
+    /** Every argument the server will receive, so the approver sees all of it. */
+    args_full: string;
+    /** What an approval authorizes, when the receipt is scoped (merge, migration, deploy). */
+    scope?: {
+        scope: string;
+        ref: string | null;
+        sha: string | null;
+    };
+    agent_id: string;
+    rule_id: string | null;
+    status: PendingAction['status'];
+    acted: boolean;
+    created_at: string;
+    expires_at?: string;
+    receipt_id?: string;
+}
+export declare function toQueueItem(p: PendingAction): QueueItem;
+export declare function pendingQueue(): QueueItem[];
+/** Call after any queue mutation so SSE subscribers see it immediately. */
+export declare function notifyQueueChange(): void;
+export declare function startApprovalServer(opts: ApprovalServerOptions): ApprovalServerHandle;