DSH: .zshrc and ~/.vim/ recursively deleted from $HOME on macOS

[atlasloewenherz]

Suggested issue title: DSH: .zshrc and ~/.vim/ recursively deleted from $HOME on macOS

---

Summary

While working on macOS, I found that ~/.zshrc and the entire ~/.vim/ directory (recursively) had disappeared from my home directory, with no action taken by me to remove them. This happened a first time (silently, noticed only when my shell lost its oh-my-zsh config and prompt), and then a second time while working inside the deepseek-harness repo checked out at tag dsh-v0.2.2-rc.1 (➜ deepseek-harness git:(dsh-v0.2.2-rc.1)). The second time I had backups, so damage was limited, but the recurrence is what prompted this report — this does not look like a one-off fluke.

This looks like the same class of bug already reported for DSH on Windows (recursive deletion of the real user home via a $home/$HOME PowerShell variable collision — see Related reports below), but observed here on macOS/zsh, where that specific case-insensitivity mechanism doesn't apply. That suggests the underlying issue may be broader than a PowerShell-only quirk.

What was observed

• ~/.zshrc did not exist. oh-my-zsh (~/.oh-my-zsh) was still installed and intact, but never got sourced since the file referencing it was gone. No crash, no error shown at the time — it was just silently absent.
• ~/.vim/ (the whole directory, not just a file) was gone, including ~/.vim/bundle/Vundle.vim and all plugins declared in ~/.vimrc. ~/.vimrc itself (a plain file directly in $HOME) survived both times — only the directory tree under it was wiped.
• Both incidents affected only these two paths. Everything else in $HOME was untouched: .ssh, .gitconfig, .config, .docker, .kube, all project directories, shell history, etc. all remained intact. This is a selective/scoped deletion, not a blanket rm -rf $HOME.
• No content could be recovered: no Time Machine configured on this Mac (zero destinations, zero local snapshots), no copy in ~/.Trash, no third-party backup tool installed.

Investigation performed (and what it ruled out)

• macOS unified log, 14-day window, predicate on zshrc → zero hits. No OS-level record of the deletion.
• No cron job, no suspicious launchd agent, no dotfile manager (chezmoi/yadm/stow/mackup) present that could explain it.
• No sync service (iCloud Drive Desktop&Documents, Dropbox, Syncthing) touches $HOME dotfiles on this machine.
• Checked DSH's own local session logs (~/.dsh/sessions/*/session-*.v4.jsonl.zstd, decompressed and inspected). Only two sessions exist locally, both created the same day I was investigating this — ~/.dsh (the session/log store itself) has a fresh creation timestamp from that day. Both logged sessions contain only read-only commands (ls, grep, cat, sed, find against DSH's own repo and ~/.dsh) — no rm -rf, no destructive call, nothing touching .zshrc or .vim.
• Importantly, this is not the same as DSH's whole install being fresh: the actual long-lived project workspace (~/Documents/deepseek-harness/default-workspace/) has been in continuous, undisturbed use since Nov 8 — daily automated scraper output (one JSON/CSV/report set per day, Nov 3 through Nov 11) sitting there untouched. So specifically ~/.dsh's session/log store got reset/recreated at some point, while the real workspace content was not touched. I inspected every script living in that workspace (install.sh, install_memoris_preset.sh, patch_global_opencode.py, germany_new_companies.py) — all are benign (config patchers that write timestamped .bak backups before any change, or a scraper with no filesystem cleanup logic at all). None reference .zshrc, .vim, rm -rf, or any path that could fall back to $HOME.
• Net effect: the locally retained client-side session logs don't go back far enough to cover whatever session actually caused the deletion — that history is gone along with (or because of) the ~/.dsh store reset. This does not clear DSH of the issue; it just means I have no further forensic trail to hand you from this machine.

So: I cannot show you an exact command the way the Windows reporter could (they had a retained PowerShell stderr log). I also can't be 100% certain of timing. What I can say with confidence: the deletion scope (two specific dotfile paths directly under $HOME, nothing else) recurred identically on a second occasion, on the same OS, while DSH was in active use on this machine.

Related reports

I'm aware of and cross-referencing a related report:

