I was close to hitting the 15 GB size limit in my Gmail. I started getting those annoying upgrade messages from Google including the warning banner etc. I also did not want to spend my afternoon cleaning up those years of mail. The obvious quick fix is to search, filter and delete a few thousand old emails. It was just too boring and grinding work that I didn’t want to spend my time on. Naturally, I handed the job to my agent instead. Here is a walkthrough of how I went about this. Sharing it here so if you want to replicate it, you can do so easily.
Msgvault
A while back I came across Msgvault, and started using this tool to keep a local copy of my whole Gmail. It pulls every message into a SQLite database on my Mac plus a folder of attachments, and it only reads from Gmail, never writes. Right now my local copy holds 173,206 messages and about 13,000 attachments, roughly 13GB.
So, my goal was to treat Gmail as the live account with a max size limit of (10 GB) and msgvault as the full archive on my own disk. This would allow me to delete the old, unwanted emails within my Gmail once the archive is complete and still keep everything in my local disk. However, I was worried that Msgvault on a future full-sync would try to delete my local archive copy to match with what is in the Gmail. I couldn’t find any documentation to explain how Msgvault worked and its behavior in such a scenario. My second concern was that I could not figure out how to automatically synchronize / back up my Gmail SQLite database to an external disk.
Agents to my rescue!
I asked my OpenClaw agent to investigate on my first concern: review the msgvault source code and docs and then tell me how Msgvault handles when I delete a message from Gmail, does the next msgvault sync remove the local copy?
I wanted my agent to answer from the real system, not from a guess. So it read msgvault’s source code and database schema. The agent found that Msgvault has a messages table with two columns, deleted_from_source_at and archived_at, which only make sense if the tool is built to keep a local message after it leaves Gmail and record when that happened. The docs said the same. This made it apparent that Msgvault’s default approach is to retain and not delete the local archived copy. This confirmation gave me confidence that I could built a workflow on top of Msgvault.
Agents figures out why my backup was broken
Now here is where things got interesting. My whole plan rested on one assumption - that my local archive was safely backed up on my external disks. So before deleting anything, I asked my agent to run a backup. Msgvault backup command threw some error messages. And when the agent dug in, it turned out the backup had been failing on every single run for a while now.
The culprit? 39 attachment files that were either corrupt or missing on disk. The backup would hit one of these bad files, choke, and stop. So the very safety net I was counting on had not been completing at all. Good thing I checked before I started deleting the originals, and not after.
My agent then found that msgvault quietly keeps a full raw copy of every message, compressed, stored separately from the loose attachment files. So the agent pulled the correct bytes for each of the 39 broken attachments out of that raw store, verified each one against its checksum to make sure it was rebuilding the exact original and not some garbage, and wrote it back. All 39 recovered, none lost. Then the backup ran clean to two separate external drives, and I had the agent verify both.
Now the deletion plan finally felt safe. I now have two clean backups on 2 external disks and I have also confirmed on the retention behavio with one test deletion gave me the confidence to now fully go ahead.
One more thing - Minor optimization
I decided to split my Msgvault archive so the agent could work on parts of it
First thing I wanted was to organize my archive so that I can build more agentic workflow on top of my emails before deleting any of the emails. In particular I wanted all my LinkedIn and Substack mails on their own, so an agent could read just that slice instead of my entire inbox.
I had the agent build a small carving script that takes a --profile and pulls a standalone searchable database out of the main archive for a chosen set of senders. LinkedIn came out as its own database, 27 senders and about 14,700 messages. Newsletters came out as another, 463 senders. Each one is a self-contained SQLite file an agent can open by itself.
Now on to automated deletion to save my GMail space
I leaned in on msgvault’s staged path to delete my Gmails.
Now, you might wonder - Hey, Sriram - all of these are done by the Msgvault tool. What did AI agents do here? Funny thing is that I guided my OpenClaw to optimize for safety and reliability. My agents found the best path forward. My agents read the Msgvault source and docs to figure out that using msgvault’s deletion flow is better rather than sending raw delete API calls to Gmail, because Msgvault has these specific gates that ensure automation does not accidentally delete or touch emails that you want retained.
• Stage the messages into a batch.
• Staging also saves each message’s full raw content locally first, so the archive copy is captured before the Gmail copy goes.
• Dry-run the batch to see what it would remove without removing anything.
• Execution only runs when a specific environment flag is set, so nothing deletes by accident.
Then, I asked it to pick messages that had the lowest signal. It started with the oldest LinkedIn job alerts, the least valuable mail in the account. Sorry, LinkedIn.
My agent staged one email for deletion first following the above workflow - first staged, then dry-run, and finally executed.
I now double checked that the local copy was not deleted. This gave me confirmation and I was ready to try bigger and more audacious things.
What you can take away from this
Yes, Msgvault tool is awesome and it makes it really easy to archive your GMail. Honestly that is not really the point. To me though, the reusable bit is how you can navigate your checks to do the due diligence and automate your every day tasks.
A few things I would do again. I made the agent write scripts to deterministically verify the safety behavior against the real system before it touched anything. I had my agent to also split my mail into slices so it could pick up one at a time, all behind a single engine instead of a pile of one-off scripts. Last but not least, I guided my agent so that deletions go through msgvault’s own staged, dry-runnable, gated path rather than raw API calls. Last but not least, I had my agent check that my backup actually worked before I relied on it, which is how I found out it had been quietly broken.
I was able to do one round of clean up. I have reduced my GMail to now 8GB. Still, I have not deleted several thousands of emails yet. But the hard part is done.
What is left is now routine - stage a batch, dry-run it, confirm the archive kept its copy, then execute. That is the next thing on my list.
If you have used other tools to achieve this, please do share your comment. Are there other better ways to do this?
========
I was close to hitting the 15 GB size limit in my Gmail. I started getting those annoying upgrade messages from Google including the warning banner etc. I also did not want to spend my afternoon cleaning up those years of mail. The obvious quick fix is to search, filter and delete a few thousand old emails. It was just too boring and grinding work that I didn’t want to spend my time on. Naturally, I handed the job to my agent instead. Here is a walkthrough of how I went about this. Sharing it here so if you want to replicate it, you can do so easily.
Msgvault
A while back I came across Msgvault, and started using this tool to keep a local copy of my whole Gmail. It pulls every message into a SQLite database on my Mac plus a folder of attachments, and it only reads from Gmail, never writes. Right now my local copy holds 173,206 messages and about 13,000 attachments, roughly 13GB.
I set a target of Gmail under 10 GB and msgvault as the full archive on my own disk. This would allow me to delete the old, unwanted emails within my Gmail once the archive is complete and still keep everything in my local disk. However, I was worried that Msgvault on a future full-sync would try to delete my local archive copy to match with what is in the Gmail. I couldn’t find any documentation to explain how Msgvault worked and its behavior in such a scenario. My second concern was that I could not figure out how to automatically synchronize / back up my Gmail SQLite database to an external disk as I kept experiencing some backup related issues. I had to solve these issues before I could figure out how I will automate deleting emails from my GMail account.
Agents to my rescue!
I asked my OpenClaw agent to investigate my first concern: review the msgvault source code and docs and then tell me how Msgvault handles when I delete a message from Gmail, does the next msgvault sync remove the local copy?
I wanted my agent to answer from the real system, not from a guess. So it read msgvault’s source code and database schema. The agent found that Msgvault has a messages table with two columns, deleted_from_source_at and archived_at. This schema make sense if the tool is built to keep a local message after it leaves Gmail and record when that happened. The docs said the same. This made it apparent that Msgvault’s default approach is to retain and not delete the local archived copy.
This confirmation gave me confidence that I could build a deletion automation workflow on top of Msgvault.
Agents figure out archive backup to external disks
Now here is where things got interesting. My automatic deletion plan rested on 2 key pillars - Msgvault archives everything and all archive is now saved in couple of external disks. However, the Msgvault backup command - the command to archive to external disks threw error. And when the agent dug in, it found that 39 attachment files that were either corrupt or missing on disk. Msgvault backup command would hit one of these bad files, choke, and stop.
AI agent then found that msgvault quietly keeps a full raw copy of every message, compressed, stored separately from the loose attachment files. So the agent pulled the correct bytes for each of the 39 broken attachments out of that raw store, verified each one against its checksum to make sure it was rebuilding the exact original and not some garbage, and wrote it back. All 39 recovered, none lost. Then the backup ran clean to two separate external drives, and I had the agent verify both the archive.
Now the deletion plan finally felt safe. I now have two clean backups on two external disks, and I have also confirmed the retention behavior with one test deletion. That gave me the confidence to now fully go ahead.
The actual deletion - Msgvault’s staged path
Now, you might wonder - Hey, Sriram - all of this is the Msgvault tool doing the work. What did the AI agent actually do here? Funny thing is, I guided my OpenClaw agent to optimize for safety and reliability, and it found the best path forward. It read the Msgvault source and docs and figured out that using Msgvault’s own deletion flow is far safer than firing raw delete API calls at Gmail. Msgvault has specific gates that make sure automation does not accidentally delete or touch mail I want to keep.
Stage the messages into a batch.
Staging also saves each message’s full raw content locally first, so the archive copy is captured before the Gmail copy goes.
Dry-run the batch to see what it would remove, without removing anything.
Execution only runs when a specific environment flag is set, so nothing deletes by accident.
Then I asked it to pick the messages with the lowest signal. It started with the oldest LinkedIn job alerts, the least valuable mail in the account. Sorry, LinkedIn.
My agent staged one email first, following the flow above - staged, dry-run, then executed. I double-checked that the local copy was still there. It was. That is the workflow I then scale to the bigger, more audacious batches.
One more thing - minor optimization
I decided to split my Msgvault archive so the agent could work on parts of it.
Here is the thing - 173,206 messages in one big database is fine as an archive, but it is not something I can hand an agent and say “go work on just my LinkedIn mail.” I wanted my LinkedIn and Substack mail carved out on their own, so a future agent could read just that slice instead of loading my entire inbox every time.
So I asked my agent to build a small carving script. You give it a --profile, and it pulls a standalone, searchable SQLite database out of the main archive for whatever set of senders you name. LinkedIn came out as its own database - 27 senders, about 14,700 messages. Newsletters came out as another - 463 senders. Each one is a clean, self-contained file an agent can open by itself, without touching the main archive.
Nothing fancy, but the groundwork is there now. Next time I want to build an agent workflow on just my job-related mail, or just my newsletters, the data is already sliced and ready.
With one deletion run, I was able to bring down my GMail from 15 GB to 8 GB now. I believe now the hard part is done - two verified backups on two external disks, proof that Msgvault will not wipe my local copies, and an archive that is sliced up for whatever I want to build next. Now doing more bulk deletion is the easy part, and that is the next thing on my list.