DeepSeek Harness v0.1.0-rc.7 Plugin Settings Cards

A new settings card appears, but your plugin configuration still behaves exactly as before.

The fastest answer: treat DeepSeek Harness v0.1.0-rc.7 plugin settings cards as a new management entry point, not as proof of a stable configuration contract. Do not rewrite working plugins on release day. Test one small, non-sensitive setting during the first week, keep validation and fallback paths, and wait for a documented compatibility promise before expanding the panel across a team.

This article is for plugin authors deciding whether an existing dsh-plugin needs adaptation, team maintainers trying to standardize settings across several plugins, and developers evaluating whether the “everything is a plugin” model is becoming a manageable product surface.

Last updated August 18, 2026. Release facts were checked against the official v0.1.0-rc.7 release information, the official repository, its configuration directories, and plugin-related source references.

Release day: a settings card changes the entry point, not the contract

The official release boundary is narrow. The v0.1.0-rc.7 announcement confirms that plugins can register their own settings cards. That confirms a change in how users may discover and manage plugin settings. It does not, by itself, confirm a complete public API, a final component model, a permission system, a migration layer, or a long-term persistence guarantee. (github.com)

That distinction matters because DeepSeek Harness is still described by the project as a developer preview with rapidly changing behavior and possible compatibility-breaking changes. The repository also identifies Cordis as part of the underlying architecture and uses dsh-plugin as a discoverability topic for plugin repositories. (github.com)

The practical interpretation is:

A settings card is therefore best understood as a presentation and management capability. It may eventually become part of a broader configuration system, but the release note alone does not establish that broader system.

New UI does not equal stable configuration semantics.

The first hidden risk is ownership. A value displayed in a card may still be loaded from a file, environment variable, plugin store, host store, or deployment layer. If you do not know which layer owns the value, a successful edit can create a misleading interface: the card appears to save the setting, but a restart or redeployment restores the old value.

The second risk is compatibility. A card may depend on host-side slot names, registration timing, component contracts, or storage behavior that can change while the project remains in preview. That is different from a mature settings platform with versioned schemas and published migration rules.

The third risk is failure scope. A malformed registration, missing key, or incompatible plugin hook may affect more than the card itself. Community discussions have raised concerns about plugin loading failures and keyed settings slots, but those discussions show community attention rather than official proof of the final API design.

First day: does an existing dsh-plugin actually need rc.7 adaptation?

Most existing plugins should not be refactored merely because a new card is available. Start by identifying what the plugin already uses.

A plugin usually falls into one of three practical groups:

This is where the phrase “DeepSeek Harness plugin settings cards” can mislead teams. The existence of a card does not mean every plugin must have one. A small plugin with one deployment-only value may be easier to operate through a checked-in configuration file. A user-facing plugin with selectable providers, modes, or behavior flags may gain real value from a card.

Check these conditions before assigning engineering work:

• Does the plugin load successfully on rc.7?
• Can it read its current configuration?
• Can it save a known safe value through its existing path?
• Does the value survive a normal refresh?
• Does the plugin depend on a fixed DOM structure, UI label, or internal host component?
• Does cordis.yml remain the source used during installation or deployment?
• Are there environment variables or startup flags that override the visible value?

If the plugin still loads and saves correctly, keep the current implementation. Open a compatibility task instead of starting a rewrite. The task should record what you observed, which path owns the configuration, and what official signal would justify further work.

This approach is safer than chasing the newest interface because it separates required adaptation from optional UX improvement.

What does a DeepSeek Harness plugin settings card actually mean?

For a developer, the card represents a possible bridge between plugin internals and user-facing management. It can make configuration discoverable, reduce manual file editing, and provide a consistent place for users to adjust values.

It does not automatically mean that the card is the canonical source of truth.

Think of the configuration model as four separate questions:

1. Registration: How does the plugin ask the host to display a card?
2. Schema: What fields, defaults, labels, and validation rules are supported?
3. Storage: Where is the value written?
4. Runtime effect: When does the running plugin consume the new value?

The release fact covers the first question at a high level. The other three require code inspection and reproduction. The official DeepSeek Harness development documentation is the right place to check for names and behavior that are actually published. Do not copy an API name from a community post into production code unless you can trace it to official source or reproduce it locally. (github.com)

