A history that helps you find an item needs some context about the item. That often means a filename or path, application, file type, and time. A privacy-conscious design should explain where that context is kept and whether it leaves the device.
Recent-item signals are not a disk-wide catalog
Windows and applications may expose recent documents through Recent Items, jump lists, or app-specific lists. A tool using those sources is different from crawling every directory to build an index of all files. The sources are also limited: if Windows or an app does not expose an item, a history app may not be able to show it.
How this app handles its own history
What Was I Working On? stores its history locally in encrypted app storage. It uses SQLCipher-based database encryption and protects the database key with Windows DPAPI. Its core functions do not require a sign-in, cloud sync, or an internet connection, and file-history data is not uploaded by the app.
Encryption helps protect saved data at rest; it is not a promise that information is inaccessible to all software running under an already-unlocked Windows account. Device security and account access still matter.
Controls you can use
- Pause tracking: stop adding new entries while keeping existing saved history.
- Set retention: choose how long the app keeps its own history.
- Clear the app history: remove entries held by the app.
- Request a recovery scan only when needed: scans check known locations for supported apps.
Windows and application lists are separate
Clearing or pausing this app does not also clear the recent-document lists maintained by File Explorer, Word, or other apps. Those lists have their own controls. If you share a device, review the settings for each account and application that matters to you.