• A Windows incident describing DSH running a CI/npm troubleshooting task that ended up executing (paraphrased from retained stderr): if (Test-Path $home) { Remove-Item $home -Recurse -Force }; New-Item -ItemType Directory $home | Out-Null — attributed to a likely $home/$HOME PowerShell automatic-variable collision (PowerShell variable names are case-insensitive, so an attempt to repurpose $home as a scratch/workspace variable can silently collide with the real, read-only $HOME).
• That report references prior related issues: "DeepSeek 在 DSH 中误用 PowerShell $home，导致对用户主目录发起递归删除" (DeepSeek 在 DSH 中误用 PowerShell `$home`，导致对用户主目录发起递归删除 #9173), "三次误删 .dsh 目录之后" (三次误删 .dsh 目录之后：插件验收 profile 隔离提案，兼一份事故复盘 #8537), "DSH + deepseek-flash 删除了我的用户目录" (DSH + deepseek-flash 删除了我的用户目录！！！ #9468).

This macOS case cannot share the exact PowerShell mechanism (bash/zsh variables are case-sensitive, so there's no $home/$HOME collision possible). If these are related, the shared root cause is more likely upstream of the shell — e.g. in how DSH computes/initializes a temporary or "workspace home" path that falls back to the literal user home directory on some failure path, with the specific paths targeted (.zshrc, .vim/) suggesting this might go through a "reset shell config" / "clean profile" style routine rather than a blanket rm -rf $HOME.

Environment

• OS: macOS (Darwin 25.6.0, arm64)
• Shell: zsh 5.9, oh-my-zsh installed
• Repo/version context of second occurrence: deepseek-harness checked out at tag dsh-v0.2.2-rc.1
• No Time Machine or third-party backup configured (relevant only in that recovery wasn't possible from the OS side)

Requested follow-up

1. Please check server-side/host-side logs (if DSH retains anything beyond the local ~/.dsh/sessions/*.jsonl.zstd client log) covering the actual incident window, since the locally retained session logs here don't go back far enough.
2. Given this is the second time the exact same two paths (.zshrc, .vim/) were the only things removed, it would help to search the codebase for any routine that explicitly deletes/recreates these specific paths (shell config reset, dev-environment bootstrap, "clean slate" setup, etc.), rather than treating this purely as a generic rm -rf $HOME case.
3. Given the Windows report's recommended fixes (deterministic protection on destructive operations targeting user-profile/home paths, resolving the real target path before executing rather than trusting command text, fail-safe behavior when a workspace path fails to initialize, clear reporting after any operation that touches a protected path) — if those land, they should also cover this non-Windows case, since the symptom (unexpected deletion scoped under the real $HOME) is the same even without the PowerShell-specific trigger.

I'm happy to provide additional local artifacts (decompressed session logs, timestamps, etc.) if that helps triage.

[aturzone]

I audited the shipped 0.2.2-rc.2 source for any routine that touches these two paths. The harness does not delete them:

• apps/desktop/src/login-shell-environment.ts:105-179 runs the account login shell once with -ilc to read env -0; it only reads startup files, and sets DISABLE_AUTO_UPDATE / ZSH_TMUX_AUTOSTART* so plugins do not block the probe. Nothing is written.
• packages/subprocess/subprocess-local/src/shell-activity.ts:66 creates its own temporary rc file (bash --rcfile, zsh ZDOTDIR) under mkdtemp(os.tmpdir()) and deletes only that directory (dispose():45, error path :128). It sources the user's .zshenv/.bashrc read-only.
• apps/cli/src/profile-boot.ts:151-172 removes only staging/profile directories under $DSH_HOME/profiles.
• Repo-wide, .vim appears in no code path as a target at all; .zshrc appears only in the read-only login-shell probe, tests, and docs.

So the deletion is not coming from a "reset shell config" routine inside the harness. The repeating shape is much more likely a destructive command executed through a shell/terminal tool (or an external process or third-party plugin) whose target resolved into $HOME. macOS removes the PowerShell $home collision, but the enabling conditions are cross-platform: under danger-full-access the sandbox is bypassed (packages/shell/bash-sandbox/src/index.ts:92), and under the never approval policy every ask is resolved as rejected before dispatch (packages/interaction/user-approval/src/index.ts:301), so a recursive delete has no review step.

Evidence that would actually pin it, cheapest first:

1. ~/.zsh_history / HISTFILE may still hold the command if the deletion came through a terminal you typed into; DSH-recorded shell calls do not enter zsh history.
2. DSH Desktop host logs under ~/Library/Logs/... for the window of both events; those logs outlive the session store.
3. If ~/.dsh was recreated, compare its creation time with the mtimes of $HOME and the surviving dotfiles; that brackets the event even without the deleted session log.
4. stat -x on $HOME; tmutil listlocalsnapshots / even with no backup destination (APFS snapshots can exist); fs_usage/EndpointSecurity only help live.
5. Which sandbox mode and approval policy the DSH window used that day, plus any custom AGENTS.md or third-party plugin that instructs environment cleanup. A task phrased as "reset/clean my shell or vim setup" is the shape that produces exactly ~/.zshrc + ~/.vim/.

On guards: the installable plugin from #9173 (@argszero/dsh-destructive-command-guard) refuses the PowerShell $home and home-root shapes, but it deliberately allows home subpaths, so rm -rf ~/.zshrc ~/.vim passes it. This shape fits the same seam: tools/pre-execute (packages/core/tools/src/pipeline.ts:201) or ctx.tools.guard (packages/core/tools/src/index.ts:384), with PreToolDecision deny/ask (packages/core/tools/src/contracts.ts:377-379). A concrete policy: parse deletion operands for shell/terminal commands; if a recursive delete targets a protected dotfile path (.zshrc, .zprofile, .bashrc, .vim, .ssh, .config, .gitconfig) or resolves to $HOME/a direct-home directory, ask — and under never, deny with an actionable reason instead of the silent rejection; log the resolved argv and cwd. A report-only mode would measure false positives before enforcing. I can implement and test that as an installable plugin on our fork if the team wants a concrete artifact.

Two honest limits: I could not reproduce this on the Linux host that produced this analysis, and the ~/.dsh re-creation is a separate known family (silent profile reset, #9940/#12290); if both happened in the same window they may share one trigger. Cross-references for the class: #9173, #8537, #9468.