This is also why you should avoid presenting a settings card as a replacement for cordis.yml. A deployment file may still be appropriate for installation-time dependencies, service wiring, default providers, or environment-specific values. A card may be more appropriate for user-adjustable runtime preferences. Those are different responsibilities.

First week: validate the smallest possible settings loop

Do not begin with API keys, production routing, or a large plugin with many dependent fields. Choose one harmless setting, such as a display mode, a non-sensitive feature toggle, or a local behavior preference.

Run the test as a timeline rather than as a one-time visual check.

Step 1: record the current configuration path

Before installing or enabling the card, write down:

• The current default value.
• The file, environment variable, or store that supplies it.
• The command or action that changes it.
• Whether the plugin reads the value at startup or during each operation.
• The expected fallback if the value is missing or invalid.

This gives you a baseline. Without it, you cannot tell whether the card changed the plugin or only changed the screen.

Step 2: register one safe field

Use only API, component, and lifecycle names that appear in the official rc.7 source, official documentation, or a real local reproduction. Avoid inventing a tutorial-style registration snippet from memory.

The first field should have:

• A deterministic default.
• A narrow set of valid values.
• No secret or personal data.
• A visible effect that is easy to reverse.
• A clear invalid-input behavior.

If the field cannot be explained in one sentence, it is too complex for the first trial.

Step 3: test read and render behavior

Start the host and confirm that the card appears for the intended plugin. Then compare the displayed value with the baseline value.

You are checking more than visibility:

• Does the card appear only when the plugin is loaded?
• Does the displayed default match the plugin’s actual default?
• Does a missing value render as an intentional fallback rather than an empty field?
• Does the card remain usable when the plugin has not completed its full runtime initialization?

A card that renders successfully can still be disconnected from the active configuration.

Step 4: change, save, and reload

Change the safe value, save it, refresh the interface, and open the card again. Then trigger the plugin behavior that should use the new value.

Record each result separately:

The important test is not “the button worked.” It is whether the runtime uses the saved value after the host has reloaded.

Step 5: test failure feedback and fallback

Submit an invalid value, remove the underlying configuration, or simulate a missing optional field. The plugin should reject unsafe input or return to a documented default.

You need to know:

• Whether invalid data is blocked before storage.
• Whether a failed save leaves the old value intact.
• Whether the card reports failure clearly.
• Whether the plugin remains loadable after a bad setting.
• Whether a manual configuration path can recover the plugin.

Keep the old recovery path until the new path has survived repeated testing.

Step 6: repeat after restart and upgrade

A refresh only tests the browser or Web UI state. Restart the host, restart the plugin process if applicable, and repeat the read test. Then test the same plugin against the next candidate or a controlled update when available.

The official DeepSeek Harness README warns that the project is in developer preview and may introduce compatibility-breaking changes. That makes restart and upgrade checks part of basic acceptance, not optional polish. (github.com)

Team rollout: separate plugin ownership from host ownership

A team should not adopt a shared settings panel until it can answer one question for every field: who owns this value?

Use this ownership model:

• Plugin-owned: The plugin defines the schema, validates the value, applies defaults, and documents runtime behavior.
• Host-owned: The host controls the value because it affects multiple plugins or shared services.
• Deployment-owned: The value belongs in infrastructure, installation, environment variables, or a checked-in deployment file.
• Secret-store-owned: The value is a credential or sensitive token and must not be exposed through ordinary display or logging.

The most common operational failure is duplicate write access. For example, a model endpoint may be editable through a settings card, an environment file, a deployment manifest, and a plugin-specific YAML file. The user changes one path, but another path wins during startup.

Before team adoption, create a small delivery record for each setting:

• Setting name and owner.
• Default value and accepted values.
• Version introduced.
• Validation rule.
• Permission requirement.
• Storage location.
• Runtime reload behavior.
• Manual fallback.
• Recovery action after a failed save.
• Whether the value may contain a secret.

This record is more valuable than a polished card because it defines responsibility when something breaks.

The Cordis architecture makes this separation important. The official repository describes DeepSeek Harness as a plugin-based system powered by Cordis, but that high-level architecture statement should not be treated as a guarantee that every plugin setting has identical lifecycle or storage semantics. (github.com)

Remote environments: test persistence, not just appearance

Remote development makes settings verification harder because several layers can retain stale state:

• The browser may cache the previous form value.
• The host process may keep an in-memory configuration.
• The plugin may load a different file after restart.
• A remote account may not have the same permissions as the test account.
• An upgrade may recreate the application directory.
• A deployment process may overwrite a user change.

