dsh-cc

English | 简体中文

Claude Code-style workflows. Your models. DeepSeek Harness.

dsh-cc turns DeepSeek Harness into a batteries-included coding environment for everyday development. Keep familiar project assets and interaction patterns while choosing the models, tools, permissions, and agent composition that fit your environment.

• Reuse familiar workflows: .claude/agents, SKILL.md, CLAUDE.md, hooks, permissions, slash commands, and resumable sessions.
• Bring your own model strategy: route aliases such as sketch, draft, blueprint, and masterplan to any provider/model pair supported by your dsh deployment.
• Run a complete coding loop: TUI, MCP, memory, subagents, background tasks, worktrees, structured output, deferred tool discovery, reversible tool-output compression (context-crusher + context_retrieve), and cost-gated compaction.
• Stay composable: install the experience through native dsh profiles and plugins instead of maintaining a permanent DeepSeek Harness fork.

dsh-cc is not Claude Code and is not a wrapper around Claude Code. It implements familiar Claude Code-style workflows on the open, composable DeepSeek Harness runtime.

Quick start

Install DeepSeek Harness and the dsh-cc launcher, then start coding:

npm install -g @deepseek-ai/dsh @dsh-cc/cli
dsh-cc

dsh-cc requires dsh >= 0.2.0-rc.2; the default npm install -g @deepseek-ai/dsh currently satisfies this (as of 2026-09-29), and the launcher enforces the floor at bootstrap. This floor tracks the development line; per-release pairings are listed in the table below.

Already have dsh >= 0.2.0-rc.2? Install only the launcher:

npm install -g @dsh-cc/cli
dsh-cc

Upgrading

npm install -g @dsh-cc/cli@latest
dsh-cc

On the first launch after an upgrade, the launcher re-runs the profile’s bundle install at the new version (recorded in ~/.dsh/profiles/tui/.dsh-cc-bootstrap.json), so the profile converges automatically, with no manual step. A failed reconcile (e.g. network, or the fresh release still inside npm/pnpm’s minimum-release-age window) warns and boots anyway, retrying on the next launch. Dev-synced profiles (via scripts/sync-local-profile.sh) are never reconciled by the launcher; they follow the dev-restore flow instead.

The launcher creates and boots the CC-oriented tui profile. To compose the profile explicitly instead:

dsh plugin --profile tui add \
  @dsh-cc/bundle-permissions \
  @dsh-cc/bundle-shell \
  @dsh-cc/bundle-tui
dsh --profile tui

The same backend also works with the dsh web UI:

dsh plugin --profile web add \
  @dsh-cc/bundle-permissions \
  @dsh-cc/bundle-shell
dsh web

dsh version compatibility

Each dsh-cc release is developed and CI-verified against one DeepSeek Harness (dsh) version. The launcher enforces that same version as the minimum dsh at bootstrap and refuses to start when dsh is older, with an upgrade hint.

There is no enforced upper bound, but only the listed pairing is CI-verified; running dsh-cc against a dsh newer than its verified version is untested territory. When a new dsh-cc release moves to a newer dsh version, upgrade dsh first, then dsh-cc.

The two packages ship on independent schedules, so @latest on one side is not necessarily the verified partner of @latest on the other; check this table after upgrading either package.

Maintainers: the verified pin lives in .github/workflows/presubmit.yml (DSH_HARNESS_REF) and the launcher floor in packages/launcher/tui/bootstrap.mjs (MIN_DSH_VERSION); update this table when either changes.

Optional: official plugins

The bundles above are the whole quick start. Four optional official plugins, shipped through the repo’s dsh-cc marketplace, add preconfigured subagent lanes and external model bridges:

• dsh-cc-agents: the dsh-cc-agents:critic (reasoning and plan review, opus alias), dsh-cc-agents:executor (mechanical execution, sonnet alias), and dsh-cc-agents:marathon (long-horizon or repo-wide complexity, fable alias) subagents, plus two routing skills (dsh-cc-agents-orchestration for picking an agent, data-analysis for analysis tasks) and optional serena code-intelligence hooks (gated on serena-onboarded repos).
• dsh-cc-shunt: PreToolUse gates that redirect bulk file reads and boilerplate generation to cheap-lane worker subagents, keeping large file corpora out of the main context (configure a haiku alias for real token savings).
• cc-codex-bridge: an approval-free Codex rescue lane. A PreToolUse hook auto-allows exactly one canonical, locked-down Codex invocation per session run, so a stuck session can hand a task to Codex without a permission checkpoint.
• cc-grok-bridge: the same pattern for a Grok review lane; one canonical invocation is auto-allowed so external Grok review passes need no per-run approval.

Install them inside a session:

/plugin marketplace add dsh-cc/dsh-cc
/plugin install dsh-cc-agents@dsh-cc
/plugin install dsh-cc-shunt@dsh-cc

