Skip to content

fix(web+server): protect encrypted vault dirs from recursive delete#14

Open
Mingholy wants to merge 3 commits into
simpx:mainfrom
Mingholy:fix/vault-delete-guard
Open

fix(web+server): protect encrypted vault dirs from recursive delete#14
Mingholy wants to merge 3 commits into
simpx:mainfrom
Mingholy:fix/vault-delete-guard

Conversation

@Mingholy

@Mingholy Mingholy commented Jun 7, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Vault tree API's delete handler uses rm -rf for all directories — an encrypted vault subtree could be wiped by a single API call
  • Server fix: encrypted vault paths (personal vault under .loopat/vaults/) now use rmdir (non-recursive) — only empty dirs succeed; non-empty raises ENOTEMPTY
  • UI fix: hide "Delete" action on non-empty encrypted vault directories so users don't go through a pointless click → confirm → error dance

Test plan

  • Right-click non-empty .loopat/vaults/default/ → no Delete option
  • Right-click empty vault subdir → Delete succeeds
  • API call to delete non-empty encrypted dir → 400 "directory not empty"

🤖 Generated with Claude Code

Mingholy and others added 3 commits June 7, 2026 19:12
- isSecretsFolder: match server logic by including `.loopat/vaults` itself
  (not just children), so UI and server agree on what's protected
- HTTP 400 for delete validation errors (was 500, triggering false 5xx alerts)
- FileTree.tsx: update getContextActions signature to match Tree.tsx 2-arg form
- Accurate TOCTOU comment: UI emptiness check is a stale-state hint, server
  rmdir is the authoritative guard

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant