DeepSeek Harness Error deployment:persona already registered: A Real-World Troubleshooting Journey from Reinstallation to .dsh Profile Conflicts
Most DeepSeek Harness installation issues tend to revolve around model providers, API authentication, MCP connections, or tool integrations. This one was different.
The error looked like a simple configuration problem at first glance:
internal: resume failed for session "session-3836a0e6-9fe9-40d7-884e-876b3ebba209"
Error: agent-presets: preset "standard" failed to mount
failed to apply loader entry persona (@deepseek-ai/dsh-persona):
prompt section "deployment:persona" is already registered
The natural assumption is that a Persona configuration was duplicated somewhere inside the preset configuration.
After several rounds of investigation, the root cause turned out to be much more subtle. The issue was not the installation itself, but a combination of persisted session state, profile data, and files stored inside the local .dsh directory.
This article documents the complete troubleshooting process.
Environment Overview
Before changing anything, the first step was to verify the current DeepSeek Harness installation.
Check the installed version:
dsh --version
Output:
0.1.0-rc.8
Inspect the installed packages:
npm list -g --depth=2 @deepseek-ai/dsh @deepseek-ai/dsh-persona
Output:
C:\nvm4w\nodejs
`-- @deepseek-ai/dsh@0.1.0-rc.8
`-- @deepseek-ai/dsh-persona@0.1.0-rc.8
Verify the actual executable path:
where.exe dsh
Output:
C:\nvm4w\nodejs\dsh
C:\nvm4w\nodejs\dsh.cmd
Check which command PowerShell is executing:
Get-Command dsh
Output:
ExternalScript dsh.ps1
C:\nvm4w\nodejs\dsh.ps1
At this point several things were already confirmed:
-
DeepSeek Harness and the Persona package were running the same version. -
No duplicate installations were visible. -
The environment was managed through NVM for Windows. -
The CLI entry points were resolving correctly.
The Failure Happened During Session Resume
The interesting detail was that the error did not occur when launching DeepSeek Harness.
It happened while attempting to resume an existing session.
The relevant part of the error was:
prompt section "deployment:persona" is already registered
That message contains two important clues:
| Element | Meaning |
|---|---|
| deployment:persona | Prompt section identifier |
| already registered | Another registration already exists |
At face value, this suggests a duplicate Persona registration.
The problem was that there was no obvious duplicate Persona configuration in the active preset.
Inspecting the Standard Preset Configuration
The next step was examining the standard preset definition:
@deepseek-ai/dsh/config/agent-presets/standard/agent.cordis.yml
Inside the file was the following section:
- id: persona
name: '@deepseek-ai/dsh-persona'
config:
text: >-
You are a coding agent powered by the {{model}} model.
Even more interesting was the accompanying comment:
The preset's own persona, shadowing the deployment default for this agent.
That indicates a design similar to:
Deployment Persona
↓
Standard Preset Persona
↓
Agent Persona
In other words, the Persona entry is expected to exist.
Removing it would merely hide the symptom rather than address the root cause.
Checking for Multiple Running Instances
To eliminate the possibility of stale background processes, all Node-related processes were inspected.
Get-CimInstance Win32_Process -Filter "Name='node.exe'" |
Select-Object ProcessId,ExecutablePath,CommandLine
Among the results were:
5536 npm start
13676 node index.js
12104 @deepseek-ai/dsh
The presence of active DSH-related processes suggested that old runtime state might still be involved.
At this point a complete uninstall became the fastest path forward.
Removing DeepSeek Harness
After stopping active DSH processes, the package was removed:
npm uninstall -g @deepseek-ai/dsh
Output:
removed 452 packages in 11s
Verify that the executable is gone:
where.exe dsh
Result:
INFO: Could not find files for the given pattern(s).
The CLI launcher had been successfully removed.
A second verification confirmed that the package no longer appeared in the global npm list.
Cleaning the npm Cache
The cache was then validated:
npm cache verify
Followed by a complete cleanup:
npm cache clean --force
Current runtime environment:
node -v
npm -v
Output:
v25.0.0
11.6.2
Should Node.js Be Downgraded?
A common troubleshooting recommendation is to switch to an LTS release such as Node 24.
In this environment that approach created additional complications.
The machine was already being used for:
Codex CLI
Claude Code CLI
Switching Node versions introduced compatibility issues for those tools.
More importantly, the observed failure occurred during:
Persona Registration
Preset Mounting
Session Resume
rather than during Node runtime execution.
There was no direct evidence linking Node 25 to the Persona registration conflict.
Changing Node versions at this stage would only introduce another variable into the investigation.
Testing DeepSeek Harness Through NPX
With the global installation removed, the next step was running DeepSeek Harness directly through NPX:
npx --yes @deepseek-ai/dsh@0.1.0-rc.8 web
The result was unusual:
No error message
No output
Appeared to hang indefinitely
This is exactly the type of behavior that often gets misdiagnosed as:
-
npm registry problems -
network failures -
corrupted package downloads -
broken release builds
The actual cause turned out to be something entirely different.
The Critical Clue Came from the .dsh Directory
An attempt was made to remove the local DSH profile directory:
C:\Users\<username>\.dsh
Windows immediately displayed:
The action can't be completed because the folder or a file in it is open in another program.
That changed the direction of the investigation completely.
The problem was no longer centered on installation packages.
The focus shifted to the .dsh directory itself.
Finding the Process Holding .dsh
The following command was used to identify processes interacting with DeepSeek Harness files:
Get-CimInstance Win32_Process |
Where-Object {
$_.Name -match 'node|npm|npx' -or
$_.CommandLine -match 'deepseek|dsh'
} |
Select-Object ProcessId,Name,ExecutablePath,CommandLine
The results revealed two unexpected entries:
6544 notepad.exe
C:\Users\reanod\.dsh\profiles\web\package.json
and:
6188 notepad.exe
agent.cordis.yml
This was the turning point.
The .dsh directory was not locked by DeepSeek Harness itself.
It was being held open by Notepad.
What Was Stored Inside .dsh?
The process information exposed a profile structure similar to:
.dsh
└─ profiles
└─ web
└─ package.json
That confirmed the existence of historical profile data.
Combined with the earlier session identifier:
session-3836a0e6...
it became clear that this was not a clean installation environment.
The system still contained:
Old Sessions
Old Profiles
Old Runtime State
all of which could influence startup behavior.
Safely Removing the User Profile
Before deleting the directory, all applications holding files open had to be closed.
Either close the Notepad windows manually or terminate them directly:
Stop-Process -Id 6544 -Force
Stop-Process -Id 6188 -Force
Verify that no relevant process remains:
Get-CimInstance Win32_Process |
Where-Object {
$_.CommandLine -match '\.dsh|deepseek'
}
Then remove the profile directory:
Remove-Item "$HOME\.dsh" -Recurse -Force
Confirm deletion:
Test-Path "$HOME\.dsh"
Expected result:
False
At this point the local user state had been fully reset.
The Correct Way to Validate the Fix
The next step is important.
Do not immediately resume the previous session.
First verify that DeepSeek Harness itself works correctly:
npx --yes @deepseek-ai/dsh@0.1.0-rc.8 --version
Expected output:
0.1.0-rc.8
Then launch the web interface:
npx --yes @deepseek-ai/dsh@0.1.0-rc.8 web
Create a completely new session:
New Session
↓
standard
↓
Hello
Avoid reopening:
session-3836a0e6-9fe9-40d7-884e-876b3ebba209
This isolates the framework from any persisted session state.
If the new session works, the issue is likely tied to the previous session or profile data.
If the same Persona registration error reappears, the investigation can move toward the preset loading mechanism inside DeepSeek Harness itself.
Quick Reference Checklist
Check DeepSeek Harness Version
dsh --version
Verify Installation
npm list -g --depth=2 @deepseek-ai/dsh
Remove Global Installation
npm uninstall -g @deepseek-ai/dsh
Clear npm Cache
npm cache clean --force
Verify Node Environment
node -v
npm -v
Find Active Processes
Get-CimInstance Win32_Process
Remove Local DSH Profile
Remove-Item "$HOME\.dsh" -Recurse -Force
Launch DeepSeek Harness with NPX
npx --yes @deepseek-ai/dsh@0.1.0-rc.8 web
FAQ
Does deployment:persona already registered always indicate a configuration mistake?
No. In this case the standard preset configuration appeared valid, and the error was more closely associated with persisted runtime state.
Can I simply remove the Persona section from the standard preset?
That is generally not recommended. The Persona entry is part of the preset design and exists for a reason.
Is Node.js 25 responsible for this error?
No direct evidence pointed to Node 25 as the cause during this investigation.
Why not downgrade to Node 24?
The system was already running Codex CLI and Claude Code CLI. Changing Node versions introduced additional compatibility concerns without addressing the actual error.
Is it safe to delete the .dsh directory?
Yes, provided no process is actively using files inside the directory.
What does .dsh contain?
The investigation showed that it stores profile information, web-related configuration, and session-related data.
Why did npx appear to hang without output?
A locked or inconsistent .dsh environment can prevent normal startup behavior and make the process appear stalled.
Should I resume the old session first after reinstalling?
No. Always test with a brand-new session before reintroducing previous session data. This makes it much easier to distinguish framework issues from state-related problems.
