sdkextensionsdesktop-ai

Extending Claude/Cowork: SDK patterns and safe plugin extension design for desktop LLMs

UUnknown

2026-02-17

10 min read

Practical SDK and extension patterns for desktop LLMs (Claude/Cowork): manifests, capability tokens, WASM sandboxes, and audit-ready logs.

Why SDK patterns for desktop LLM plugins matter in 2026

Developer productivity collides with security and auditability when you let large language models operate on a user's desktop. Tools like Anthropic's Claude and its Cowork desktop research preview (late 2025) make it easy for an agent to reorganize files, synthesize documents, and run local automation — and that power forces platform teams to answer: how do we let third-party extensions move fast without risking data exfiltration, privilege escalation, or untraceable side-effects?

This article gives practical SDK and extension design patterns for desktop LLM hosts (Claude, Cowork, and similar apps) that balance developer ergonomics with secure, auditable operation. If your team builds a plugin ecosystem for a local LLM host, you'll find concrete patterns, a permission model recipe, sandboxing options, audit schemas, and tooling suggestions that you can implement today.

Top-level design principles

Least privilege by default — plugins only get capabilities they explicitly need.
Capability-based authorization — grant fine-grained, delegable tokens, not broad OS credentials.
Defense in depth — combine language-level controls (type systems, linting) with runtime sandboxing (WASM, process isolation) and OS policies (seccomp, AppArmor).
Auditability & accountability — every operation that touches user data must produce structured, tamper-evident logs.
Developer ergonomics — offer a test harness, API mocks, and clear manifest schemas so authors can build quickly without bypassing security.

2026 context: Why desktop LLMs change the rules

By 2026 we've seen desktop LLMs evolve from chat assistants to agents with autonomous file-system access, local automation, and integration into productivity apps. Anthropic's Cowork (research preview launched in late 2025) pushed this forward by enabling agent-driven file ops for non-technical users. Enterprise adoption accelerated demand for secure plugin ecosystems that satisfy compliance (SOC2, ISO 27001) and give security teams control without crippling developer productivity.

Recent trends you must design for:

Wider use of WebAssembly (WASM + WASI) as a portable, sandboxable runtime for extensions.
Capability-delegation schemes (UCAN/macaroons-like approaches) replacing coarse OAuth scopes for local resource access.
Stricter enterprise requirements for signed plugins, SBOMs, and reproducible builds (SLSA alignment).
Increased regulatory scrutiny on autonomous agents and data exfiltration vectors.

Core SDK patterns for safe extension ecosystems

1) Manifest-first, declarative capability model

Every plugin ships with a manifest describing the permissions it needs, entrypoints, and metadata. A manifest is the single source of truth for permission negotiation, store listing, and risk review.

{
  "name": "sheet-gen",
  "version": "1.0.2",
  "entry": "dist/main.wasm",
  "runtime": "wasm",
  "permissions": [
    {"resource": "filesystem:/Documents/Spreadsheets", "actions": ["read", "write"]},
    {"resource": "clipboard", "actions": ["write"]}
  ],
  "publisher": {"name": "Acme AI", "signature": "MEUCIQ..."}
}

Manifest design tips:

Use resource-based permissions (paths, URL patterns) instead of abstract scopes.
Include a risk score field computed at submission time for store visibility.
Require publisher identity and a signature for tamper-evidence.

2) Capability tokens for fine-grained, revocable access

A capability token is a cryptographically-signed artifact granting specific actions on a resource, optionally time-limited and audience-bound. Avoid giving plugins the host's full OS credentials (e.g., avoid shipping ACCESS_TOKEN that maps to user-level keys).

// Example capability token payload (conceptual)
{
  "typ":"cap",
  "iss":"host.app",
  "sub":"plugin:sheet-gen",
  "res":"filesystem:/Documents/Spreadsheets/report.xlsx",
  "acts":["read","write"],
  "exp":1710000000
}

Use patterns like:

Short-lived tokens for active sessions.
Offline tokens hashed and stored with HSM-backed keys for enterprise deployments.
Delegable sub-capabilities when a plugin needs to call another plugin or a helper process.

3) Sandbox-first runtime choices

Choose the least-permissive runtime that still meets your ecosystem's needs. Common patterns in 2026:

