我艹，我让他写个插件，他把我dsh目录给清了，zcode也清了....

[wlfzsd]

我就是说“帮我写个dsh插件，在左上角的新建会话下面加一个今天的token使用统计，统计所有渠道的”
然后。。。。。会话打不开了，我重启dsh所有会话全丢了！zcode的所有会话也全丢了。我tm真服了

[wlfzsd]

我他妈真的太想骂人了啊 他把我magpie也全清了，我里面几十个账号啊，我艹 我现在都不知道他还清了什么

[WorthIts]

兄弟，赶紧装个其他的agent ，别把现场丢了，你让它好好分析一下

[wlfzsd]

全没了，什么都没了。。。他把D://Users\Administrator 目录下大量用户文件都删除了，不删文件夹，但是内部文件几乎全清了。只要是用户数据，就给我清楚，我真他妈服了。

[WorthIts]

他那个完全权限权限太大了，，预览版不能给这么大权限，太吓人了

[wlfzsd]

他那个完全权限权限太大了，，预览版不能给这么大权限，太吓人了

不给完整权限是没法干活的。想让他连续干几个小时，就必须给完整权限，不然他会频繁暂停。ai出错我能理解，但是作为最后一道防线的agent工具得针对这种情况有防御机制啊，至少官方应该出插件拦截某些特殊情况

[rereareal]

看来我把pi丢在容器里面跑是对的，不过pi有点不顺手了，还是搓一个带权限管控的框架吧

[wlfzsd]

看来我把pi丢在容器里面跑是对的，不过pi有点不顺手了，还是搓一个带权限管控的框架吧

我一直给的是 完全权限 ，以前即便遇到问题，也没这次这么严重。

[XuZhangxing]

我全局搜了一下，这个@zxcompany311-svg兄弟更狠，#11906 整个D盘没了，完全权限要慎重一点，里面有人说有可能是模型判断失误

[wlfzsd]

我全局搜了一下，这个@zxcompany311-svg兄弟更狠，#11906 整个D盘没了，完全权限要慎重一点，里面有人说有可能是模型判断失误

我去看了，应该我也是这个问题。我总体还算运气好，没删我源码，真是谢天谢地了

[MangoIsIllegal]

真这么吓人？用的什么模型啊 这么夸张？

[kangtsang]

这个坑我早就踩过了 而且给了解决方案和官方提议 具体可以参考一下排查原因看看
#8537

[WorthIts]

社区里都是狠人啊，窝都被端了，都一用一个不吱声

[wlfzsd]

社区里都是狠人啊，窝都被端了，都一用一个不吱声
主要是碰到这个问题的人很少，我前些日子看到有人说清盘了，但是我从dsh第一个版本一直 完全权限 用到现在，第一次遇到，就差点给我一窝端了。系统环境被破坏了，很多软件也坏了，很多账号也丢了。好在脚本没删我的，要是删我脚本，我人得彻底崩溃

[ViCrack]

windows powershell太容易有坑了，而且你还开了完全权限，常在河边走

[kangtsang]

这个误删的问题严格来说不是dsh的问题 是写的powershell脚本撞上了windows保留的变量命名无法复制自动回落成系统默认值导致连锁删除，这个只能在全局的AGENTS.MD 去加约束，但是也是没办法根治的，有时AGENTS.MD的规则围栏会被忽略，只能尽量降低发生这类事故的风险，以下是我的围栏规则：

5. 事故与教训要如实记账

• 我曾经因为 $home（PowerShell 只读自动变量，赋值静默失败）加上无防护的 Remove-Item -Recurse -Force，删掉过整个用户目录。
• 脚本的命名尽量不要和预留的命名重复，一律避开、走最安全的路线。 变量、函数、参数都算；不要靠记忆去分辨哪个预留名能不能用 —— 实测给只读的赋值会报 WriteError 却不中断脚本，变量保持原值，后续拿它拼出的路径会静默指到别处。下面两份清单只用来事后复核，不是「这些名字可以用」的许可：
  • 只读（赋值报错；PowerShell 7.6.6 实测，5.1 抽查一致）：$home、$host、$pid、$error、$shellid、$true、$false、$?、$PSHome、$PSEdition、$PSCulture、$PSUICulture、$IsWindows、$IsLinux、$IsMacOS、$IsCoreCLR、$ExecutionContext、$PSCmdlet、$PSBoundParameters、$PSVersionTable、$MyInvocation
  • 可写（赋值正常）：$pwd、$profile、$args、$null、$psitem、$_、$input、$matches、$LASTEXITCODE、$PSScriptRoot、$PSCommandPath、$StackTrace、$NestedPromptLevel、$^
  • 没测准的（只在自带容器里才成立，例如 $foreach/$switch/$this 分别只在 foreach / switch / class 内）：$foreach、$switch、$this、$PSDebugContext、$Event、$EventArgs、$EventSubscriber、$Sender、$ConsoleFileName
• 写任何涉及删除、清理、重置的脚本前：路径逐级验证、只删白名单下的直接子项、避开 Remove-Item 对 reparse point 的跟随、绝不把变量插值路径直接喂给递归删除。
• 这类教训要在文档和脚本注释里留痕，不只是嘴上说。

