How to Integrate Codex and Claude Code into DeepSeek Harness on Windows

If you are trying to add Codex and Claude Code as subagents in DeepSeek Harness, the package names are now available from npm, but installing the packages alone is not enough. The main difficulty is keeping the DeepSeek Harness core packages, subagent packages, and session packages on compatible versions.

This article documents the actual installation path and the errors encountered while integrating @deepseek-ai/dsh-subagent-codex and @deepseek-ai/dsh-subagent-claude-code into a DeepSeek Harness web profile on Windows.

The key problem is version compatibility. In the example below, DeepSeek Harness itself is installed globally at 0.1.0-rc.8, while the manually installed Codex and Claude Code packages are 0.0.1-rc.1. That mismatch eventually causes the findLastMessageTurnEnd module error.

What Is the Correct Way to Add Codex and Claude Code to DeepSeek Harness?

The intended configuration is to add both subagent packages to the web profile and then start the profile with dsh web.

The profile configuration used in this setup is

{
  "name": "dsh-profile-web",
  "private": true,
  "dependencies": {
    "@deepseek-ai/dsh-subagent-claude-code": "^0.0.1-rc.1",
    "@deepseek-ai/dsh-subagent-codex": "^0.0.1-rc.1"
  },
  "dsh": {
    "profile": {
      "bundles": [
        "@deepseek-ai/dsh-base",
        "@deepseek-ai/dsh-web-app",
        "@deepseek-ai/dsh-subagent-codex",
        "@deepseek-ai/dsh-subagent-claude-code"
      ]
    }
  }
}

This configuration tells DeepSeek Harness to load four bundles

@deepseek-ai/dsh-base
@deepseek-ai/dsh-web-app
@deepseek-ai/dsh-subagent-codex
@deepseek-ai/dsh-subagent-claude-code

The important detail is that the Codex and Claude Code packages are profile bundles. They are not ordinary npm packages that can simply be installed globally and automatically become available to every DSH profile.

Are the Codex and Claude Code Packages Actually Published on npm?

Yes.

The initial assumption that these packages might be internal or unpublished turns out to be incorrect based on the npm metadata retrieved during the installation.

Running

npm view @deepseek-ai/dsh-subagent-codex

returns

@deepseek-ai/dsh-subagent-codex@0.0.1-rc.1
One-shot Codex subagent provider over the official app-server protocol

The package currently exposes the latest tag at

0.0.1-rc.1

and the next tag at

0.1.0-rc.8

The package depends on

@deepseek-ai/schemastery

The Claude Code package can be inspected with

npm view @deepseek-ai/dsh-subagent-claude-code

Its npm metadata reports

@deepseek-ai/dsh-subagent-claude-code@0.0.1-rc.1
One-shot Claude Code subagent provider over the official Agent SDK

It has the same two relevant release channels

latest: 0.0.1-rc.1
next: 0.1.0-rc.8

and depends on

@anthropic-ai/claude-agent-sdk
@anthropic-ai/sdk
@deepseek-ai/schemastery

This immediately gives us an important clue.

The package versions available under latest and next are different.

Why Did npm Install Fail with `Cannot Read Properties of Null`?

The first installation attempt was

npm install -g @deepseek-ai/dsh-subagent-codex

and npm returned

npm error Cannot read properties of null (reading 'children')

The same error appeared when the command was executed again.

At first glance this looks like a package availability problem. It is not.

A useful test was to install an unrelated package

npm install -g lodash

which completed successfully

added 1 package in 2s

This demonstrates that npm itself was capable of installing packages.

The Codex package was then installed locally inside the DSH profile directory

C:\Users\reanod\.dsh\profiles\web>npm install @deepseek-ai/dsh-subagent-codex

and npm successfully reported

added 22 packages in 9s

This gives us a much more useful diagnosis.

The original problem was related to how the package was being installed globally, while the DSH profile expects profile-specific packages to exist inside the profile dependency tree.

