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

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.