[wlfzsd]

这个误删的问题严格来说不是dsh的问题 是写的powershell脚本撞上了windows保留的变量命名无法复制自动回落成系统默认值导致连锁删除，这个只能在全局的AGENTS.MD 去加约束，但是也是没办法根治的，有时AGENTS.MD的规则围栏会被忽略，只能尽量降低发生这类事故的风险，以下是我的围栏规则：

5. 事故与教训要如实记账

• 我曾经因为 $home（PowerShell 只读自动变量，赋值静默失败）加上无防护的 Remove-Item -Recurse -Force，删掉过整个用户目录。

• 脚本的命名尽量不要和预留的命名重复，一律避开、走最安全的路线。 变量、函数、参数都算；不要靠记忆去分辨哪个预留名能不能用 —— 实测给只读的赋值会报 WriteError 却不中断脚本，变量保持原值，后续拿它拼出的路径会静默指到别处。下面两份清单只用来事后复核，不是「这些名字可以用」的许可：

  • 只读（赋值报错；PowerShell 7.6.6 实测，5.1 抽查一致）：$home、$host、$pid、$error、$shellid、$true、$false、$?、$PSHome、$PSEdition、$PSCulture、$PSUICulture、$IsWindows、$IsLinux、$IsMacOS、$IsCoreCLR、$ExecutionContext、$PSCmdlet、$PSBoundParameters、$PSVersionTable、$MyInvocation
  • 可写（赋值正常）：$pwd、$profile、$args、$null、$psitem、$_、$input、$matches、$LASTEXITCODE、$PSScriptRoot、$PSCommandPath、$StackTrace、$NestedPromptLevel、$^
  • 没测准的（只在自带容器里才成立，例如 $foreach/$switch/$this 分别只在 foreach / switch / class 内）：$foreach、$switch、$this、$PSDebugContext、$Event、$EventArgs、$EventSubscriber、$Sender、$ConsoleFileName

• 写任何涉及删除、清理、重置的脚本前：路径逐级验证、只删白名单下的直接子项、避开 Remove-Item 对 reparse point 的跟随、绝不把变量插值路径直接喂给递归删除。

• 这类教训要在文档和脚本注释里留痕，不只是嘴上说。

AGENTS规则有点难，他那个上下文一大，注意力缺失有失效的风险。严格来说就是deepseek和dsh的问题，deepseek执行命令写错了，dsh又没有拦截机制。 不开 完全权限 根本干不了活，几分钟一个问题，大活完全无法自动执行

[ame-code]

与其说完全权限给的太多不如说仅工作区权限给的太少，让AI干点啥都给拦下来了，感觉不开完全权限基本残废问题更大

[ViCrack]

加约束治标不治本，脚本非常灵活，甚至随便一个文件重定向，解压缩等等场景都会把数据干没
只有从系统权限入手才是合理

就是目前的工作区修改权限太拉了，审核太多就会让人想开完全权限

[kangtsang]

这个事情真的很无语 目前的状况下肯定还会有源源不断的受害者出现 没办法根治这个问题 一个月前就踩过这个坑发帖了 反正现在是没招了 我也在想有没有什么办法能杜绝这个乱删文件的问题

[21364]

以下四条，四选一就能解决90%的问题，四条全上基本上就没有什么隐患了。
1.有非常多的成熟插件可以解决这个问题，比如【cc-safety-net】，实测有效拦截大部分高危指令，但需要补充一点自定义规则，具体哪些让你AI找个安全环境测试一下给你补上就行；
2.把windows默认的powershell5.1升级到7，让AI默认用7，也可以避免；
3.开个硬盘卷影作为回滚备份，只用硬盘5-10%空间就够了；
4.你可以手工设置删除规则，告诉AI禁止使用删除相关指令，转而将需要删除的文件移动入特定文件夹如.trash，然后定期手动删除，也可以避免悲剧，还可以叠加非完全权限，因为只是移动文件不会触发审批。

[Big-Dao]

根据我这两年Coding Agent编程的切身体感，LLM无论是在powershell上还是CMD的表现要远远差过linux下posix shell工具链，而且有些错误相当低级，用起来百感交集。毕竟，用来训练LLM的开源代码库使用posix shell工具链的数量不知道要比powershell/CMD高出几个数量级，LLM在斜杠、反斜杠......各类差异上颇费心智。

微软在纳德拉接手后没多久，就拥抱Linux，推出了WSL，开发体验相当良好，这些年来，我都是优先在WSL下干活。

在deepseek harness for windows发布后，dsh拥有了windows原生应用的流畅和便利，但是官方没找到类似VS Code的Remote-WSL扩展的WSL插件，如果想用posix shell工具链，就只能在web ui下用，但是浏览器中的web app受到的限制太多了。于是搓了插件，为了安全，还特意支持了沙箱，以尽量避免倾巢之祸。

朋友们可以试用一下。插件初启，还有非常多问题，欢迎任意意见和建议。

#11251
https://github.com/Big-Dao/dsh-plugin-wsl-env

[kangtsang]