If you operate a plugin on a remote Mac, repeat the test with a clean browser session, a host restart, a second permitted account, and a controlled redeployment. Do not record “persistent” simply because the card still showed the selected value after a page refresh.

Secrets need stricter handling. Use references to a secure store or environment injection where appropriate. Do not place real keys in screenshots, logs, issue reports, test fixtures, or example repositories. The card should expose the minimum information required to manage the secret, such as presence or status, rather than its actual value.

VMSPIN can be useful when you need a temporary remote Mac environment for this kind of controlled plugin evaluation. Start with the VMSPIN remote Mac environment overview to understand the available workflow, but keep the acceptance criteria independent of the hosting provider. If you are comparing a short pilot with a longer-running setup, use a neutral remote Mac test plan to define the machine, account, installation, restart, and recovery requirements before choosing an environment. A remote machine is only useful if you can reproduce the same install, restart, account, and recovery sequence.

Use this first-week acceptance checklist

Run the following checklist before you let a team depend on the new card:

• [ ] Confirm the plugin loads on v0.1.0-rc.7 without unrelated changes.
• [ ] Identify whether the current source of truth is the plugin, host, deployment file, or secret store.
• [ ] Select one non-sensitive setting with a deterministic default.
• [ ] Confirm that the card registers only through an official or reproduced API path.
• [ ] Verify that the displayed value matches the actual runtime value.
• [ ] Save a valid change and confirm the plugin behavior changes as expected.
• [ ] Submit an invalid value and record the rejection or fallback behavior.
• [ ] Refresh the interface and reopen the card.
• [ ] Restart the host and check the value again.
• [ ] Test the plugin with the intended user permissions.
• [ ] Verify that a deployment or upgrade does not silently overwrite the setting.
• [ ] Document a manual recovery path before removing the old configuration entry.
• [ ] Record the exact rc.7 build, plugin revision, and test environment.
• [ ] Recheck the result when official documentation or a later release changes.

A failed checkbox is not automatically a reason to abandon settings cards. It is a reason to limit rollout and identify the missing contract.

Which official signals should unlock wider investment?

Do not expand from one pilot plugin to a team-wide settings system until several signals line up.

First, look for a formal settings guide that defines registration, supported field types, validation, save behavior, and lifecycle timing. A release note that says a card can be registered is useful, but it is not a complete contract.

Second, look for an official example plugin. A maintained example can reveal the intended ownership model more reliably than isolated community snippets.

Third, look for compatibility language. The project currently warns that developer-preview changes may break compatibility, so your internal policy should treat every upgrade as a compatibility event. (github.com)

Fourth, check whether later release notes explain persistence and migration. You need to know what happens to an existing value when a field is renamed, removed, moved between storage layers, or changed from a scalar value to a structured object.

Until those signals appear, use a staged plan:

• Now: validate one safe setting on one plugin.
• After repeatable persistence: add a second plugin with a different configuration pattern.
• After documented API behavior: standardize shared components and team review rules.
• After migration guidance: move important user-facing configuration away from legacy paths.
• After compatibility commitments: consider broad panel adoption.

This staged plan also answers the common cordis.yml question. The card should not be assumed to replace cordis.yml. Keep deployment configuration where it is authoritative. Move a field only when the new ownership, persistence, and fallback behavior are documented and tested.

The decision for August 18, 2026

If you maintain an existing plugin and it still loads, reads, saves, and recovers correctly, do not perform a broad rc.7 rewrite this week.

If you are building a new plugin, add a minimal settings-card experiment only for a non-sensitive value, while preserving schema validation and a manual fallback.

If you manage several plugins, delay a unified settings standard until official examples and compatibility guidance define the contract.

Your current local or self-managed setup may be cheaper for a long-running workload, but it can also create inconsistent Node environments, permission drift, stale configuration files, and difficult restart reproduction across team members. A temporary Mac environment from VMSPIN can give you a cleaner place to compare installs and recovery steps without committing every developer to the same hardware. It is not automatically the best choice for permanent heavy workloads, always-on services, or tests that require direct physical interfaces.

For the next move, read the relevant DeepSeek Harness development and plugin recovery material in your documentation workflow, then run the smallest possible card test before building a team-wide configuration panel. Treat rc.7 as a release for controlled observation: let the evidence from registration, persistence, restart, and recovery decide how much you invest.