[Feature] Add DeepSeek Harness as a first-class client integration

[estelledc]

Area

Multiple areas

What are you trying to accomplish?

Add DeepSeek Harness (dsh) as a first-class OpenCodex client integration, alongside the existing file-based integrations.

Users should be able to enable OpenCodex from the dashboard or CLI, select OpenCodex models inside DeepSeek Harness, refresh the model catalog, and safely disable or restore the integration.

I am willing to lead the initial design and implementation and maintain the integration as DeepSeek Harness evolves.

What prevents this today?

DeepSeek Harness can already use an OpenAI Responses-compatible gateway through @deepseek-ai/dsh-llm-pi-ai, but users currently have to:

• edit $DSH_HOME/settings.yaml manually;
• maintain a duplicate model catalog;
• configure loopback authentication themselves;
• detect and repair configuration drift themselves;
• remove the integration without OpenCodex ownership or rollback protection.

OpenCodex does not currently detect or expose DeepSeek Harness in its Integrations dashboard or CLI.

What should OpenCodex do?

OpenCodex should:

• detect $DSH_HOME, falling back to ~/.dsh;
• expose DeepSeek Harness in the Integrations dashboard and CLI;
• manage only the OpenCodex-owned provider fragment under llm-pi-ai.providers.opencodex in settings.yaml;
• export the OpenCodex model catalog using the openai-responses protocol;
• include supported reasoning-effort metadata;
• refresh the managed fragment when the OpenCodex catalog changes;
• preserve unrelated DSH settings and the user's current default-model selection;
• support disable, ownership checks, snapshots, drift refusal, and restore through the existing Integrations framework;
• initially support loopback OpenCodex endpoints only.

The integration should not install DeepSeek Harness or replace the user's selected default model.

Example usage or interface

ocx integration client enable --client dsh
ocx integration client status --client dsh
ocx integration client disable --client dsh

After enabling it, the user selects the OpenCodex provider and an OpenCodex model from the DeepSeek Harness model selector.

Alternatives or workarounds

Manually adding an opencodex route to $DSH_HOME/settings.yaml works, but it provides no catalog refresh, ownership tracking, drift protection, or reversible uninstall.

A profile-level cordis.patch.yml integration was also considered, but the user settings layer already supports dynamic provider routes and avoids modifying every DSH profile.

Additional context

Compatibility baseline:

• DeepSeek Harness: 0.1.0-rc.6
• OpenCodex runtime tested: 2.14.0
• Responses text generation: passed
• High reasoning effort: passed
• Native parallel tool calls and tool-result continuation: passed
• Code-tools mode: passed
• Unknown-model failure: passed without silent fallback
• Settings-only integration without profile patches: passed
• Settings-only loopback integration without an additional environment variable: passed

Relevant DeepSeek Harness implementation:

https://github.com/deepseek-ai/deepseek-harness/tree/main/packages/llm/llm-pi-ai

DeepSeek Harness currently identifies provider requests with a stable deepseek-harness/<version> User-Agent. OpenCodex may use this for best-effort client attribution later, but attribution is not required for the initial configuration integration.

Because DeepSeek Harness is currently a developer preview, the integration should have focused configuration-schema and end-to-end compatibility tests.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.

[coderabbitai]

🔗 Related PRs

#333 - fix(codex): preserve external model providers [merged]
#616 - fix: preserve hosted image tool preferences [open]
#1122 - fix(anthropic): preserve response model metadata [open]
#1461 - fix(codex): preflight sync injection before catalog writes [merged]
#1606 - docs(devlog): routed tool-discovery profile plan with landing verification [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[lidge-jun]

Accepted as a scoped client-integration feature.

Verified against current dev: DSH is not an existing client integration. ExportClientId has no dsh member in src/clients/config-export.ts:410, and the runtime integration registry has no DSH path/detection entry in src/integrations/registry.ts:59. Your claim that OpenCodex does not currently detect, expose, or manage DeepSeek Harness reproduces from code reading; it is not already fixed on dev.

The requested ownership model fits the existing integration framework. A DSH exporter should emit one managed fragment at the exact llm-pi-ai.providers.opencodex path, because ExportClientSpec.buildContribution is the source of truth for fragments OpenCodex owns (src/clients/config-export.ts:443), while the writer already refuses foreign edits and preserves unrelated fragments. This must not become a whole-document YAML rewrite: the framework treats ownership as fragment-scoped, so disable/refresh can neither remove a user-owned provider nor overwrite the selected default model.

Before implementation, add a checked-in DSH 0.1.0-rc.6 settings fixture and tests proving: DSH_HOME wins over ~/.dsh; enable writes only the owned nested provider; catalog refresh preserves unrelated settings and the default model; user edits inside the owned fragment refuse refresh/disable; disable and restore are reversible; and no generated file serializes an API key. The existing exporters treat secret serialization as a release-blocking invariant (src/clients/config-export.ts:425), and remote-bind support must be refused unless DSH has a documented way to send OpenCodex's dedicated admission header.

This should land with focused schema/round-trip and writer-state tests plus a DSH compatibility E2E, and docs for the dashboard/CLI workflow.

DISPOSITION: ACCEPTED

[Wibias]

Fixed by #1665