Why Did `dsh web` Then Fail?

After adding the Codex package to the profile, running

dsh web

produced this error

Error: dsh: profile bundle "@deepseek-ai/dsh-subagent-codex" declares no dsh.bundle in its package.json

This error is particularly useful because it tells us how DeepSeek Harness loads profile bundles.

The package is not treated as an ordinary dependency.

When the profile configuration contains

"bundles": [
  "@deepseek-ai/dsh-subagent-codex"
]

DeepSeek Harness expects that package to declare a dsh.bundle entry in its own package.json.

The error therefore means the installed package version is not compatible with the bundle-loading mechanism expected by the installed DSH version.

At this point, simply adding the package to dependencies is insufficient.

The Important Version Difference Between DSH and the Subagent Packages

The global DeepSeek Harness installation is

npm list -g @deepseek-ai/dsh

which reports

@deepseek-ai/dsh@0.1.0-rc.8

The installed DSH package also contains

@deepseek-ai/dsh-session@0.1.0-rc.8

and

@deepseek-ai/dsh-subagent@0.1.0-rc.8

This is the version family used by the current DSH installation.

However, the manually installed Codex package was

@deepseek-ai/dsh-subagent-codex@0.0.1-rc.1

and the Claude Code package queried from npm also reports

@deepseek-ai/dsh-subagent-claude-code@0.0.1-rc.1

The package metadata also exposes

next: 0.1.0-rc.8

That is the version that matches the installed DSH release family.

This distinction is the most important finding in the entire installation process.

Why Does `findLastMessageTurnEnd` Cause the Startup Failure?

After configuring both packages, running

dsh web

produced the following error

The requested module '@deepseek-ai/dsh-session'
does not provide an export named 'findLastMessageTurnEnd'

The failing source code is

import {
  Session,
  SessionId,
  findLastMessageTurnEnd,
  snapshotJsonValue
} from "@deepseek-ai/dsh-session";

The error occurs while loading

@deepseek-ai/dsh-subagent

The important part of the stack trace is

C:\Users\reanod\.dsh\profiles\web\node_modules\@deepseek-ai\dsh-subagent\lib\index.js

followed by

import {
  Session,
  SessionId,
  findLastMessageTurnEnd,
  snapshotJsonValue
}
from "@deepseek-ai/dsh-session";

Node.js then reports

SyntaxError: The requested module '@deepseek-ai/dsh-session'
does not provide an export named 'findLastMessageTurnEnd'

This is a classic package API mismatch.

The @deepseek-ai/dsh-subagent code expects @deepseek-ai/dsh-session to expose

findLastMessageTurnEnd

but the version of @deepseek-ai/dsh-session that Node.js actually resolves does not provide that export.

The problem is therefore no longer npm installation.

The problem is dependency version alignment.

Why `npm list` in the User Directory Shows Nothing

Several commands were run from

C:\Users\reanod

including

npm list @deepseek-ai/dsh-subagent
npm list @deepseek-ai/dsh-session
npm list @deepseek-ai/dsh

and they returned

`-- (empty)

That result is expected.

The packages were installed globally, not in

C:\Users\reanod\node_modules

The actual global npm installation can be confirmed with

npm list -g @deepseek-ai/dsh

which reports

C:\nvm4w\nodejs
`-- @deepseek-ai/dsh@0.1.0-rc.8

The global npm root is

npm root -g

and returns

C:\nvm4w\nodejs\node_modules

The global npm prefix is

npm prefix -g

which returns

C:\nvm4w\nodejs

So the package locations are separated into two environments.

The global DSH installation lives under

C:\nvm4w\nodejs\node_modules

while the profile dependencies live under

C:\Users\reanod\.dsh\profiles\web\node_modules

This distinction matters because Node.js module resolution does not simply merge these two dependency trees.

How Does `dsh` Find the Installed DeepSeek Harness?

The command

where dsh

returns

C:\nvm4w\nodejs\dsh
C:\nvm4w\nodejs\dsh.cmd

