[Bug][Desktop][Windows] workspace-write can poison the DSH Desktop install directory itself, making Harness unlaunchable after restart

[HuDeyi-66]

Summary

On Windows, DeepSeek Harness Desktop can apparently apply the persistent
workspace-write ACL sandbox entries to its own installation directory.

Once this happens, the Desktop install tree receives:

• the DSH capability SID ACE
• an Everyone deny ACE
• an inheritable Low Mandatory Integrity label

The next launch of DeepSeek Harness then fails because Electron/Chromium
processes launched from the installation tree inherit Low integrity.

In my case this was reproducible twice.

This appears related to #7709, but with a more severe Desktop-specific failure
mode: the directory being poisoned is the directory containing
DeepSeek Harness.exe itself.

It may also explain some symptoms similar to #7823.

---

Environment

• OS: Windows x64

• DeepSeek Harness Desktop: 0.1.7-rc.2

• Electron: 44.0.0

• Node: 24.18.1

• Installation directory:

  D:\DeepSeek Harness

• Desktop profile:

  %USERPROFILE%\.dsh\profiles\desktop

• Desktop profile contained only the official bundles:

{
  "name": "dsh-profile-desktop",
  "private": true,
  "dependencies": {},
  "dsh": {
    "profile": {
      "bundles": [
        "@deepseek-ai/dsh-base",
        "@deepseek-ai/dsh-web-app"
      ]
    }
  }
}

Reproduction / observed sequence
1. Harness is healthy
After manually restoring the ACL of:
D:\DeepSeek Harness
DeepSeek Harness Desktop launches normally.
The healthy ACL is:
D:\DeepSeek Harness
    APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(OI)(CI)(RX)
    NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(F)
    NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(F)
    BUILTIN\Users:(I)(OI)(CI)(RX,W)
    Mandatory Label\Medium Mandatory Level:(OI)(CI)(NW)

The application launches successfully in this state.
2. Perform a file/plugin-management operation through DSH
While Harness was running normally, I asked the DSH agent to remove a redundant
desktop-pet/plugin-related item.
After the operation, Harness was closed/restarted.
3. Harness becomes completely unlaunchable
Double-clicking DeepSeek Harness.exe produces no visible window.
Starting it from PowerShell exposes the actual failure:
GPU process launch failed: error_code=18
Desktop renderer exited: launch-failed
GPU process launch failed: error_code=18
FATAL: GPU process isn't usable. Goodbye.

The process exits with:
-2147483645

which corresponds to:
0x80000003 / STATUS_BREAKPOINT

Using --disable-gpu does not fix the crash.
The parent PowerShell process itself is Medium integrity
(S-1-16-8192), so this is not caused by launching Harness from an
elevated or Low-integrity shell.
Critical evidence: install-directory ACL is mutated
Immediately after Harness becomes unlaunchable:
icacls "D:\DeepSeek Harness"

shows:
D:\DeepSeek Harness
    Everyone:(CI)(DENY)(S,DC)
    S-1-4-979659899-60949555:(OI)(CI)(W,D,DC)
    APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(OI)(CI)(RX)
    NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(F)
    NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(F)
    BUILTIN\Users:(I)(OI)(CI)(RX,W)
    Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

These are the same standing ACL changes associated with the Windows
workspace-write sandbox:
- capability SID
- Everyone deny
- inheritable Low integrity label
The drive root itself is clean:
D:\
    NT AUTHORITY\Authenticated Users:(OI)(CI)(F)
    NT AUTHORITY\SYSTEM:(OI)(CI)(F)
    BUILTIN\Administrators:(OI)(CI)(F)
    BUILTIN\Users:(OI)(CI)(RX,W)

Therefore the problematic ACL is not inherited from D:\.
Recovery
Removing the capability SID and explicit Everyone deny, and changing the
integrity label from Low back to Medium, immediately restores the Desktop.
The recovery used was:
$root = "D:\DeepSeek Harness"

$acl = (Get-Item $root).GetAccessControl('Access')

$cap = [Security.Principal.SecurityIdentifier]'S-1-4-979659899-60949555'
$acl.PurgeAccessRules($cap)

$everyone = [Security.Principal.SecurityIdentifier]'S-1-1-0'