WASM (WASI) sandboxes for deterministic, portable plugins with a small surface area — use Wasmtime or WasmEdge and expose an explicit host-API surface via interfaces.
Language sandboxes (Node workers, restricted Python interpreters) for richer plugin logic — combine with OS process isolation + seccomp/AppArmor profiles.
Native helper processes in containers for heavyweight integrations, but only with strict network and filesystem policies.

Example host policy for WASM-based plugins:

Only allow WASI file descriptors that map to approved resource tokens.
Block networking by default; open HTTP fetch only via host APIs that enforce egress filters and audit logging.
Limit CPU and memory via runtime configurations to avoid crypto-mining or DoS.

Plugin-host communication: API surface patterns

Design the host API as a minimal facade that mediates access to sensitive capabilities. Patterns to follow:

RPC-over-IPC with typed schemas (JSON-RPC or Cap’n Proto) where every call carries a capability token.
Event-based model where the host emits events (file-opened, user-authenticated) and plugins register handlers with restricted scopes.
Mediator service for cross-plugin communication so the host can enforce policy when a plugin tries to call another plugin.

// TypeScript-like SDK skeleton for a host facade
class HostAPI {
  constructor(private capToken: string) {}

  async readFile(path:string){
    return rpc('fs.read', {path}, this.capToken);
  }

  async writeFile(path:string, contents:string){
    return rpc('fs.write', {path, contents}, this.capToken);
  }
}

Permission negotiation UX: user prompts and enterprise policy

Good UX reduces risky user overrides. Patterns:

At install time, show a clear, resource-scoped permission screen. Avoid generic statements like "access all files".
Allow admins to pre-approve plugins with signed manifests and set enterprise policies that auto-grant certain capabilities for whitelisted publishers.
For sensitive operations (network egress, process spawn), require an explicit run-time confirmation that shows exactly what resource and data will be involved.

Principle: Never let user convenience be the only defense. Prompt design + default-deny policies are your first line of defense.

Auditability: structured logs and tamper-evidence

Design logs to be structured, machine-readable, and linkable to capability tokens and manifests. An audit event should include:

Actor (plugin ID + publisher)
Action (read, write, network.connect)
Resource (path, URL)
Capability token ID (hashed)
Outcome and checksum of changed data
Timestamp and host signature

{
  "event_id":"evt_01G4X...",
  "ts":"2026-01-15T10:22:00Z",
  "actor":"plugin:sheet-gen@1.0.2",
  "action":"fs.write",
  "resource":"/Users/alice/Documents/Spreadsheets/report.xlsx",
  "cap_hash":"sha256:...",
  "result":"success",
  "host_sig":"MEQCIG..."
}

Operational recommendations:

Send logs to a local append-only ledger and to enterprise SIEM; sign logs with the host key.
Include before/after content hashes for sensitive writes so incident responders can detect unauthorized data modifications.
Offer a tamper-evidence mode where logs are anchored to a public transparency log (optional for cloud-connected deployments). See audit trail best practices for ideas about structured, auditable events.

Developer ergonomics: SDK features that remove risky shortcuts

Security fails when developers bypass the hosted APIs. The SDK should make the secure path the easiest path.

