[GH-ISSUE #1839] [Feature] Add native DeepSeek Harness (DSH) client support to REA setup #619

New issue

Closed

opened 2026-10-15 18:26:41 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:26:41 +00:00

Owner

Originally created by @whoishaha on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1839

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Setup, packaging, or upgrade

Current limitation

REA supports guided MCP registration for multiple agent clients through rea setup, but DeepSeek Harness (DSH) is not currently included in the supported client list.

REA already documents manual DSH integration using @deepseek-ai/dsh-mcp-client and a Cordis YAML patch. However, users must manually locate and edit the DSH configuration, resolve the REA MCP launcher, and verify the registration.

Unlike other supported clients, DSH cannot currently be configured or diagnosed through REA's standard setup --client and doctor --client workflows.

This is a client onboarding and configuration-management gap, not a limitation of REA's existing MCP server.

Use cases

First-time setup: A DSH user wants to install REA through npx rea-agents setup and register the local REA MCP server without manually editing Cordis YAML files.
Reverse-engineering workflows: A DSH agent needs access to REA's existing MCP tools to investigate local binaries or JavaScript applications, using the same setup experience available to other supported agents.
Configuration diagnostics: Users need to verify whether the REA MCP server is correctly registered in DSH and identify missing, invalid, or conflicting configurations.
Configuration maintenance: Users need to update or remove REA-managed registrations without affecting unrelated DSH plugins or user settings.

The current manual configuration works but lacks the guided setup, validation, idempotency, and lifecycle management provided for supported clients.

Desired outcome and success criteria

Add first-class DeepSeek Harness support to REA's existing client integration workflow.
Expected behavior:

rea setup --client dsh --dry-run --json previews the configuration changes without modifying files.
rea setup --client dsh --yes --json registers REA's stdio MCP server using DSH's supported Cordis configuration format.
rea doctor --client dsh --json checks the registration and provides actionable diagnostics for missing or invalid configurations.
REA's existing uninstall workflow safely removes REA-owned DSH registrations without affecting unrelated settings.
Repeated setup is idempotent and does not create duplicate registrations.
Existing Cordis configuration, including unrelated plugins and supported YAML constructs, is preserved. Configurations that cannot be safely modified are reported without mutation.
The configured DSH client can discover and invoke REA tools through the existing mcp__rea__<tool_name> interface.
Existing client integrations and REA MCP tool contracts remain unchanged.

The integration should also reuse REA's existing approval, backup, and configuration verification mechanisms.

Authority boundaries and non-goals

REA-side changes only: No modifications to DeepSeek Harness source code or its MCP client implementation.
Configuration scope: Modify only explicitly approved, REA-managed entries in DSH's user configuration. Preserve unrelated plugins, profiles, and settings.
Process execution: Use DSH's existing MCP client to launch REA's stdio MCP server. No new arbitrary process-execution capability is introduced.
Target mutation: No changes to analyzed binaries, application files, or REA's analysis behavior.
Dependencies and licensing: Do not automatically install or upgrade DSH, MCP client plugins, reverse-engineering providers, or licensed analysis engines.
Evidence provenance: No changes to REA's evidence contracts, schemas, artifact identity, or analysis results.
Platform compatibility: Follow DSH's supported configuration-path semantics. Initial native validation can target Linux, with macOS and Windows coverage reported separately.
Non-goals: DSH Agent Loop modifications, new MCP tools, new analysis providers, and comprehensive management of every DSH profile in the initial implementation.

Alternatives considered

1. Manual MCP configuration
REA already documents how to register its MCP server in DSH through $DSH_HOME/cordis.patch.yml.
This works but requires manual configuration editing, launcher path resolution, duplicate-registration avoidance, and subsequent maintenance.

2. Skill-only installation
Installing REA's bundled skill through rea setup --skill makes the workflow instructions available to compatible agents but does not register the REA MCP server with DSH.

3. Modifying DeepSeek Harness directly
DSH already provides a native MCP client, so upstream source changes are unnecessary. The missing capability is REA's client configuration integration.

The proposed enhancement would provide a consistent setup experience without duplicating existing MCP functionality.

Possible direction

A possible approach is to extend REA's existing client-adapter infrastructure:

Register dsh as a supported client in the setup and doctor workflows.
Resolve the DSH user configuration path using DSH_HOME, with ~/.dsh/cordis.patch.yml as the documented default.
Add a DSH-specific configuration adapter that manages Cordis YAML patch entries for @deepseek-ai/dsh-mcp-client.
Generate an REA stdio registration with a stable server name and the version-pinned REA launcher.
Reuse the existing dry-run, approval, backup, idempotency, doctor, and uninstall mechanisms.
Preserve unrelated YAML content and fail safely when a configuration cannot be parsed or updated without loss.
Add configuration lifecycle tests, native DSH integration verification, and installation documentation.

The initial scope could target the user-level Cordis configuration documented by REA. Active-profile overrides and configuration precedence should be considered during validation, with broader profile management deferred if necessary.

This is only a proposed direction. Maintainer guidance on Cordis YAML handling and configuration scope would be welcome before implementation.

References

I'm interested in implementing this feature and submitting a PR with tests and documentation.

Before proceeding, I'd appreciate maintainer feedback on whether this integration would be welcome, particularly the preferred approach for safely managing DSH's Cordis YAML configuration.

Originally created by @whoishaha on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1839 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Setup, packaging, or upgrade ### Current limitation REA supports guided MCP registration for multiple agent clients through rea setup, but DeepSeek Harness (DSH) is not currently included in the supported client list. REA already documents manual DSH integration using @deepseek-ai/dsh-mcp-client and a Cordis YAML patch. However, users must manually locate and edit the DSH configuration, resolve the REA MCP launcher, and verify the registration. Unlike other supported clients, DSH cannot currently be configured or diagnosed through REA's standard setup --client and doctor --client workflows. This is a client onboarding and configuration-management gap, not a limitation of REA's existing MCP server. ### Use cases - First-time setup: A DSH user wants to install REA through npx rea-agents setup and register the local REA MCP server without manually editing Cordis YAML files. - Reverse-engineering workflows: A DSH agent needs access to REA's existing MCP tools to investigate local binaries or JavaScript applications, using the same setup experience available to other supported agents. - Configuration diagnostics: Users need to verify whether the REA MCP server is correctly registered in DSH and identify missing, invalid, or conflicting configurations. - Configuration maintenance: Users need to update or remove REA-managed registrations without affecting unrelated DSH plugins or user settings. The current manual configuration works but lacks the guided setup, validation, idempotency, and lifecycle management provided for supported clients. ### Desired outcome and success criteria Add first-class DeepSeek Harness support to REA's existing client integration workflow. Expected behavior: - rea setup --client dsh --dry-run --json previews the configuration changes without modifying files. - rea setup --client dsh --yes --json registers REA's stdio MCP server using DSH's supported Cordis configuration format. - rea doctor --client dsh --json checks the registration and provides actionable diagnostics for missing or invalid configurations. - REA's existing uninstall workflow safely removes REA-owned DSH registrations without affecting unrelated settings. - Repeated setup is idempotent and does not create duplicate registrations. - Existing Cordis configuration, including unrelated plugins and supported YAML constructs, is preserved. Configurations that cannot be safely modified are reported without mutation. - The configured DSH client can discover and invoke REA tools through the existing mcp__rea__<tool_name> interface. - Existing client integrations and REA MCP tool contracts remain unchanged. The integration should also reuse REA's existing approval, backup, and configuration verification mechanisms. ### Authority boundaries and non-goals - REA-side changes only: No modifications to DeepSeek Harness source code or its MCP client implementation. - Configuration scope: Modify only explicitly approved, REA-managed entries in DSH's user configuration. Preserve unrelated plugins, profiles, and settings. - Process execution: Use DSH's existing MCP client to launch REA's stdio MCP server. No new arbitrary process-execution capability is introduced. - Target mutation: No changes to analyzed binaries, application files, or REA's analysis behavior. - Dependencies and licensing: Do not automatically install or upgrade DSH, MCP client plugins, reverse-engineering providers, or licensed analysis engines. - Evidence provenance: No changes to REA's evidence contracts, schemas, artifact identity, or analysis results. - Platform compatibility: Follow DSH's supported configuration-path semantics. Initial native validation can target Linux, with macOS and Windows coverage reported separately. - Non-goals: DSH Agent Loop modifications, new MCP tools, new analysis providers, and comprehensive management of every DSH profile in the initial implementation. ### Alternatives considered **1. Manual MCP configuration** REA already documents how to register its MCP server in DSH through $DSH_HOME/cordis.patch.yml. This works but requires manual configuration editing, launcher path resolution, duplicate-registration avoidance, and subsequent maintenance. **2. Skill-only installation** Installing REA's bundled skill through rea setup --skill makes the workflow instructions available to compatible agents but does not register the REA MCP server with DSH. **3. Modifying DeepSeek Harness directly** DSH already provides a native MCP client, so upstream source changes are unnecessary. The missing capability is REA's client configuration integration. The proposed enhancement would provide a consistent setup experience without duplicating existing MCP functionality. ### Possible direction A possible approach is to extend REA's existing client-adapter infrastructure: 1. Register dsh as a supported client in the setup and doctor workflows. 2. Resolve the DSH user configuration path using DSH_HOME, with ~/.dsh/cordis.patch.yml as the documented default. 3. Add a DSH-specific configuration adapter that manages Cordis YAML patch entries for @deepseek-ai/dsh-mcp-client. 4. Generate an REA stdio registration with a stable server name and the version-pinned REA launcher. 5. Reuse the existing dry-run, approval, backup, idempotency, doctor, and uninstall mechanisms. 6. Preserve unrelated YAML content and fail safely when a configuration cannot be parsed or updated without loss. 7. Add configuration lifecycle tests, native DSH integration verification, and installation documentation. The initial scope could target the user-level Cordis configuration documented by REA. Active-profile overrides and configuration precedence should be considered during validation, with broader profile management deferred if necessary. This is only a proposed direction. Maintainer guidance on Cordis YAML handling and configuration scope would be welcome before implementation. ### References - [REA — Supported agents](https://github.com/morluto/rea/blob/main/docs/installation.md#supported-agents) - [REA — DeepSeek Harness manual integration](https://github.com/morluto/rea/blob/main/docs/installation.md#deepseek-harness) - [REA — Contributing guidelines](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md) - [PR #1376 — Native Pi client support](https://github.com/morluto/rea/pull/1376) - [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) - [DSH MCP Client documentation](https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/mcp/mcp-client/README.md) I'm interested in implementing this feature and submitting a PR with tests and documentation. Before proceeding, I'd appreciate maintainer feedback on whether this integration would be welcome, particularly the preferred approach for safely managing DSH's Cordis YAML configuration.

bsakaguchi

2026-10-15 18:26:41 +00:00