现在都是AI开发了 我都有点想转到Linux平台去了 Windows 反斜杠真的是太反人类了 历史债太多了屎山一座 现在有了agent切到Linux平台真的是一个很好的契机 当然预算充裕的话也可以直接御三家

[XuZhangxing]

点赞，越来越硬核了，不过harness是兜底大模型的，没想到社区还要持续兜底harness

[Big-Dao]

我也有想法弄一台机器彻底原生linux，平时使用的应用程序几乎100%有linux版本。只是windows的保有量太大，做出来的东西总要在windows上跑一下才行，很难割掉。

[axetroy]

这个本质上和 DSH 关系不大。

CMD/PowerShell/LLM，三者其一的锅。

LLM 要足够强，保证生成没有那么多问题的脚本。

CMD/PowerShell 太难用了，LLM 通常生成一串 99% 的人都读不懂的脚本。

当然 DSH 也可以学下 copilot 增加一个 autopilot 模式。超出工作区外的权限，可以用 LLM 去自动审批，增加点成本

[kangtsang]

现在不是有一个实验室自动审批权限的官方插件了 我之前试过了 也是老撞墙 现在也基本都是完全权限运行的状态。平时做开发改代码没什么问题，只有在让agent自己写脚本删文件才是高风险的事情，所以我加了AGENTS全局规则在删除文件前必须获取我的同意才执行，基本上不会在中途直接删，而是在完成任务后把待删除的中间文件列出来问由人决定后才删。

[21364]

盲猜又是AI大战powershell导致的。
1.早就有非常多的成熟插件可以解决这个问题，比如【cc-safety-net】，你没有装；
2.你可以把windows默认的powershell5.1升级到7，让AI用7，就可以避免这次悲剧，你没有升级；
3.你可以麻烦一点，别给完全权限，给自动审批/手动审批，你没有给；
4.你可以开个硬盘卷影作为回滚备份，只用你硬盘5-10%空间就够了，你没有开；
5.你的需求早就有插件完成，你可以不用自己重复造轮子，直接用现成的，一样可以避免这次悲剧；
6.你可以手工设置删除规则，告诉AI禁止使用删除相关指令，转而将需要删除的文件移动入特定文件夹入.trash，然后定期手动删除，也可以避免悲剧，还可以叠加非完全权限，因为只是移动文件不会触发审批。你也没跟AI说。
综上所述，你有至少6次机会避免悲剧，但每一次都被你亲手放过，那只能说，就算不信命，你也算是合该有这一劫了。

[wlfzsd]

盲猜又是AI大战powershell导致的。 1.早就有非常多的成熟插件可以解决这个问题，比如【cc-safety-net】，你没有装； 2.你可以把windows默认的powershell5.1升级到7，让AI用7，就可以避免这次悲剧，你没有升级； 3.你可以麻烦一点，别给完全权限，给自动审批/手动审批，你没有给； 4.你可以开个硬盘卷影作为回滚备份，只用你硬盘5-10%空间就够了，你没有开； 5.你的需求早就有插件完成，你可以不用自己重复造轮子，直接用现成的，一样可以避免这次悲剧； 6.你可以手工设置删除规则，告诉AI禁止使用删除相关指令，转而将需要删除的文件移动入特定文件夹入.trash，然后定期手动删除，也可以避免悲剧，还可以叠加非完全权限，因为只是移动文件不会触发审批。你也没跟AI说。 综上所述，你有至少6次机会避免悲剧，但每一次都被你亲手放过，那只能说，就算不信命，你也算是合该有这一劫了。

1.我默认使用的pwsh7
2.手动审批给小白用的，你见谁一个活干几个小时，要不停盯着给审核
3.我agents.md有明确删除规则，他有自己的项目垃圾箱，之前一直正常执行
4.你默认我就应该知道cc-safety-net，我就应该安装，所以使用前我就应该装好你认为所有有用的插件。 如果他这么有用，官方为什么不直接内化，还要我去想到并安装

综上所述，如果deepseek在生成此类删除指令的时候再慎重一点，dsh如果内置有兜底插件，也不至于说产生这种悲剧。gpt和cc以前也能从网上找到这种清盘案例，但是他们如果也是把这种概率降到最低了，但是显然dsh没有注意到这个问题，或者把该问题的优先级排在后面了，毕竟概率不大

[kangtsang]

#12846 又有新的受害者了出现了 这个案例更惨 都不敢想像损失有多大 要是没有远端仓库备份源码的话只能瘫坐了

[wlfzsd]

#12846 又有新的受害者了出现了 这个案例更惨 都不敢想像损失有多大 要是没有远端仓库备份源码的话只能瘫坐了
dsh就应该内置一个高风险识别拦截的插件，这个bug就是出现概率极度，风险度极高。

[tiexo]

跟我上次一模一样，我还以为是magpie更新导致的....

[wlfzsd]

跟我上次一模一样，我还以为是magpie更新导致的....

你是某个应用出现数据丢失了，还是全部的应用目录。 我一开始以为只是清的我dsh目录，后来发现用户应用的数据目录所有子文件全被他清除了。很多软件需要重装，系统应用也遭到了破坏