Provide a local sandbox runner that simulates capability negotiation and produces the same logs as a host. Fast inner loop means fewer hacks.
Type definitions and lint rules that fail CI when the manifest requests wildcard permissions (e.g., filesystem:/*)
CLI scaffolding (generate manifest, test harness, package, sign) and a plugin store submission flow that enforces SBOMs and signature checks.

// Local test harness pseudocode
$ cw-sdk init plugin
$ cw-sdk run --sandbox --cap=fs:/tmp/test
// SDK produces detailed audit events even in sandbox

Sandboxing options compared (practical trade-offs)

WASM/WASI
- Pros: Strong isolation, portable, deterministic limits
- Cons: More work for complex native bindings; need careful host API design
Process isolation + seccomp/AppArmor
- Pros: Familiar to app developers, supports full-featured runtimes
- Cons: Harder to guarantee complete isolation across OS versions
Containers
- Pros: Very strong isolation and resource control
- Cons: Overhead on desktop; requires container runtime and image management

CI/CD, signing, and supply chain controls

To prevent malicious plugins, require:

Signed plugin artifacts (publisher keys stored in a trust registry).
SBOMs generated by build pipelines (CycloneDX or SPDX) and a SLSA-like provenance attestation.
Static analysis and sandboxed tests triggered in CI that simulate host policies.

Example pipeline checklist:

Build (reproducible flags)
Generate SBOM + provenance
Run unit tests + host-api contract tests in sandbox
Sign artifact with publisher key
Submit to store; automated policies validate manifest and SBOM

Practical code example: minimal TypeScript SDK flow

The following is a simplified flow for a plugin requesting a capability and performing a file write through the host facade. This is conceptual and uses an RPC helper that the SDK provides.

import {HostClient} from 'cw-host-sdk';

async function main(){
  // Host injects a bootstrap token identifying the plugin process
  const bootstrap = process.env.CW_BOOTSTRAP_TOKEN;
  const client = new HostClient(bootstrap);

  // Negotiate a capability for a single file
  const cap = await client.requestCapability({
    resource: 'filesystem:/Users/alice/Documents/Spreadsheets/report.xlsx',
    actions: ['write'],
    ttl: 60 // seconds
  });

  // Create a facade bound to the granted capability
  const fs = client.forCapability(cap);
  await fs.write('/Users/alice/Documents/Spreadsheets/report.xlsx', 'data,1,2,3');
}

main().catch(console.error);

Testing, threat modeling, and incident response

Include extension-specific threat modeling as part of your store review. Key threats:

Data exfiltration via network or indirect channels (clipboard, telemetry)
Privilege escalation by accessing unexpected system paths
Supply chain compromise of plugin packages or publisher keys

Operationalize detection:

Alert on unusual patterns: plugins that request network + filesystem in same session.
Use behavioral baselines and anomaly detection in audit logs.
Provide an emergency revoke mechanism to invalidate capability tokens and quarantine plugins.

Real-world pattern: host-mediated connectors

For integrations to external services, implement a host-mediated connector pattern:

Plugins ask the host to perform outbound requests through a connector.
The host applies enterprise egress filters, injects app-level credentials, and logs requests with capability context. See notes on edge orchestration and how mediation helps enforce policy.
This avoids placing secrets in plugin code while preserving plugin expressiveness.

Future-proofing: trends for 2026 and beyond

Expect these directions to matter as the ecosystem matures:

Zero-trust local capability systems that make every host API call independently verifiable.
Hardware-backed attestation on end-user devices for high-assurance enterprise deployments — related to the growing conversation about edge identity and device-backed credentials.
Standardization efforts for plugin manifests, capability tokens, and audit schemas driven by platform vendors and security consortia.

Actionable implementation checklist

Define a manifest schema with granular resource permissions; require publisher signatures.
Implement capability tokens with short TTLs and auditable token hashes in logs.
Choose a sandbox strategy (WASM first if you need portability).
Design a minimal host API facade; require tokens on every call.
Produce structured audit events and stream to SIEM; anchor logs for tamper-evidence where needed.
Ship an SDK with local sandbox runner, scaffolding, and lint rules.
Enforce supply chain controls: SBOM, signing, and reproducible builds in CI.

Conclusion — balancing productivity, security, and trust

Desktop LLM hosts like Claude and Cowork make localized automation compelling. But the same features that increase productivity — file access, network integration, and autonomous actions — also increase risk. The right SDK patterns make the secure path the easiest path for developers: manifest-first permission declarations, capability tokens, sandboxed runtimes (WASM or process isolation), structured audit logging, and a developer experience that includes a local sandbox and CI checks.

Start with a narrow surface area and iterate: expose one host capability at a time, collect metrics, and adapt policies from real-world usage. With these patterns you can build a thriving plugin ecosystem that scales without sacrificing security or auditability.

Next steps

If you’re designing a plugin platform for desktop LLMs, start by drafting a manifest schema and a minimal host API. Prototype a WASM runtime with capability tokens and a local sandbox runner. Measure developer friction and adjust: when secure defaults are also the simplest developer workflow, you've won.

Call to action

Want a reference implementation and CI templates that implement these patterns? Download our starter SDK, manifest schema, and sandbox runner from devtools.cloud’s repository — built specifically for desktop LLM hosts like Claude/Cowork. Get the starter kit, run the sandbox, and harden your extension pipeline for production-ready security and auditability.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.