[Windows] Sandbox labels the whole workspace tree as Low integrity -> Explorer renders every icon in the workspace as a generic blank page

[zeal-hope-love]

Summary

On Windows, when a session workspace is used in a sandboxed file mode (observed with workspace-write), DSH applies a mandatory integrity label of Low to the workspace root:

Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

Because the ACE is inheritable (OI/CI), every file and folder in the tree becomes Low integrity. Windows Explorer then refuses to render icons for those objects and shows the generic blank-page icon for everything — and the label persists after the session, until it is manually restored.

This is very visible when the workspace is a folder the user actually looks at. The Desktop is an obvious choice of workspace, and in our case all 20+ desktop shortcuts turned into white blank pages, which looks like a broken Windows/icon-cache problem.

Rebuilding the Windows icon cache does not help (verified). Only restoring the integrity level fixes it.

Environment

Item	Value
OS	Windows 10/11 Home 25H2, build 26200.9457, x64
DSH desktop app	0.2.0-rc.2 (DeepSeek Harness.exe FileVersion)
dsh runtime	0.1.5-rc.2 (@deepseek-ai/dsh)
Workspace	C:\Users\PoXia\Desktop (the user's real Desktop)
File policy observed	workspace-write (sandbox active); issue persisted afterwards
User	local standard user (not administrator)

ACL the sandbox left behind on the workspace root

C:\Users\PoXia\Desktop
  Everyone:(CI)(DENY)(DC)
  WYFJ\CodexSandboxUsers:(OI)(CI)(RX)
  S-1-4-725516237-812817362:(OI)(CI)(W,D,DC)
  NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
  BUILTIN\Administrators:(I)(OI)(CI)(F)
  WYFJ\PoXia:(I)(OI)(CI)(F)
  Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)      <-- root cause

Every child inherits the label, e.g.

C:\Users\PoXia\Desktop\DeepSeek Harness.lnk
  WYFJ\CodexSandboxUsers:(I)(RX)
  WYFJ\PoXia:(I)(F)
  Mandatory Label\Low Mandatory Level:(I)(NW)            <-- inherited

For comparison, a folder the sandbox had touched but not labeled (an old workspace) only carries CodexSandboxUsers:(OI)(CI)(RX) and shows no icon problem — which matches the fact that the icon failure is caused specifically by the integrity label, not by the ACL entries.

Minimal reproduction (no DSH required)

$t = "$env:USERPROFILE\IconTest"
New-Item -ItemType Directory -Path $t -Force | Out-Null
$sh = New-Object -ComObject WScript.Shell

# 1) normal folder
$l = $sh.CreateShortcut("$t\before.lnk"); $l.TargetPath = "$env:WINDIR\System32\notepad.exe"; $l.Save()
# Explorer shows the normal Notepad icon

# 2) reproduce: label the folder Low + No-Write-Up
icacls $t /setintegritylevel (OI)(CI)Low:(NW)
$l = $sh.CreateShortcut("$t\after.lnk"); $l.TargetPath = "$env:WINDIR\System32\notepad.exe"; $l.Save()
# Explorer now shows the generic blank-page icon for after.lnk
# (any file created in, or already labeled Low inside, this folder behaves the same)

# 3) fix
icacls $t /setintegritylevel (OI)(CI)Medium
$l = $sh.CreateShortcut("$t\restored.lnk"); $l.TargetPath = "$env:WINDIR\System32\notepad.exe"; $l.Save()
# icon is normal again

Objective measurement via SHGetFileInfo(..., SHGFI_ICON) at 32×32, counting non-white / colored pixels
(4=transparent, colored = channel spread > 12):

Folder state	Shortcut icon signature
normal folder	non-white=660, colored=529 ✅ real icon
after Low:(NW)	non-white=180, colored=45 ❌ identical value for every shortcut = generic icon
after restoring Medium	non-white=660, colored=529 ✅