/plugin install flips the enabledPlugins flag for you; restart the session so the new agents and hooks are picked up. To update later, re-pull the marketplace and then update the plugin: /plugin marketplace update dsh-cc, then /plugin update . Each plugin’s own README (agents, shunt, cc-codex-bridge, cc-grok-bridge) covers configuration and known limits.

Why developers use dsh-cc

dsh-cc is developed with dsh-cc itself. The repository’s current setup routes work across Kimi, GLM, and DeepSeek models, plus a System One decision lane for the typed-approval gauge alias; see Dogfooding dsh-cc for the concrete mapping.

Who is this for?

• Developers who want to use DeepSeek Harness directly as an everyday coding agent;
• Teams that already have .claude/ project assets and want to keep reusing agents, skills, hooks, and project memory;
• Users who want to pick Kimi, GLM, DeepSeek, or other models per task instead of being tied to a single vendor;
• Plugin authors who want to compose or extend an agent’s permissions, tools, memory, subagents, and UI rather than maintain a product fork.

Compatibility at a glance

Statuses were verified against upstream documentation retrieved as of 2026-09-23 (freshness threshold: 120 days).

For the exact feature-by-feature status and known gaps, see the Claude Code parity matrix.

Familiar coding-agent workflows

Subagents

Project-local Claude Code-style agent definitions under .claude/agents can be discovered and dispatched by the CC preset.

.claude/
  agents/
    reviewer.md
    debugger.md

Agent frontmatter can continue using familiar model aliases while dsh decides which provider/model actually serves the request.

Skills

SKILL.md-based skills are discovered by the CC skill provider, including project-specific skills and bundled utility skills.

Memory

The memory layer supports CLAUDE.md-style context plus a dedicated write channel for durable memories. Memory is isolated by workspace, with optional shared team memory, and background dream consolidation kicks in automatically when memory-index pressure builds up.

MCP

The CC profile includes an MCP client with:

• tools;
• resources;
• prompts;
• OAuth 2.1 flows.

Use /mcp to inspect and manage MCP connections.

Optional: Serena code intelligence

When your MCP configuration connects a Serena server, dsh-cc automatically takes advantage of it: the system prompt steers toward Serena’s symbol tools for code questions, and the bundled explore subagent gains read-only symbol retrieval (find_symbol, find_referencing_symbols, get_symbols_overview). Serena is strictly optional; without it, sessions behave identically through the built-in Read/Grep tools, minus the steering hints.

Install Serena once so a local serena binary is on PATH:

uv tool install git+https://github.com/oraios/[email protected]

Then add it to ~/.dsh/.mcp.json (or a project .mcp.json) using the local binary:

{
  "mcpServers": {
    "serena": {
      "command": "serena",
      "args": ["start-mcp-server", "--context", "claude-code", "--project-from-cwd"]
    }
  }
}

Avoid launching it via uvx --from git+…: every server start would write ~/.cache/uv, which the session sandbox denies.

/doctor reports the connection under the mcp.serena check.

Hooks

Claude Code-style hooks can react to session, prompt, tool, permission, compaction, task, and subagent lifecycle events. Command and HTTP executors are supported, with additional prompt/agent executors available behind configuration gates.

This repository ships a tracked hooks.json (the CC preset loads it from the launch cwd) carrying the repo-development hooks. The serena code-intelligence hooks ship with the official dsh-cc-agents plugin (gated; they fire here because this repo is serena-onboarded) and require serena-hooks on PATH; see Local development.

See the parity matrix for the currently bridged event set.

Slash commands

The CC preset exposes a growing command surface, including:

/agents            manage continuable background agents
/auto-mode         inspect the auto permission mode (defaults, config, decision review)
/branch            worktree branch management
/commit-split      propose an atomic-commit split of the working tree (dry-run)
/compact           compact the session context
/config            inspect or change settings
/cost              token / cost information
/diff              inspect CLAUDE.md / settings differences
/doctor            session health report (--verbose / --json)
/export            write the session transcript to a file
/help              list commands or show one command's help
/init              scan a project and scaffold CLAUDE.md
/learn             distill recurring corrections into workspace memory
/mcp               manage MCP connections
/memory            inspect memories
/onboard           re-run the first-run setup (clears the onboarding opt-out)
/permissions       inspect or change permission mode/rules
/plugin            manage plugins
/provider          manage LLM providers (list/add/remove, rotate keys, set default)
/release-notes     show release notes
/rename            pin an explicit title on the current session
/resume            resume an interrupted session
/skills            list installed skills
/stats             session event-log stats (turns, tools, tokens)
/status            environment and session status
/tasks             inspect current tasks/jobs
/version           show version information

The TUI also provides terminal-oriented interactions such as todo inspection, approval flows, queued prompts, transcript export, usage/context display, and local shell commands.

