Should I vibe code
Server-side email filtering, reminders, and inbox cleanup
A false positive here throws no error. The message arrived, got filed, and quietly stopped existing for you.
?
Their verdict, the price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Two mailbox entries here already cover the neighbouring failures: Spark for the daemon that holds your credentials, Clean Email for the bulk operation you cannot take back. SaneBox's own contribution is quieter and, over a year, more expensive. It moves individual messages out of your inbox based on a guess, one at a time, continuously, and it is right often enough that you stop checking. Think about what a false positive looks like from outside. The sender's mail was accepted. It was delivered. It was filed. There is no bounce, no error, no red row in a queue anywhere — the only symptom is a conversation that never happened, and your software is structurally incapable of telling you about it. That asymmetry is the whole problem: the good outcome is invisible and so is the bad one. Underneath sits the usual machinery, a service that runs while you don't, holding a token or an app password with full access to the mailbox, issuing IMAP moves against servers that implement a move as copy-then-delete and occasionally manage only one of those. The classifier is the fun part and it is a weekend. Being trusted with an inbox for a year is not.
What actually breaks
not "if". the specific failures.
- The false positive, which is the product's actual failure mode and produces no signal anywhere. The message is not lost, it is filed — which is worse, because you now believe you have seen your inbox
- MOVE itself. Many IMAP servers implement it as COPY followed by EXPUNGE, so a connection dropped between the two leaves you with a duplicate or with nothing, and only one of those is noticeable
- Gmail, which is not IMAP with a different hostname. Folders are labels, moving means removing one, All Mail keeps a copy you did not plan for, and the API's delete is not the client's delete
- The credential, which is the whole mailbox: an always-on service holding an OAuth refresh token, or for iCloud and the long tail an app-specific password that is functionally the account
- The classifier's feedback loop. It learns from what you open, so a fortnight away teaches it that nothing matters, and a retrain quietly reclassifies the past along with the future
- Auto-delete rules, if you copy the blackhole feature. They key on a From header, which is a string the sender chooses, and they are irreversible by design rather than by accident
- Divergence. You move things by hand, a phone client moves things, UIDVALIDITY changes, a folder gets renamed — and now your state and the mailbox's state are two opinions with no referee
- Throttling. Gmail and Exchange rate-limit a chatty client, and when they do, triage stops without stopping: the daemon is up, the log is clean, and nothing has been sorted since Tuesday
The rule that caused it was a reasonable one: mail from senders you have never replied to, matching the shape of a template blast, goes to the Later folder. Your registrar's renewal notices match that shape exactly, because they come from the same no-reply address and the same template as the registrar's marketing, which you had been ignoring for two years. Three notices went to Later. So did the fourth, the one whose subject line said the domain had expired. You noticed at the point mail stopped arriving at all — which is also the point at which the password reset for the registrar account goes to a mailbox on the domain that just lapsed. Everything after that was recoverable, in the sense that a redemption fee and a support queue are recoverable. The part worth sitting with is that no piece of software behaved incorrectly by its own lights. The classifier applied what it had learned. The mail was delivered. The folder was right there the whole time.
Is that you?
the verdict is a default, not a law
- It flags rather than moves: a label, a star, a filtered view over a mailbox nothing has touched
- It is your mailbox alone, and nothing concerning anyone else's business passes through it
- Every action lands in a log you can read, with an undo you have actually used at least once
- It refuses to touch anything from a sender you have ever replied to, no matter what the model says
- It moves or deletes without an audit trail you would be willing to produce in an argument
- It runs unattended against a mailbox where a missed message costs a deadline or a contract
- It holds an app-specific password for the account that is also your identity recovery route for everything else
- You have not tested what happens when a move fails halfway through
If you build it anyway
the checklist, then the prompt that enforces it
- Flag, do not move. A keyword, a label or a local flag plus a filtered view gives you the same experience with a display bug as its worst case instead of a lost message. Earn the right to move things later, if at all.
- Build the undo before the classifier. A per-message log of message-ID, source folder, destination folder, timestamp and reason, and a command that puts everything from a given run back. Write it first; you will need it during the first week.
- Never delete. Not as a shortcut, not for the obvious spam, not on a rule keyed off a From header, which is a field the sender fills in.
- Allowlist by relationship: anyone you have ever replied to, anyone in your contacts, anyone in a thread you started. Those are never touched by automation, which removes most of the ways this hurts.
- Send yourself a digest of everything filed, every day, and make it readable in fifteen seconds. This is the mitigation SaneBox itself leans on, and it exists precisely because the failure mode is silence.
- Fail closed. On a classifier error, a timeout, an unexpected folder or an unparsed header, do nothing and log it. The default must be leaving mail where it is.
- OAuth wherever the provider offers it. Where it does not, decide deliberately where an app password lives, who can read it, and what an attacker with the host obtains — and write the answer down before the first run.
- Copy the header-only design. SaneBox does not take possession of message bodies; a triage system that only reads headers and metadata is a far smaller thing to lose control of, whether or not you ever buy theirs.
I am building an email triage service that classifies incoming mail and gets
the unimportant messages out of my inbox. The failure I care about is the silent
one: something that mattered is filed plausibly and I never see it. In order:
1. Read-only first. Connect, classify, write the results to a report I read for
two weeks. Nothing in the codebase moves, deletes or flags mail yet.
2. Build the action log and the undo before the first write: message-ID, source
and destination folder, timestamp, the rule or score that caused it, and a
command that reverses an entire run. Demonstrate the reversal working.
3. When actions start they are flags or labels only. If I ask for real moves,
explain the copy-then-expunge failure and what a half-completed move loses.
4. Deletion is permanently out of scope. If I ask for a blackhole feature, say
no once: it keys on a From header, which is a string the sender chooses.
5. Hard allowlist, checked before any rule: anyone in my contacts, anyone I
have replied to, anyone in a thread I started. These are never touched.
6. Send me a daily digest of everything filed — subject, sender, reason — that I
can scan in fifteen seconds. Build it before tuning the classifier.
7. Fail closed. Unknown folder, parse error, timeout, classifier exception,
ambiguous score — do nothing, log it, alert me. Never guess.
8. Handle IMAP honestly: UIDVALIDITY changes mean refetch, folder names are
modified UTF-7, IDLE drops, Gmail's labels are not folders. Test two hosts.
9. Credentials: OAuth where it exists; otherwise tell me exactly where the app
password lives, encrypted with what, and what an attacker with the host gets.
Keep it out of the database that holds message metadata.
10. Rate-limit and back off with jitter. If the provider throttles us, surface
it loudly — a triage service that silently stopped sorting on Tuesday looks
exactly like a quiet week.
11. Read headers only. Do not store message bodies anywhere, and if a feature
seems to need them, tell me which one and why before implementing it.
12. Out of scope: other people's mailboxes, auto-replies and anything that
sends. SaneBox sells moves and reminders run by someone else's on-call rota.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
As soon as the mailbox is one where a missed message costs something. The price is on a page that would not render for us, so check it yourself — but the case for buying is not really the price, it is the two design decisions the product already made and your weekend build probably will not. It analyses headers rather than taking possession of message bodies, and it sends you a digest of everything it filed, which is the only honest answer to a failure mode that generates no errors. If you build your own, steal both of those before you steal the classifier.
The exit is easy or nearly impossible, depending on one decision you made months earlier. If the system only ever flagged, leaving means deleting some keywords and revoking a token; the mailbox was never altered and every client sees what it always saw. If it moved things, leaving means finding everything it moved and deciding where each message should have been — which is only tractable if you kept the per-message log, and is otherwise a year of archaeology across folders. Either way, rotate the credential rather than merely deleting the app: an app-specific password for a mailbox usually keeps working long after you have forgotten which VPS was using it.
Small Lua-scriptable IMAP rules engine, still maintained, and the sane starting point for server-side triage.
Open-source desktop mail client whose sync engine is a realistic preview of the IMAP edge cases waiting for you.
Questions
Isn't this just a spam filter?
No, and the difference is the whole entry. A spam filter is tuned so that false positives are catastrophic and rare, and the mail it catches is mail you never wanted. A triage classifier sorts wanted mail by predicted importance, so its errors are ordinary messages from real people, filed somewhere plausible. Spam filtering has decades of shared training data and adversarial research behind it. Your importance model has your click history and about a fortnight of it.
Why not just use the provider's own filters?
Do, for anything you can express as a rule. A deterministic filter is inspectable, runs on the provider's infrastructure, needs no credential of yours, and does the same thing every time — which means when something goes missing you can read the rule and know why. The reason people buy this category is the part rules cannot do: guessing about senders you have never seen. That guess is also the reason this page exists.
Is flagging instead of moving really enough to get the benefit?
Almost entirely, yes. Every mail client will hide, sort or colour by keyword, so a flag plus a filtered view gives you a clean inbox with the messages still in place. The difference is what happens when the classifier is wrong: with a flag it is a display bug you fix by changing a filter, and with a move it is a message in a folder you do not read. Same product, one of them recoverable.
How likely is the missed-message scenario, honestly?
Likely enough that the commercial product ships a daily digest specifically to catch it. Any classifier operating on thousands of messages a month will misfile some; the question is never whether but whether you find out. That is why the guardrails here are about the digest, the log and the undo rather than about model accuracy — accuracy is what you tune, and recoverability is what saves you.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
A mail client is a browser you wrote for content sent by strangers, running beside your IMAP passwords.
The Gmail API's delete call skips the Trash entirely. Your cleanup script will reach for it — it's the obvious verb.
An autonomous agent with delete permission on your inbox is a very fast way to lose something.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice