dsh-sandbox-console-fix
Windows only. A DeepSeek Harness bundle that
makes the confined sandbox usable on the desktop app: workspace-write shell calls start again, and
read-only keeps working — without relaxing any confinement. Both of this bundle's patch rows are
platform-guarded, so on Linux/macOS the composition is untouched and the package is inert.
Targets DeepSeek Harness desktop 0.2.0-rc.2 — Electron 44.0.0 / Node 24.18.1, verified on
Windows 11 22H2 x64.
Reported upstream as a Discussion:
https://github.com/deepseek-ai/deepseek-harness/discussions/9280.
⚠️ NOT REVIEWED BY ANY HUMAN
AI-generated code. Found, designed, written and tested end-to-end by DeepSeek V4.1-flash, an AI
agent running in DeepSeek Harness. A human directed the work and approved the steps, but no human has
read, reviewed, audited or approved this code or its evidence. Treat it exactly like unreviewed
third-party code from an unknown author: read index.js, console-shim.mjs and cordis.patch.yml
yourself before installing, and do not run it anywhere you would not run an unreviewed script.
The same warning accompanies every comment this project posts upstream.
Prior art and corroboration
@argszero/cordis-plugin-sandbox-grant-advisor (0.17.0) already names this failure shape as its
native-init family and explains it: a confined child that never reaches its first instruction, split
into the packaged GUI-subsystem host and a console-subsystem node.exe whose runner was started with
DETACHED_PROCESS. It is an advisor — it names and diagnoses; this bundle is the repair. Its measured
remedies (Harness discussions #8193 / #8208) are followed here, including restoring the runner's three
standard handles around AllocConsole(). The longer mechanism write-up is discussion #9238, and the
report is #9280.
Root cause and what this bundle does
The restricted token that runs the confined child gets one extra full-access ACE merged into its
Default DACL: tempWriteSidPtr ?? writeSidPtr ?? worldSid — the capability write SID in
workspace-write, Everyone in read-only. On a host whose process token's Default DACL lacks
Everyone, a child that has to create a console during DLL initialization dies with 0xC0000142 — and
it only has to when the sandbox runner owns no console (the packaged desktop app's Electron host).
Primary mechanism (since 0.2.0). The shim runs inside the runner process before the runner derives
the restricted token, and merges Everyone into that process token's Default DACL. The restricted token
inherits it, which is exactly what the shipped read-only path already does — so no console handling is
needed at all.
Fallback. If the merge cannot be applied, the shim gives the runner a console instead:
AllocConsole() with the three standard handles saved and restored and the window hidden.
Measured on one host: shipped runner → child 3221225794; Default-DACL merge only → child 0; writes
outside the workspace still denied and absent; the child's own console stays hidden. Setting
DSH_SANDBOX_CONSOLE_FIX_DEBUG to a file path records which path was taken. The structural fix belongs
upstream — a one-line Default-DACL change, previously reported with a source patch in the Harness
discussions (routing index: #9195).
The problem
On the packaged Windows desktop app, any shell call under workspace-write fails immediately:
[exit code: 3221225794] # 0xC0000142 STATUS_DLL_INIT_FAILED
pwsh, cmd and powershell all fail the same way, both MSI and Store-packaged PowerShell builds,
while danger-full-access and read-only work — so the shell tool is fine and the
workspace-write confinement path is the problem.
The failure needs two conditions together — a console-less runner host (the Electron binary) and
workspace-write. The complete matrix is in docs/VERIFICATION.md. Why the child's own console creation succeeds in the one mode and fails in the other is not isolated — see sections 5 and 9 of that record; the fix works in both modes either way.
Root cause, in the shipped code (dsh-sandbox-local, windowsAclRunnerInvocation()):
if (existsSync(builtEntry)) return [process.execPath, builtEntry];
In the desktop app process.execPath is DeepSeek Harness.exe — an Electron binary, i.e. a
GUI-subsystem image, which never has a console. Measured on one machine, same parent process:
| runner host | GetConsoleWindow() |
|---|
node.exe (console subsystem) | non-zero → has a console |
DeepSeek Harness.exe (GUI subsystem) | 0 → no console |
The ACL runner then spawns the confined child without CREATE_NO_WINDOW / CREATE_NEW_CONSOLE
— on purpose, because per DSH's own documentation such children die during DLL initialization under
the restricted token — and relies on the child inheriting the runner's console. With nothing to
inherit, the console-subsystem child must create a console itself; that creation fails under the
Low-integrity write-restricted token, and the process exits STATUS_DLL_INIT_FAILED (0xC0000142).
The fix
One extra argv entry, in the position DSH's own development path already uses for the same runner
([process.execPath, "--import", <url>, entry]):
shipped: [execPath, runner.js, …profile, --, target]
this: [execPath, --import <console-shim.mjs>, runner.js, …profile, --, target]
console-shim.mjs merges one Everyone full-access ACE into the runner process token's Default DACL (falling back to AllocConsole() only when that cannot be applied), so the
confined child inherits a console and starts normally.
What does not change
| shipped | with this bundle |
|---|
| restricted token (Low IL + write-restricted SIDs) | ✔ | identical — except the token's Default DACL gains an Everyone full-access ACE, exactly the ACE the shipped read-only path already merges |
| workspace / private-temp capability-SID grants, deny ACEs | ✔ | identical |
| integrity label, Job object, stdio plumbing, denial dialects | ✔ | identical |
| runner and child environment | ✔ | identical — nothing injected |
dsh-fs-sandbox file policy | ✔ | untouched |
Verified with an escape-write test run inside the confined child: four out-of-workspace targets are
denied and absent on disk, while an in-workspace write succeeds — see
docs/VERIFICATION.md.
Install
Install it the way dsh expects — through the Plugin Manager, which performs package installation
and bundle selection itself:
- Open the Plugin Manager page and install a bundle from
https://github.com/TJZF-4j97/dsh-sandbox-console-fix, or from an absolute path to a checkout of
this directory.
- Restart the Harness.
- Set the session to
workspace-write and run any shell command.
Nothing is downloaded and no build script is requested, because the package deliberately declares no
dependencies: index.js loads LocalSandboxProvider from the running Harness bundle, and
console-shim.mjs resolves koffi there too. The Harness's own installer recorded exactly that —
Packages: +1, zero downloads, no pending build scripts.
cordis.patch.yml mounts this provider by disabling the shipped sandbox row and inserting its own,
both rows platform-guarded with !!js — the idiom the shipped dsh-base patch uses for its own
bash-sandbox row. That shape is required by the Loader dialect: a non-insert patch that targets an
existing row replaces its fields, and a truthy name only asserts the existing plugin name, so a
provider row cannot be swapped by overriding its id. On Windows the composition keeps exactly one
ctx.sandbox provider and the shipped package still resolves from the dsh installation; on other
platforms the shipped row stays enabled and this bundle's row stays disabled.
Installing by hand (not recommended)
Copy the directory somewhere the profile can resolve, add the name to dsh.profile.bundles, then
restart:
Copy-Item -Recurse -Force .\dsh-sandbox-console-fix "$env:USERPROFILE\.dsh\profiles\desktop\node_modules\dsh-sandbox-console-fix"
{ "dsh": { "profile": { "bundles": ["@deepseek-ai/dsh-base", "@deepseek-ai/dsh-web-app", "dsh-sandbox-console-fix"] } } }
The Plugin Manager route is preferred: install_bundle snapshots and restores package.json and
pnpm-lock.yaml when an install fails, and keeps the profile's own bookkeeping consistent.
Verify
With the session set to workspace-write:
$PSVersionTable.PSVersion # expect 7.6.6 — not 0xC0000142
Set-Content 'C:\Users\<you>\nope.txt' 'x' # expect [sandbox: file access denied under workspace-write mode]
Set-Content '.\ok.txt' 'x' # expect success
Remove-Item '.\ok.txt'
Not caused by this bundle: inside the confined shell the sandbox blocks piped stdio between
programs, so $x = & some.exe … and some.exe | Out-Null fail (EPERM; PowerShell surfaces it as
StandardOutputEncoding is only supported when standard output is redirected), while a bare
& some.exe …, PowerShell's own cmdlet pipelines and file redirection work. That is the sandbox's
documented confinement.
Reproduce the underlying mechanism without installing anything:
node scripts/console-probe.cjs # host-console probe
node scripts/console-probe.cjs --host electron # same parent, Electron host
node scripts/full-chain-repro.js --help # drive the shipped runner under both hosts
powershell -File scripts/escape-test.ps1 -Workspace <dir> # confinement check
See scripts/README.md for the extracted-runner paths those scripts need.
Uninstall
Remove the bundle name from the profile's bundles list (and the dependency), then restart. No
system-level change is left behind — the workspace ACEs and integrity label that the Harness itself
owns are not touched by this bundle.
Compatibility
| |
|---|
| Platform | Windows 10/11, x64 |
| Harness | DeepSeek Harness desktop 0.2.0-rc.2 (Electron 44.0.0 / Node 24.18.1) — the subclass overrides one method of @deepseek-ai/dsh-sandbox-local@0.2.0-rc.2 |
| Node / Electron | any (--import requires Node ≥ 20.6 / Electron with Node ≥ 20.6) |
| Upstream report | https://github.com/deepseek-ai/deepseek-harness/discussions/9280 |
| Other platforms | the override is never called; the package is inert |
Because it subclasses a Harness-internal class, re-check after a Harness upgrade — the upstream fix
(see the issue report) makes this package unnecessary.
Discovery
DeepSeek Harness's CONTRIBUTING.md
asks ecosystem plugins to associate their GitHub project with the dsh-plugin topic. This
repository carries it — together with dsh, deepseek-harness, sandbox, windows and pwsh — so
the plugin is discoverable from that topic listing.
Security
The bundle does not widen file authority, and this is measured rather than argued: with the Default-DACL
merge applied, writes to %USERPROFILE%, the drive root, C:\Windows\Temp and the user temp directory
are still denied and the files are absent, while an in-workspace write succeeds. What changes is only the
runner process token's Default DACL, which gains one Everyone full-access ACE — the same ACE the
shipped runner already merges on its read-only path. The restricting SIDs, the Low integrity label, the
workspace and private-temp grants, the denial ACEs and the fs policy are untouched, and the shim performs
no process creation and no environment change. It writes one file only when
DSH_SANDBOX_CONSOLE_FIX_DEBUG is explicitly set to a path, for support. Every failure is swallowed so
the runner keeps its shipped behaviour.
License
MIT
Security review (three adversarial rounds, 2026-10-11)
This is an AI self-review, not a human audit. Three attack/fix/functional-test rounds were run
against the installed bundle; every finding below was reproduced before it was fixed, and every fix was
re-tested against the same attack.
| Finding | Severity | Status |
|---|
A bare require('koffi') resolved from this plugin's ancestor directories — all writable by any local process — so a planted package executed inside the sandbox runner (outside the sandbox). Reproduced. | High | Fixed: koffi is now resolved only from inside the running Harness installation. |
index.js loaded @deepseek-ai/dsh-sandbox-local through the same walk-up chain, unvalidated; a planted class runs inside the Harness process and controls windowsAclRunnerInvocation(). Reproduced. | High | Fixed: the resolution's realpath must be inside this plugin's own node_modules or the dsh profile root. |
| The diagnostic env var wrote an arbitrary absolute path, truncating any existing file. Reproduced. | Medium | Fixed: the diagnostic now emits one stderr line and performs no file writes. |
| A missing or unreadable shim was preloaded unconditionally, so the runner failed to start and every sandboxed command failed. Reproduced. | Medium | Fixed: the shim's existence is checked before it is preloaded. |
The merge's re-read only compared the ACE count, so a silent SetTokenInformation no-op would be reported as success. | Medium | Fixed: the Default DACL is now walked and the ACE must name Everyone and carry FILE_ALL_ACCESS. |
| Token handle, SID and merged ACL were never released. | Low | Fixed: CloseHandle + LocalFree. |
The EXPLICIT_ACCESS_W layout is 64-bit; other architectures were not excluded. | Low | Fixed: the merge is skipped off x64 and the console fallback is used. |
| The fallback's standard-handle restore had no per-step protection. | Low | Fixed: each step is individually guarded. |
An inherited Authenticated Users: Modify ACE (from the volume hosting the plugin directory) applies to this plugin's source directory, and the profile installs it with link:, so any authenticated local user can rewrite the executed code — including cordis.patch.yml, whose !!js expressions the Loader evaluates as code. Verified by icacls and by reading the Loader. |
What this bundle changes, precisely
- It merges one
Everyone full-access ACE into the runner process token's Default DACL, before the
runner derives the restricted token — the same ACE the shipped runner already merges on its
read-only path. The restricted token therefore inherits it.
- Scope: a Default DACL governs the initial ACL of every securable object that token holder creates
without an explicit security descriptor, so this is process-wide for the runner, not limited to the
confined child. It is per-process and disappears when the Harness exits.
- Measured after the fix: the confined child starts, its own restricted token's Default DACL contains
the
Everyone ACE with mask 0x1f01ff, writes outside the workspace stay denied and absent, and the
child's own console is created hidden.
- Uninstall this bundle before validating a Harness upgrade — while it is installed, its
disabled
patch silently discards any upstream change to the shipped sandbox row.