The Windows launcher can be inspected with

type C:\nvm4w\nodejs\dsh.cmd

The important part is

"%_prog%" "%dp0%\node_modules\@deepseek-ai\dsh\lib\bin.js" %*

This means the dsh command directly launches

C:\nvm4w\nodejs\node_modules\@deepseek-ai\dsh\lib\bin.js

The command therefore points to the global DSH installation.

This is also why the global package version can be checked with

npm list -g @deepseek-ai/dsh

and why the result is

@deepseek-ai/dsh@0.1.0-rc.8

Why Does `require.resolve()` Fail?

The following command was tested

node -p "require.resolve('@deepseek-ai/dsh/package.json')"

and Node.js returned

Error: Cannot find module '@deepseek-ai/dsh/package.json'

This does not contradict the fact that DSH is installed globally.

The command was executed from

C:\Users\reanod

while the package is installed under

C:\nvm4w\nodejs\node_modules

Node.js does not automatically use the global npm package directory for ordinary module resolution from the current working directory.

The more direct way to locate the package is therefore

npm root -g

followed by inspection of

C:\nvm4w\nodejs\node_modules\@deepseek-ai\dsh

Node.js Version Used in This Installation

The current environment reports

node -v

v25.0.0

and

npm -v

11.6.2

The executable locations are

where node

C:\nvm4w\nodejs\node.exe

and

where npm

C:\nvm4w\nodejs\npm
C:\nvm4w\nodejs\npm.cmd

These details are useful when reproducing the problem because the same commands can behave differently when multiple Node.js installations exist on Windows.

In this environment, node, npm, and dsh all resolve through

C:\nvm4w\nodejs

so the PATH configuration is internally consistent.

The Correct Version Strategy for Codex and Claude Code

The npm metadata provides a straightforward direction.

The manually installed packages use the latest release

0.0.1-rc.1

while the package metadata also exposes

0.1.0-rc.8

through the next tag.

The installed DSH core is already

0.1.0-rc.8

Therefore the dependency family should be kept on the same release line.

The target configuration should use

0.1.0-rc.8

for the DSH subagent packages instead of mixing

0.0.1-rc.1

with

0.1.0-rc.8

The practical target is therefore

@deepseek-ai/dsh
0.1.0-rc.8

@deepseek-ai/dsh-session
0.1.0-rc.8

@deepseek-ai/dsh-subagent
0.1.0-rc.8

@deepseek-ai/dsh-subagent-codex
0.1.0-rc.8

@deepseek-ai/dsh-subagent-claude-code
0.1.0-rc.8

This alignment is especially important because the startup failure occurs inside the shared dsh-session and dsh-subagent layers.

A Clean Profile Configuration

Once the packages are aligned, the profile should keep the dependency declarations explicit.

A suitable configuration structure is

{
  "name": "dsh-profile-web",
  "private": true,
  "dependencies": {
    "@deepseek-ai/dsh-subagent-codex": "0.1.0-rc.8",
    "@deepseek-ai/dsh-subagent-claude-code": "0.1.0-rc.8"
  },
  "dsh": {
    "profile": {
      "bundles": [
        "@deepseek-ai/dsh-base",
        "@deepseek-ai/dsh-web-app",
        "@deepseek-ai/dsh-subagent-codex",
        "@deepseek-ai/dsh-subagent-claude-code"
      ]
    }
  }
}

Using an exact version during troubleshooting is preferable to

"^0.0.1-rc.1"

because the caret range allows npm to resolve versions within the specified major and minor compatibility range, while the problem here is specifically about keeping the DSH package family synchronized.

What the Dependency Tree Should Look Like

The global installation already demonstrates the expected DSH dependency structure.

Running

npm list -g @deepseek-ai/dsh-session

shows that many DSH components depend on

@deepseek-ai/dsh-session@0.1.0-rc.8

For example

@deepseek-ai/dsh-agent@0.1.0-rc.8
└── @deepseek-ai/dsh-session@0.1.0-rc.8