/provider opens an overlay over your configured model providers: /provider list prints the current routes, /provider add walks a wizard for the built-in presets (Moonshot, Z.AI/Zhipu, DeepSeek) or a fully custom endpoint, and the per-route detail view rotates keys, refreshes the model list, sets the default, or removes the route. API keys are typed into a masked field and stored in the credential store (~/.dsh/.credentials.yaml), never in settings; keys already supplied by the environment are shown read-only. Changes take effect for new sessions immediately (credentials resolve per request); the running session keeps its current provider until you pick again with /model.

First-run onboarding

On a fresh install with no model configured, the boot seed settles with no default route and the TUI opens the provider panel automatically: pick a preset, paste your API key (stored only in the credential store), set the default model, and you are ready to go. Dismissing the panel with Esc only skips it for the current session; the flow is re-offered on the next boot. To opt out permanently, set cc-onboarding.suppressed: true under the user settings namespace in ~/.dsh/settings.json, and re-arm any time with /onboard. Non-interactive (non-TTY) runs never trigger the flow and keep the plain “No model configured” notice.

Use the models you want

Claude Code-style agent definitions often refer to models using aliases:

model: sonnet

dsh-cc can route those aliases to provider/model pairs configured for your deployment.

Conceptually:

sonnet / draft      -> /
opus / blueprint    -> /
haiku / sketch      -> /
fable / masterplan  -> /
architect           -> parent agent route (planning / orchestration)
gauge               -> typed-decision cheap lane (System One models; not generative)
inherit             -> parent agent route

Aliases are configuration, not hard-coded vendor bindings. This lets you preserve familiar agent definitions while choosing the models that fit your own environment.

Dogfooding dsh-cc

dsh-cc is now developed with dsh-cc itself. The project’s current development setup uses the same model-alias routing described above, with this mapping:

This is a real project configuration rather than a required default: users can map the aliases to any provider/model combination supported by their DeepSeek Harness deployment.

How this is different

vs. Claude Code

Claude Code is a complete coding-agent product. dsh-cc instead brings many familiar interaction patterns to the DeepSeek Harness runtime, where the deployment controls models, tools, plugins, permissions, and agent composition.

vs. a DeepSeek Harness fork

This repository is designed primarily as an out-of-repo plugin stack. Most functionality is installed and composed through dsh profiles, reducing the amount of permanent fork maintenance required as upstream evolves.

A small number of upstream packages are vendored where the required extension point cannot currently be expressed as a wrapper. See Architecture notes below.

vs. model/API routers

A model-routing proxy only switches models. dsh-cc extends the agent runtime and developer experience itself: UI, commands, tools, memory, subagents, hooks, MCP, permissions, sessions, and worktree workflows.

CC Mode

CC Mode is an additional dsh agent preset. The four built-in dsh modes remain behaviorally unchanged.

On the tui profile, CC Mode is the default. On other profiles it can be selected through the preset selector or configured as the default agent preset.

The terminal profile launches in fullscreen mode by default. To opt out for one invocation:

DSH_CCTUI_UI_MODE=regular dsh --profile tui

Configuration

Your profile remains ordinary dsh composition. Local tweaks can be placed in:

~/.dsh/profiles/tui/cordis.patch.yml

They are applied after the installed bundles.

Model alias configuration, permissions, settings precedence, hook behavior, memory options, and TUI behavior are exposed through the corresponding plugins/settings namespaces.

For exact semantics, use the package READMEs and the parity matrix as the source of truth.

Custom status line

On the tui profile, you can replace the built-in bottom status line with your own shell command (Claude Code-compatible). The block can live in the user file ~/.dsh/settings.json or in a project .claude/settings.json:

{
  "statusLine": {
    "type": "command",
    "command": "~/.dsh/statusline.sh",
    "padding": 0,
    "refreshInterval": 10
  }
}

Project .claude/settings.json files shared with a Claude Code checkout work as-is; if both a camelCase statusLine and a dsh-native kebab statusline key are present, the dsh-native key wins.

The command receives a Claude Code-compatible JSON session payload on stdin (the CC statusline docs describe the contract); dsh-cc supplies only the fields it can source truthfully. Its stdout’s first lines (up to 3) become the status line (ANSI escapes are passed through); a failure or empty output renders a blank line. The command reruns on session boot/resume, new messages, mode and model changes, plus on the refreshInterval timer, which is in seconds (minimum 1). Scripts get COLUMNS/LINES in their environment.

Current limits: only the first 3 output rows are rendered (CC renders every row). Settings files are hot-reloaded, so settings.json edits made outside the running session apply without a restart; when the command itself changes, the status line re-runs it immediately.

Compatibility and known limits

The goal is useful Claude Code-style workflow compatibility, not byte-for-byte emulation of Claude Code.

