Windrecorder: a local screen memory search engine for Windows
Windrecorder is a memory search app by records everything on your screen in small size, to let you rewind what you have seen, query through OCR text or image description, and get activity statistics, like Microsoft's Windows Recall or Rewind.
At a glance
- What is it?
- Windrecorder records your screen in small files, indexes only the scenes that change, and lets you query the result through OCR text or image descriptions. It is Windows-only, GPL-2.0, and built around ffmpeg, SQLite and a Streamlit web UI.
- Who is it for?
- Adopt Windrecorder if you work on Windows, want a local Rewind or Recall style memory aid, and are comfortable with a Git clone plus install_update.bat workflow. Skip it if you need macOS or Linux support, or if you want a packaged installer and a stable release channel.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 28, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Windrecorder is for, and who it is not for
Windrecorder is a personal memory search engine for Windows. The README describes it as a screen recorder that stores what you have seen in small files, then lets you rewind, query OCR text or image descriptions, and pull activity statistics. The comparison it draws is explicit: Microsoft's Windows Recall and Rewind. The difference is that all capabilities run locally, with no internet connection and no upload, and the README states that you own all your data.
The audience is narrow but well defined. You need a Windows machine, you need to be willing to run a Python application from a cloned repository, and you need to accept that recording runs continuously in the background. The README recommends placing the install in a partition with sufficient space, which tells you the storage profile is not trivial even though the file sizes are described as small.
If you are looking for a cross-platform tool, this is the wrong project. The dependency list in pyproject.toml pins pywin32 and uiautomation behind sys_platform == 'win32', and the uv environment is declared as sys_platform == 'win32' and platform_machine == 'AMD64'. There is no macOS or Linux path in what the repository documents.
How the recording and indexing pipeline works
The README describes two recording modes, and the choice changes the latency of everything downstream.
Automatic Flexible Screenshots takes a screenshot every 3 seconds by default. Screenshots are indexed when content or text changes, which is what makes real-time rewind possible. Every 15 minutes, past screenshots are converted into video. The README calls this mode low on system resources and suitable for users who need to store, rewind and search memory cues.
Direct Video Recording via FFmpeg records video in 15-minute segments and indexes the clips after recording completes. The README notes there may be a 15-minute delay in data querying, and calls this mode moderate on system resources while enabling smooth and complete recording.
Both modes share an idle-maintenance loop. When the screen is static, when window titles or screen content match an exclusion list, or when the computer is locked, recording pauses and the app compresses and cleans videos and runs image recognition embedding. The README frames this as automatic, and the best-practice tip is to set Run on system startup in the webui and let it run.
Only changed scenes are indexed, and the database receives OCR text, page title, browser URL and similar fields. The web UI is Streamlit, which is consistent with the streamlit dependency and the .streamlit/ directory at the repository root. Storage is split between video files and a SQLite database, both under userdata.
Installing Windrecorder and recording your first screen
The README gives a manual install path rather than a packaged installer. You need ffmpeg, Git and uv before you clone anything.
Download the FFmpeg build named ffmpeg-master-latest-win64-gpl-shared.zip, then extract the files inside its bin directory (not the bin directory itself) into C:\Windows\System32 or another directory on PATH. Install Git, then install uv. The README states the uv installer manages Python 3.12 automatically, so a separate Python installation is not required. Existing Python or Poetry users can keep their installation and run the updater directly.
Pick the directory where you want Windrecorder to live, then clone it:
git clone https://github.com/yuka-friends/WindrecorderOpen install_update.bat to install and configure the app. When that finishes, start it with start_app.bat. The app runs in the system tray and is used through the right-click menu.
If you want the AI agent path instead of the tray menu, the README points to __assets__/how_to_use_memory_skill.md for memory skill installation and usage, written in Simplified Chinese. Image embedding is not installed by default; the README says it is provided as an extension under extension/install_img_embedding_module. Third-party OCR engines are optional extras in pyproject.toml: rapidocr, wechat and embedding.
All data, including video, database and statistics, lands in the userdata directory under Windrecorder. If you move the app to another computer, the README says to delete .venv in the directory, move it, then re-run install_update.bat to rebuild the virtual environment.
Where Windrecorder breaks down
The most concrete limitation is the query delay in FFmpeg mode. Because clips are indexed after each 15-minute segment completes, a search will not see the last quarter hour. If you are trying to find something you saw two minutes ago, that mode is the wrong configuration. Screenshot mode indexes on change, which the README presents as the real-time option.
The second limitation is the update path. The README warns that if automatic updates fail, you should close Windrecorder, open cmd in the repository root, run git pull --ff-only, then reopen install_update.bat, and it points to docs/upgrading.md if Git reports a conflict. That is a Git-based upgrade, not a package manager. Anyone who has edited files in the working tree will hit the conflict case.
The third is scope. The exclusion list works by window title, process name, included text or screen still time, which means sensitive windows are handled by matching rules rather than by a per-application privacy model. If your work involves material you cannot have captured at all, the safe answer is to not run continuous capture on that machine.
The fourth is the release situation. The repository shows no retrieved releases, pyproject.toml still carries version 0.1.0, and the README has a coming soon line pointing at pull requests. Treat the project as one that tracks main rather than one with a versioned support policy. The last push was on 2026-09-25, so the codebase is being changed, but a 0.1.0 version string and a Git pull updater are the practical facts that matter when you plan an upgrade window.
Windrecorder compared with Rewind and Windows Recall
Rewind is the macOS app the README names as the thing Windrecorder is an alternative to, and Windows Recall is the built-in Microsoft feature it also positions against. The difference is not the feature list. It is where the data lives and what you have to do to get the tool.
Rewind is a commercial product on macOS. Windrecorder is GPL-2.0 and Windows only. If your machine is a Mac, the comparison ends there, because the dependency markers exclude anything but Windows AMD64.
Windows Recall ships with the operating system. Windrecorder does not; you clone a repository, install ffmpeg, Git and uv, and run a batch file. In exchange, the README states everything runs locally with no internet connection and no upload, and that the OCR engine is swappable. The built-in Windows recognition is one option, and Rapid OCR, WeChat OCR and Tesseract OCR are documented alternatives, with a linked performance test reference in __assets__. Tesseract is the one that supports more than 100 languages and can recognize several at once, which matters if your screen content is not English or Chinese.
So the real trade is packaging and platform support against control over the pipeline. Windrecorder gives you the OCR engine choice and a local SQLite database you can inspect. It does not give you a signed installer or a support contract.
Licence and the cost of keeping it running
Windrecorder is GPL-2.0, declared both in the repository metadata and in pyproject.toml under license = "GPL-2.0". For individual use that is unremarkable. If you plan to embed it in a product, or to ship a modified version to customers, the copyleft terms apply to the distributed work, and you should read the licence text rather than rely on a summary. Nothing here is legal advice.
The dependency list mixes permissive licences with GPL components, and the optional OCR extras bring their own terms: rapidocr-onnxruntime, wechat-ocr and the uform onnx embedding package are separate distributions. If you enable them, check each one.
Upgrade cost is the more immediate concern. Because the updater is git pull --ff-only plus install_update.bat, an upgrade is a working-tree operation. Local edits, including tweaks to the Streamlit pages or the exclusion logic, can block it. The README's recovery path is docs/upgrading.md. Budget for that: a machine that records continuously and then fails to update is a machine that keeps writing to userdata while you debug the repository.
Storage cost is not fixed by the README. It describes file sizes as small and recommends a partition with sufficient space, and the idle maintenance compresses and cleans expired videos, but no retention default is documented. Verify what your own capture rate produces before you rely on the cleanup.
Choosing between the two recording modes
This is the decision that shapes everything else, and the README does not make it for you.
Pick Automatic Flexible Screenshots when you want to search what you just saw. Indexing happens on content change, so new material appears in queries without a fixed wait. The cost is that you get reconstructed video rather than a continuous stream, assembled from screenshots every 15 minutes, and the README describes this as the low-resource option.
Pick Direct Video Recording via FFmpeg when you want a complete, smooth record of activity and can tolerate up to 15 minutes of query lag. This is the mode for archival review rather than live recall.
Neither mode records through a locked screen or a static screen, and both honor the exclusion list. If your goal is a searchable memory aid, the screenshot mode matches the stated purpose. If your goal is a faithful activity record for later review, the FFmpeg mode does, at the price of the delay the README itself flags.
Editorial conclusion
Adopt Windrecorder if you work on Windows, want a local Rewind or Recall style memory aid, and are comfortable with a Git clone plus install_update.bat workflow. Skip it if you need macOS or Linux support, or if you want a packaged installer and a stable release channel. Before committing, verify that ffmpeg is on PATH, that the drive holding userdata has room for continuous capture, and that the recording mode you pick matches how quickly you expect to query new footage.
Frequently asked questions
Does Windrecorder work on macOS or Linux?
No. The uv environment in pyproject.toml is declared as sys_platform == 'win32' and platform_machine == 'AMD64', and pywin32 and uiautomation are Windows-only dependencies. The README describes it as a Windows tool throughout.
Where does Windrecorder store my recordings and database?
All data, including video, database and statistics, is stored in the userdata directory under Windrecorder. The README says you can move the app by deleting .venv, moving the directory, and re-running install_update.bat.
How do I upgrade Windrecorder if the automatic update fails?
The README says to close Windrecorder, open cmd in the Windrecorder root directory, run git pull --ff-only, then reopen install_update.bat. If Git reports a conflict, it points to docs/upgrading.md.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/yuka-friends-windrecorder)