DSH | oh-my-dsh | A curated distribution built for governed self-evolution

[mingyooagi]

Unofficial community project. oh-my-dsh is independently developed and maintained. It is not affiliated with or endorsed by DeepSeek, and it has not been reviewed by the DeepSeek team. Please inspect the source and evaluate the risks before installing or activating third-party capabilities.

Project: github.com/amplifthq/oh-my-dsh

License: MIT

Upstream: deepseek-ai/deepseek-harness

What is oh-my-dsh?

DeepSeek Harness provides a strong plugin architecture and a deliberately conservative reference composition. oh-my-dsh, or OMD, is an opinionated distribution built on that architecture.

It is not a fork and does not ship modified upstream source. OMD is a formal Cordis bundle composed on top of the upstream Web or headless runtime, followed by profile and user overrides:

@deepseek-ai/dsh-base
→ @deepseek-ai/dsh-web-app or @deepseek-ai/dsh-headless
→ oh-my-dsh
→ profile/cordis.patch.yml
→ $DSH_HOME/cordis.patch.yml

The user's patch is applied last. Every OMD default can therefore be replaced or removed without maintaining a divergent Harness fork.

The project started from a simple question: what would a distribution layer for an agent harness look like?

The analogy I use is the “Debian moment.” A strong core is necessary, but a usable distribution also needs packaging, tested combinations, defaults, trust boundaries, updates, rollback, and a stable place for user-owned extensions.

For an agent harness, I think there is one additional requirement: the distribution should be able to learn from real work without allowing the agent to authorize its own expansion.

Built for governed self-evolution

OMD treats self-evolution as a governed harness loop, not as model retraining or autonomous self-modification:

discover a capability gap
        ↓
distill a skill or forge a plugin
        ↓
inspect and approve the exact proposal
        ↓
observe real use and attribute outcomes
        ↓
evaluate a frozen harness snapshot
        ↓
compare regression and ablation evidence
        ↓
optimize the next proposed action
        ↓
retain, revise, unload, or promote

The pieces of this loop are implemented as DSH plugins:

• Capability discovery searches tools, skills, slash commands, inert or active MCP servers, curated session plugins, and agent-forged plugins without activating them. Zero-result searches become durable capability-gap evidence.
• Skill Forge turns a procedure that was actually executed and verified into a proposed SKILL.md. The exact content and destination are reviewed before any write.
• Plugin Forge lets the agent author a small DSH plugin for a missing capability. The complete source, digest, imports, declared effects, and secret warnings are carried by an approval-gated proposal.
• Eval scores an explicit frozen harness snapshot with machine assertions. Diff comparison checks for regression; ablation comparison tests whether one skill or plugin accounts for the claimed improvement.
• Optimizer selects from a locked set of next proposals—promote, forge, unload, save a skill, or do nothing—using stored evaluation evidence.

The optimizer cannot apply a proposal, invent plugin source, write a skill body, or modify the curated catalog. A successful eval does not grant more authority.

Self-evolution is not self-authorization. The agent can discover, create, measure, and propose. The user approves activation or persistence. Promotion into the shared distribution remains a reviewed pull request.

How it integrates with DSH

OMD stays on DSH's public composition and plugin surfaces. Its main integrations include:

One proposal plane

Sensitive changes use one lifecycle:

prepare → inspect → approve → commit → verify

This covers MCP activation, plugin loading, semantic refactoring, debugging, skill persistence, and forged-plugin creation. A session proposal cannot authorize itself.

Lazy MCP activation

OMD discovers compatible MCP definitions from existing Claude, Cursor, and Codex configuration without starting processes, expanding credentials, or injecting tool schemas.

The agent may prepare an activation proposal. The user can inspect the command or endpoint, working directory, configuration source, redacted arguments, and consequences before approving it for that session.

Recoverable semantic rename

Bundled language servers provide navigation for TypeScript/JavaScript, Python, JSON, HTML, CSS-family languages, and YAML. Host-installed rust-analyzer, gopls, clangd, and sourcekit-lsp are discovered when available.

For semantic rename, OMD validates workspace containment and observed file versions, displays the exact multi-file edit, applies it after approval, requests diagnostics, and attempts rollback if publication fails partway through.

Hardened Web fetch

Web fetch is enabled through an OMD provider that rejects private, loopback, link-local, and cloud-metadata destinations before the request and validates DNS results again when connecting.

This is intended to make Web access useful by default without turning the fetch tool into an SSRF path. Users can explicitly disable fetch or opt into private-network access for trusted environments.

Existing agent configuration, reused in place

OMD can discover compatible instructions, skills, commands, hooks, and MCP definitions from Claude, Codex, Cursor, Gemini, and Copilot locations.

Project-owned integrations remain disabled until the Git root is explicitly trusted. Trust makes definitions discoverable; capability activation is still a separate approval.

Distribution and installation

OMD currently offers two channels:

• A portable distribution for macOS arm64 and Linux x64 with glibc, including its own Node.js runtime and production dependency closure
• An npm package for developers, custom profiles, and downstream composition

Portable installation:

curl -fsSL https://github.com/amplifthq/oh-my-dsh/releases/latest/download/install.sh | sh
omd setup
omd

Please inspect the installer and release artifacts before running third-party software.

npm installation:

npm install --global oh-my-dsh
omd setup
omd

Portable installs support verified foreground updates, rollback, and file-integrity checking:

omd update
omd rollback
omd doctor --verify

User state—including sessions, skills, trust decisions, MCP definitions, configuration patches, and forged plugins—lives outside the immutable distribution and survives update or rollback.

Current boundaries

DeepSeek Harness is still in developer preview. OMD pins a tested upstream release rather than silently following every prerelease, and a canary workflow checks the overlay against upcoming DSH versions.

Some boundaries are intentional:

• Native Windows portable releases are not currently provided; WSL2 is the supported shape for Windows users.
• Persistent code kernels run as the host user and are not sandboxes.
• Approved in-process plugins have the privileges of the Harness process.
• Plugin Forge's static restrictions improve reviewability but do not sandbox runtime behavior.
• External curated integrations are described as external; they are not presented as built in.
• OMD does not estimate monetary cost when the upstream provider abstraction does not expose reliable provider-neutral pricing.

Why an overlay, not a fork?

A fork would make it easier to change upstream internals, but it would also create a permanent merge, security, and reviewability burden.

OMD instead adds curated defaults, host-side guards, and missing capabilities through DSH plugins. It deliberately avoids rebuilding the upstream session engine, provider routing, planning loop, TUI, or peer messaging.

When a capability belongs upstream, the preferred path is to propose or extend the upstream seam and delete the private compatibility layer when that seam becomes available.

Feedback I would value

I would especially appreciate feedback from DSH maintainers and plugin authors on:

1. Whether this distribution boundary is using the intended Cordis and DSH seams
2. Which OMD capabilities should eventually move upstream rather than remain distribution-owned
3. Whether the shared proposal lifecycle is a useful direction for third-party capability activation
4. How to improve diff and ablation evaluation for harness-level changes
5. What evidence should be required before a session-forged plugin is considered for community promotion

The goal is not to replace the upstream reference setup. It is to explore what a user-controlled distribution layer can look like while staying close to DSH architecture.

Distribution-native. Self-evolution-native. Human-governed.

Overlay, not a fork.

Project URL: https://github.com/amplifthq/oh-my-dsh