Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Keep earlier versions of office files, so a team member's mistake on a real file can be undone

Open
  • Is something wrong?
#44 1 comment 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@agentvivekkumar is already working on this.

Since Oct 8, 2026.

Assessment

This issue has not been assessed yet.

Description

enhancement Require Customer
Problem / motivation

Team members change the owner's real files, and nothing can bring back what a file held before.

  • The owner's files and the team's work share the same folders. The business folder is the office's filing cabinet: the owner keeps the client list, price sheet and budget there, and each team member writes freely inside its own folder (src/shared/folderAccess.ts).
  • One bad write is permanent. If Kelly saves a shortened client list over the full one, Oscar's script rewrites last year's figures in Budget 2026.xlsx, or a cleanup deletes the wrong file, the earlier version is gone. Most owners don't run Time Machine or File History, and even when they do, it runs hourly and can't say which team member made the change.
  • Word and Excel files are mostly changed from the shell. Claude's text file tools can't write .docx or .xlsx, so team members change them with scripts. The harness guard already notes that a shell write "can't be judged from its text" (src/main/harnessGuard.ts). On Windows, shell commands aren't held to the agent's folder at all yet.
  • Mail already has this promise; files don't. "Archiving, marking read and marking junk never delete anything." Files are where an owner's most valuable work lives, and they get no such guarantee.

This doesn't wait on a customer request. Every office writes to real files today. The first lost file is when an owner stops trusting the team with their work.

Proposed solution

File history: before a team member changes a file in the office, the app keeps the version that was there. The owner can see what changed and put any file back in one click. Everything stays local and needs no new dependency (node:fs and node:crypto).

1. Keep the version from before each change

  • Claude's file tools (Write, Edit, MultiEdit, NotebookEdit): the PreToolUse hook already sees every one of these before it runs (src/main/hooks.ts, beside harnessWriteDecision). When the target is inside the office, the app copies the current file into the history first, then lets the call go through. This gives an exact "before" for every edit.
  • Shell commands (Bash, PowerShell): before each command, the app makes a quick incremental pass over that team member's own folder. It saves any file whose size or modified time differs from its last saved version. Only changed files are copied, so after the first pass this costs a folder scan plus the files the owner or the team changed since. Scripted Office edits and deletes are then covered too, and this works on Windows where the shell isn't sandboxed.
  • Michael's own files in the business folder are covered the same way. Michael can't write to team folders, so there is nothing more to cover there.

2. Store it safely

  • A content-addressed store in the app's data folder (beside harness.db), named by SHA-256, so an unchanged file is stored once however many times it's saved. Records (path, agent, tool, time, hash) go in harness.db.
  • The store is outside every agent's folder: the sandbox and the file tool guard deny writes to it, so a team member can't change or erase the history.
  • Limits the owner can see in Settings: skip files over 100 MB; keep 30 days; cap total size (default 5 GB) by pruning the oldest first. Always keep each file's most recent earlier version for at least 7 days. Settings shows how much space the history uses.

3. Let the owner see and restore

  • "Files changed" on each team member's panel: each file with Changed, Added or Deleted, when, and Open or Show in folder. Text files show what changed; Word, Excel and PDF show size and time.
  • Earlier versions → Restore. Restoring saves the current file first, so a restore can also be undone. Restore is an owner-only action in the app, never an agent tool.
  • Owner-facing text follows the repo's rules: plain words, no dashes, {{godName}}, and translated.

Plan: three PRs, one change each

  1. The history store and the pre-change copy for Claude's file tools, as pure helpers with node:test cases: dedupe, size cap, pruning, paths with spaces, case-insensitive file systems, and a target outside the office (ignored).
  2. The incremental pass before shell commands, with tests for an added, changed and deleted file, and a check that an unchanged folder copies nothing.
  3. Files changed and Restore in the panel, with a test that restoring keeps the current version first.

I'd like to start with PR 1 from my fork. It's self-contained, adds no dependency, and protects every edit made with Claude's file tools straight away.

Screenshot, mockup or recording

The Work tab shows what Kelly did, but not which files she changed, and there is no way back if one of them was wrong.

Image
Alternatives considered
  • Claude Code's own checkpoints. They cover only Claude's file tool edits, not shell changes or deletes. They live inside one session's terminal, and the owner never uses that terminal.
  • Git in the business folder. Git struggles with large binary Office files, puts a .git folder in the owner's own documents, and would need the agents kept away from it. The repo also turns git views off for business owners.
  • The OS backup (Time Machine, Windows File History, OneDrive). Often off, runs hourly at best, and can't say which team member changed what. File history adds to it rather than replacing it.
  • Asking the owner before every write. Safe, but it stops the office for every save. Keeping the earlier version makes every change undoable without slowing the team down.
Area

Office floor / avatars

Pre-flight
  • I attached a screenshot, mockup or recording above.
  • I searched existing issues and discussions, and this isn't a duplicate.
Dominant language
TypeScript
Stars
273
Forks
211
Avg merge
10h 3m
Merged PRs (30d)
136

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from agentvivekkumar/dontbemichael

All issues in agentvivekkumar/dontbemichael

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.