After restoring the label on the real workspace, the previously blank shortcuts resolved to their real icons again
(e.g. WorkBuddy 819 colored pixels, VS Code 622, DevEco Studio 447, Motrix 350, Baidu Netdisk 303).

Things that do not fix it

• Rebuilding the icon cache: stop explorer.exe, delete %LOCALAPPDATA%\Microsoft\Windows\Explorer\iconcache_*.db, restart. Icons come back blank. (i.e. this is not an icon-cache corruption.)
• Restarting Explorer / ie4uinit.exe -show.
• Re-creating the shortcut, or copying a shortcut that works elsewhere into the workspace: it renders blank as soon as it lives in the workspace tree.

Impact

• Every icon in every sandboxed workspace turns into a blank page for the user, for as long as the label stays — and it survives the session (it is a persistent inheritable ACE on the user's folder).
• Users are likely to misdiagnose it as an icon-cache / malware / "my files are corrupted" problem.
• It also silently weakens the user's folder state: the sandbox additionally leaves Everyone:(CI)(DENY)(DC) and a synthetic-SID ACE on the user's real directory.

Suggested fixes (in order of preference)

1. Do not put the integrity label on the workspace root. If a Low-integrity writable area is needed, use a dedicated subdirectory (e.g. <workspace>\.dsh_sandbox\) and confine the label there.
2. If the root must be labeled, restore the original label and ACLs when the sandboxed turn ends (i.e. treat the label as part of the sandbox's acquire/release bookkeeping, and revert it on release).
3. At minimum, do not make the label inheritable over pre-existing user content (OI/CI) and do not apply it recursively to files the user already had.
4. Warn (or refuse by default) when the selected workspace is a shell-visible folder such as Desktop / Documents / Downloads.
5. The bundled diagnose-windows-sandbox-acl skill only repairs access denials. It would be worth extending it (or having DSH record/restore the original label) so this side effect is detected and repaired too.

User-side workaround

# restore integrity label (fixes the icons immediately)
icacls "<workspace path>" /setintegritylevel (OI)(CI)Medium
# remove the leftover sandbox entries (optional)
icacls "<workspace path>" /remove:d Everyone
icacls "<workspace path>" /remove:g "CodexSandboxUsers"

Note this re-degrades the sandbox protection while it is applied, and the problem comes back if the sandbox re-labels the workspace on the next sandboxed turn — so it is not a real fix.

Related symptom (reported by the user, not independently confirmed)

In the same workspace, launching .lnk files also produced the Attachment Manager dialog
"打开文件 - 安全警告 / 来自 Internet 的文件可能对你有所帮助…", although none of those files carried a
Zone.Identifier stream (verified two independent ways: Get-Item -Stream Zone.Identifier and dir /r).
After the integrity label was restored to Medium, the user reported the dialog no longer appears.
Might be worth checking whether Low-integrity objects also affect the shell's execution/zone policy.

---

中文摘要

Windows 上启用沙箱（workspace-write）后，DSH 会给工作区根目录加上
Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)。该 ACE 可继承，于是整棵目录树的每个文件都变成"低完整性"，
Explorer 对这些文件一律只画通用白纸图标（本例工作区恰好是用户桌面，桌面上所有快捷方式瞬间全变白纸）。
重建图标缓存无效，只有把标签改回 Medium 才恢复；而且这个标签在会话结束后仍然留在用户目录上。
同时还残留 Everyone:(CI)(DENY)(DC)、CodexSandboxUsers:(OI)(CI)(RX) 和一个合成 SID 授权项。
建议：不要把 Low 标签打在用户已有的工作区根目录上（或改放到专用子目录），并在沙箱会话结束时还原标签与 ACL。

[simonhx6]

Same!

[Daniel-sjy]

same!

[hellowind777]

Confirmed on 0.2.1-rc.2: shortcut icons, custom folder icons, and PowerShell script execution affected

I encountered this after using my actual Windows Desktop as the workspace for a DeepSeek Harness session investigating intermittent PC stuttering. The problem persisted after the session. I have now recovered the desktop and can provide controlled before/after evidence.

Environment

• DeepSeek Harness desktop executable FileVersion: 0.2.1-rc.2
• Windows 11 Pro, version 26H2, build 26300.9711, x64
• Workspace: %USERPROFILE%\Desktop
• The affected Harness session used workspace-write sandboxing.
• Script execution tests: built-in Windows PowerShell 5.1, effective execution policy RemoteSigned.

Observed symptoms

1. Many desktop .lnk files displayed generic white-page icons, even though their targets and icon resources existed.
2. Four folders lost their desktop.ini custom icons despite retaining the required folder/file attributes and valid icon resource paths.
3. The same shortcuts and custom folders displayed correctly in a backup directory outside the affected tree, including in Windows File Explorer itself.
4. Copying a working shortcut into the Desktop, or a newly created diagnostic subdirectory beneath it, produced the broken icon again.
5. Shortcuts stored in the public Desktop continued to display correctly, making the merged desktop appear only partially broken.

The affected Desktop root had:

Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

Its shortcuts and desktop.ini files inherited the Low label. The working backup and public-Desktop shortcuts did not have that label. For the compared shortcut, there was no Zone.Identifier stream.

Controlled tests on disposable copies

Test	Low integrity	After changing to Medium
Byte-identical shortcut, verified with SHA-256	SHGetFileInfo returned the generic file icon; icon location was empty	Returned the original application's .ico resource
Folder with the original custom desktop.ini	Returned the generic folder resource imageres.dll,-3	After restoring the folder and its desktop.ini, a fresh process returned the configured SHELL32.dll,43 resource
Newly created harmless .ps1 containing only Write-Output 'ASSOCIATION_PROBE_OK'	Direct powershell.exe -NoProfile -NonInteractive -File ... failed with an unsigned-script error; exit code 1	The same command and script succeeded, printed the marker, and exited 0

For the shortcut and script tests, only the test file's integrity label was changed. The script test did not change execution policy, use -ExecutionPolicy Bypass, or change file associations. This independently confirms an execution-policy symptom in addition to the icon problem described above.

Recovery and validation

Earlier icon-cache rebuilds did not fix the problem. After backing up the relevant settings, recovery consisted of restoring the affected root's inheritable label:

icacls "$env:USERPROFILE\Desktop" /setintegritylevel '(OI)(CI)M'

We verified Medium inheritance on the original desktop items. Shell API queries then returned the correct icons. Explorer still held stale display state, so an Explorer restart was needed for the shortcut icons; reapplying the four original folder icon settings via SHGetSetFolderCustomSettings cleared their remaining stale presentation. The final desktop view showed the application icons and all four original custom folder icons correctly. Existing ordinary DACL entries were not reset.

This is a recovery procedure after the affected sandbox session, not a proposed way to disable sandbox protections. A future session that labels the workspace Low again could recreate the problem.

Attribution and scope

The Low-label cause is confirmed locally. Its origin in Harness sandbox initialization matches the session timing and this discussion, but we did not capture the process that last wrote the label or perform a new clean-install Harness reproduction. No explicit integrity-label modification command was found in the inspected model tool calls. A separate .ps1 default-application preference was also adjusted during recovery; I am not claiming that changing the default application to Notepad was caused by Harness.

Please investigate preserving/restoring workspace integrity labels as part of the sandbox lifecycle, including inherited labels on pre-existing user files. Regression coverage should include Explorer shortcut icons, desktop.ini folder icons, newly copied files, and unsigned local scripts under RemoteSigned, particularly when a Windows known folder is selected as the workspace.

中文补充：本机已用单变量实验确认，桌面的可继承 Low 标签不仅导致快捷方式白图标和文件夹自定义图标丢失，还会使新建的无害 PowerShell 脚本在 RemoteSigned 策略下报未签名。只把测试脚本改为 Medium，执行即恢复正常，无需降低执行策略。