and

@deepseek-ai/dsh-subagent@0.1.0-rc.8
└── @deepseek-ai/dsh-session@0.1.0-rc.8

The important relationship is

dsh
│
├── dsh-session
│
├── dsh-subagent
│
├── dsh-subagent-fork-in-process
│
├── dsh-web-app
│
└── other DSH components

The Codex and Claude Code providers sit above this shared subagent infrastructure.

Conceptually, the architecture becomes

DeepSeek Harness
│
├── Web App
│
├── Core Agent
│
├── Session
│
├── Subagent Runtime
│
├── Codex Subagent Provider
│   └── Codex app-server protocol
│
└── Claude Code Subagent Provider
    └── Claude Agent SDK

This explains why a mismatch in dsh-session can prevent both the web application and subagent system from starting.

A Practical Troubleshooting Sequence

When DSH fails to start after adding Codex or Claude Code, check the environment in this order.

1. Check Node.js

node -v

2. Check npm

npm -v

3. Check the executable paths

where node
where npm
where dsh

4. Check the global DSH version

npm list -g @deepseek-ai/dsh

The environment discussed here reports

@deepseek-ai/dsh@0.1.0-rc.8

5. Check the global session package

npm list -g @deepseek-ai/dsh-session

The expected version in this environment is

0.1.0-rc.8

6. Check the global subagent package

npm list -g @deepseek-ai/dsh-subagent

The installed DSH tree contains

@deepseek-ai/dsh-subagent@0.1.0-rc.8

7. Check the profile dependencies

Move to

cd C:\Users\reanod\.dsh\profiles\web

then run

npm list @deepseek-ai/dsh-subagent-codex
npm list @deepseek-ai/dsh-subagent-claude-code
npm list @deepseek-ai/dsh-session
npm list @deepseek-ai/dsh-subagent

The goal is to identify whether the profile has introduced a second, incompatible DSH dependency tree.

8. Check the package metadata

For Codex

npm view @deepseek-ai/dsh-subagent-codex

For Claude Code

npm view @deepseek-ai/dsh-subagent-claude-code

Pay particular attention to

latest
next
dependencies

The version selected for the subagent packages should match the DSH release family being used.

What Each Error Tells You

The errors encountered during this installation are actually useful diagnostics.

Error	What it indicates
`Cannot read properties of null (reading 'children')`	The initial npm installation path is problematic
`profile bundle ... declares no dsh.bundle`	The installed package is not compatible with the profile bundle loader expected by this DSH version
`does not provide an export named findLastMessageTurnEnd`	`dsh-subagent` and `dsh-session` are using incompatible APIs
`npm list ... (empty)`	The command is checking the local project tree while the package is installed globally
`where dsh` points to `C:\nvm4w\nodejs`	The DSH executable is coming from the global Node/npm installation

The final error is the most important one because it identifies a concrete API mismatch rather than a generic startup failure.

Codex and Claude Code Use Different Provider Mechanisms

The two packages also reveal an important architectural distinction.

The Codex package describes itself as

One-shot Codex subagent provider over the official app-server protocol

The Claude Code package describes itself as

One-shot Claude Code subagent provider over the official Agent SDK

So DeepSeek Harness is not simply launching arbitrary command-line programs.

It has provider packages that adapt these external coding agents to the DSH subagent mechanism.

The architecture can therefore be understood as

                    DeepSeek Harness
                           │
                    Subagent Runtime
                       /          \
                      /            \
               Codex Provider   Claude Provider
                    │                │
          Codex app-server       Claude Agent SDK

This distinction matters when troubleshooting. If the DSH subagent layer cannot load, neither provider can be initialized successfully.

Why You Should Not Install These Packages Globally First

The global DSH installation already contains its own dependency graph.

For example

C:\nvm4w\nodejs\node_modules
└── @deepseek-ai
    └── dsh
        ├── dsh-session
        ├── dsh-subagent
        ├── dsh-base
        └── dsh-web-app

The profile has another dependency graph

C:\Users\reanod\.dsh\profiles\web
└── node_modules
    └── @deepseek-ai
        └── dsh-subagent-codex

When the profile loads a bundle, Node.js has to resolve the dependencies used by that bundle.

If the profile contains packages from one DSH release line while the core runtime belongs to another release line, the resulting module graph can contain incompatible APIs.

That is exactly what the findLastMessageTurnEnd error exposes.

Recommended Installation Model

For this particular setup, the cleanest model is to treat the DSH global installation as the runtime and the web directory as the profile dependency environment.

The workflow is

Global
C:\nvm4w\nodejs
│
└── @deepseek-ai/dsh@0.1.0-rc.8

Profile
C:\Users\reanod\.dsh\profiles\web
│
├── package.json
│
└── node_modules
    │
    ├── dsh-subagent-codex@0.1.0-rc.8
    │
    └── dsh-subagent-claude-code@0.1.0-rc.8

The critical requirement is version consistency.

Avoid a configuration like

DSH                  0.1.0-rc.8
dsh-session           0.1.0-rc.8
dsh-subagent          0.1.0-rc.8
Codex provider        0.0.1-rc.1
Claude provider       0.0.1-rc.1

The target should instead be

DSH                  0.1.0-rc.8
dsh-session           0.1.0-rc.8
dsh-subagent          0.1.0-rc.8
Codex provider        0.1.0-rc.8
Claude provider       0.1.0-rc.8

Quick Installation Checklist

Use this checklist before trying to start the profile again.

Check that node resolves to the intended Node.js installation.
Check that npm resolves to the same installation.
Check that dsh resolves to the same Node.js prefix.
Confirm the global DSH version with npm list -g @deepseek-ai/dsh.
Confirm the DSH session version with npm list -g @deepseek-ai/dsh-session.
Check the available Codex provider versions with npm view @deepseek-ai/dsh-subagent-codex.
Check the available Claude Code provider versions with npm view @deepseek-ai/dsh-subagent-claude-code.
Keep the provider packages on the same 0.1.0-rc.8 release line as the installed DSH runtime.
Install provider packages inside C:\Users\reanod\.dsh\profiles\web.
Declare the providers in the profile dependencies.
Declare the providers in the DSH bundles list.
Run dsh web only after the dependency tree is aligned.

FAQ

Are `@deepseek-ai/dsh-subagent-codex` and `@deepseek-ai/dsh-subagent-claude-code` available on npm?

Yes. Both packages can be queried through npm view. Their latest versions are 0.0.1-rc.1, while the npm metadata also exposes 0.1.0-rc.8 through the next release channel.

Why did `npm install -g @deepseek-ai/dsh-subagent-codex` fail?

The global installation produced Cannot read properties of null (reading 'children'). Installing the Codex package locally inside the DSH profile succeeded, which shows that the issue was associated with the installation context rather than the package being unavailable.

Why does `dsh web` say the package has no `dsh.bundle`?

The installed provider package version does not match the bundle format expected by the installed DSH runtime. The error appears during profile bundle loading.

What causes `findLastMessageTurnEnd` to fail?

The loaded dsh-subagent package expects @deepseek-ai/dsh-session to export findLastMessageTurnEnd, but the resolved session package does not expose that symbol. This indicates incompatible DSH package versions.

Why does `npm list @deepseek-ai/dsh` show `(empty)`?

The command without -g checks the current project’s local dependency tree. Your DSH installation is global under C:\nvm4w\nodejs\node_modules.

Which DSH version is installed in this environment?

The global installation is @deepseek-ai/dsh@0.1.0-rc.8.

What should the Codex and Claude Code versions be?

For the DSH installation described here, the logical target is 0.1.0-rc.8, because that matches the installed DSH, dsh-session, and dsh-subagent release family.

How to Add Codex and Claude Code to DeepSeek Harness on Windows