dsh-cloudflare-access

DeepSeek Harness locks privileged APIs such as Settings, Credentials, and Agent Preset management to loopback by design. The moment DSH runs on a remote server, a user can front the UI with Cloudflare Access but the backend still rejects every remote privileged request. dsh-cloudflare-access fills exactly that gap: it does not replace Access, does not ship a login page or MFA, and instead re-validates the Cf-Access-Jwt-Assertion header injected by Cloudflare right inside the DSH origin process, making remote privileged endpoints genuinely reachable.\n\nEvery remote privileged request must clear a two-gate check: a Host/Origin validation pinned by --trusted-host and a full JWT verification covering signature, issuer, audience, and expiry (with roughly 30 seconds of clock skew tolerated). Missing or invalid credentials return 401/403 and never touch the privileged implementation. Loopback traffic remains entirely untouched, so SSH-tunnel-to-localhost workflows keep working as before. For non-privileged remote endpoints like the events WebSocket, a three-tier ordinary mode (off, optional, required) lets operators tighten or relax access per deployment.\n\nIf you run a DSH Web profile on a VPS or an internal-server host, put Cloudflare Access in front of it as the single identity provider, and want to manage settings or credentials from a browser without exposing DSH to the open internet, this plugin is the missing piece. It reads only the assertion header, stores no credentials, ignores the CF_Authorization cookie, and never logs tokens. Trust stays in Cloudflare; DSH performs the smallest possible second check.