# Privacy and data

## What ships in this project

The release source should contain reusable code, synthetic tests, documentation and license notices only. It does not require an author's account, home directory, server address, model credentials, browser token, session transcript or deployment record.

There is no bundled provider account. Each installation uses the providers already configured in its own DSH instance. The package name, runtime service and storage domain are neutral project identifiers, not usernames.

## What is stored when you use it

DSH's storage-domain backend saves records under the neutral subagent_model_policy domain in the configured DSH home's storages directory. The records contain:

- A session ID, creation timestamp and workspace directory, used to distinguish session identities safely.
- The owning root session's identity for a child binding.
- A provider ID, model ID and optional reasoning-effort value.
- A revision number and whether a child binding is pending or fixed.

These are installation-specific runtime records. They are not source files and must not be included in a release archive or source repository. Workspace paths and provider names can reveal information about an installation even when no password is present.

The plugin's records do not contain API keys or conversation transcripts. DSH itself still stores and processes its normal session history, settings and credentials separately. This plugin does not replace DSH's privacy or authentication controls.

## Network and model routing

The runtime plugin does not add telemetry, a separate network listener or direct external network calls. Its browser UI calls its Host Remote methods through DSH's existing connection. Provider catalogs and metadata come from DSH's model service, which may contact configured providers under their existing settings.

Choosing a different provider changes where DSH sends that subagent's model requests and associated content. This is a model-routing control, not an anonymizer or data-loss-prevention boundary. Review the chosen provider's policies and your own data-handling requirements.

Explicit installation helpers may inspect local runtime paths and create local native-peer links. They do not upload source or settings and should not require credentials. Installing through DSH's package manager is a separate operation governed by that manager's network and security policies.

## Access, logs and reports

The plugin shares the existing DSH instance's authentication and trust boundary. It does not create separate accounts, per-session access-control rules or a multi-tenant permission boundary.

Save/validation failures and provider errors may appear in the UI or DSH logs. Errors originating in a provider or native runtime can contain local paths or other installation details. Review and redact logs and screenshots before sharing them. Never post API keys, browser pairing URLs, cookies, raw session storage or real conversation histories in an issue report.

Use synthetic examples when reporting a bug. The DSH version, Node version, operating system, reproduction steps and a redacted error are usually enough to begin.

## Backups, removal and sharing

Back up policy records with the corresponding DSH sessions and profile. Deleting bindings can remove the information needed to preserve an existing worker's route. Unregistering the plugin stops enforcement even if the records remain.

Do not copy someone else's policy storage into your installation. Do not place runtime data or native-peer links in a public release. A clean release should be assembled from an explicit file list, with no parent repository history or machine-generated dependencies.