Some areas are intentionally partial or depend on DeepSeek Harness extension points. Examples include parts of the hook event vocabulary, background subagent workflows, notification/IDE-shell behavior, and vendor-specific features.

The project tracks those differences explicitly instead of hiding them:

Read the full Claude Code parity matrix →

Architecture

The repository is a monorepo of small plugins and bundles grouped by responsibility:

packages/
  settings/       settings cascade, migrations, namespaces
  interaction/    slash commands, permission rules, interaction plugins
  mcp/            MCP client and configuration
  hooks/          hook protocol and CC bridge
  core/           tool registry, ToolSearch, NotebookEdit, StructuredOutput, Sleep, workflow, web-fetch
  skill/          SKILL.md support
  preset/         CC agent preset and agent compatibility
  compat/         plugin loader and manager, model aliases, output styles
  memory/         CLAUDE.md memory and dream consolidation
  workspace/      worktree tool and session-cwd guard
  subagent/       coordinator, task tool, handoff store, resume pins
  compaction/     compaction tiers, cost gate, tool-use summaries
  session/        session commands (cost, export, stats, learn) and forensics
  context/        reversible tool-output compression (context-crusher) and post-compact progress rebuild
  llm-tuning/     reasoning-fold and side-query
  observability/  cache-health observer, config snapshot sidecar, shared sidecar IO
  plugin/         first-party plugins of the in-repo marketplace
  test-support/   shared test fixtures and eval harnesses (not published)
  bundle/         installable profile bundles
  ui/             terminal UI and the vendored pi-tui renderer
  launcher/       the dsh-cc executable

Most packages are normal out-of-repo dsh plugins.

A few packages vendor upstream code when the required changes need private or internal extension points rather than composition. These currently include the tools registry, MCP client, hook protocol, and Claude Code hook bridge (mounted at runtime under distinct package names while preserving the expected service interfaces), plus the pi-tui terminal renderer under ui/, whose purity is enforced by check:vendor-purity.

Local development

This repository expects a sibling DeepSeek Harness checkout at ../deepseek-harness for local link: development dependencies.

pnpm install --frozen-lockfile
pnpm run typecheck
pnpm test

Serena (serena-hooks on PATH)

The serena code-intelligence hooks (a PreToolUse remind nudge after a burst of raw reads/greps, plus SessionEnd cleanup of the per-session hook state) ship with the official dsh-cc-agents plugin (see its README’s Serena hooks section for the gating contract). They fire in this repo because it is serena-onboarded (.serena/project.yml is tracked) once the plugin is enabled and the binary is on PATH:

uv tool install git+https://github.com/oraios/[email protected]

That pin provides serena, serena-agent, and serena-hooks. The plugin’s gate wrappers pin hook state into the project (SERENA_HOME=/.serena): serena’s default state dir (~/.serena/hook_data) is outside the session sandbox’s writable surface, and serena swallows the failure; without the pin the remind counter never persists and the hooks silently no-op. State lands in .serena/hook_data/ (gitignored), per session id, and is removed when the session is disposed.

The repo’s own tracked hooks.json keeps only repo-development hooks that reference scripts/hooks/ (post-edit diagnostics nudge, serena failure watchdog).

Health-check and index remain one-shot uvx commands; see docs/code-intelligence-health.md.

To test unpublished packages against a real profile:

pnpm run build
bash scripts/sync-local-profile.sh web
dsh web

After a dev sync, dsh-cc --version shows a -dev+[.dirty] label identifying the source tree; updating the launcher via npm automatically returns the profile to the store bundles.

To prove the production bundle set actually boots in a user-grade environment (fresh DSH_HOME, harness-healed fallback, pseudo-TTY, no LLM calls), run the same gate presubmit and publish use:

pnpm smoke:profile-boot

The CC preset needs no separate install step: the tui profile’s bundle patch declares the cc agent-preset registry roster directly, and the composition is carried by @dsh-cc/preset-cc (installed with the bundles into the profile’s node_modules).

See docs/dev.md for offline development details and repository-specific dependency rules.

Packages and releases

Published plugins use the @dsh-cc npm scope. The root monorepo package is private; installable packages are released individually through the repository release tooling.

Release process details: docs/release.md.

Project status

dsh-cc is evolving alongside DeepSeek Harness. The compatibility surface can change as upstream adds new extension points or changes existing ones.

If you find a workflow that works differently from Claude Code, the parity matrix is the best place to check whether it is implemented, partial, intentionally out of scope, or still missing.

Contributions, compatibility reports, and focused upstream extension proposals are welcome. Useful ways to help include:

• compatibility reports with reproduction steps and /doctor --json output;
• focused fixes and tests for one capability;
• upstream extension proposals that reduce vendored code;
• real-project model-routing and workflow examples.

Open an issue · View pull requests

License

Apache-2.0