foreach ($r in @(
    $acl.GetAccessRules(
        $true,
        $false,
        [Security.Principal.SecurityIdentifier]
    )
)) {
    if (
        $r.AccessControlType -eq [Security.AccessControl.AccessControlType]::Deny `
        -and $r.IdentityReference -eq $everyone
    ) {
        [void]$acl.RemoveAccessRuleSpecific($r)
    }
}

(Get-Item $root).SetAccessControl($acl)

icacls "D:\DeepSeek Harness" /grant "*S-1-15-2-2:(OI)(CI)(RX)" /T /C
icacls "D:\DeepSeek Harness" /setintegritylevel "(OI)(CI)M"

After this, the ACL returns to Medium integrity and DeepSeek Harness launches
normally again.
Reproducibility
This occurred twice.
Sequence observed:
Harness working
    ↓
install directory ACL is healthy / Medium
    ↓
DSH performs file/plugin-related operation
    ↓
install directory receives workspace-write ACL
    ↓
Harness restart
    ↓
Electron renderer/GPU process launch fails
    ↓
0x80000003
    ↓
manually remove workspace-write ACL + restore Medium
    ↓
Harness launches normally again

On the second occurrence, the ACL state was checked immediately after the
failure and the same three workspace-write entries had reappeared.
This makes the correlation highly reproducible.
Expected behavior
The Desktop installation directory must never be treated as a writable
workspace by dsh-sandbox-windows-acl.
At minimum, DSH Desktop should reject / guard against applying
workspace-write provisioning to:
- the directory containing DeepSeek Harness.exe
- its resources directory
- the Desktop installation root
- any parent directory required for launching the Desktop runtime
Ideally the Desktop runtime should canonicalize candidate workspace paths and
fail safely if the requested workspace overlaps the installation tree.
Actual behavior
The Desktop installation tree can receive the persistent workspace-write
security descriptor.
Because the Low integrity label is standing and inheritable, the next launch of
the Desktop itself becomes Low-integrity and Electron exits with
STATUS_BREAKPOINT.
This effectively allows a normal DSH workspace/file-management operation to
make the DSH Desktop unable to launch itself.
Related reports
- #7709 — Windows workspace-write Low integrity label lowers executables
  launched from the labeled tree and can break Electron with 0x80000003.
- #7823 — Desktop installed to a custom Windows directory can fail to launch
  its renderer because of installation-directory ACLs.
This report appears to connect the two failure classes:
the DSH sandbox can place its own Desktop installation directory into the ACL
state that subsequently breaks Electron startup.
Suggested fix
Possible safeguards:
1. Explicitly forbid workspace-write provisioning when the canonical
   workspace path overlaps the Desktop installation directory.
2. Add a Desktop startup check for the workspace-write capability ACE /
   inheritable Low integrity label on the installation root.
3. Provide an official command/API to revoke a standing workspace grant.
4. Avoid leaving an inheritable Low integrity label on executable installation
   trees.
5. If such a path is selected, fail before modifying the directory ACL and show
   a clear diagnostic.
The most important invariant seems to be:
workspace-write must never mutate the security descriptor of the directory
containing the currently installed/running DSH Desktop runtime.

[HuDeyi-66]

Important clarification: the ACL mutation happens while Desktop remains running

The Desktop application did not crash, close, or restart during this reproduction.

DeepSeek Harness remained running throughout the entire sequence.

The sequence was:

1. Desktop was already running normally.

2. The installation directory had a healthy Medium-integrity ACL.

3. I installed dsh-theme-endfield through the built-in Plugins UI.

4. Desktop remained open and responsive.

5. Before any restart, I immediately checked the installation-directory ACL.

6. The workspace-write ACL entries had already appeared:

   • Everyone:(CI)(DENY)(S,DC)
   • capability SID S-1-4-979659899-60949555
   • Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

Therefore the ACL mutation occurs during the plugin-management operation itself,
not during Desktop shutdown or startup.

The currently running Desktop process survives because it was already launched.
The corrupted Low-integrity label becomes fatal on a subsequent launch of the
Desktop executable from that directory.

After restoring the directory to Medium integrity while Desktop was still
running, the application continued normally.

[hnbdr]

The situation is rather unfortunate. Any project that touches DSH while the sandbox plugin is enabled by default receives a "Low IL" designation for its entire recursive content. Any executables the user runs from these directories will fail to interact correctly with the temp directory and other resources, crashing with non-obvious errors.