shouldivibecodeit

Should I vibe codeSaner.AI?

AI workspace for capturing, connecting, and querying personal knowledge

Your inbox is a password-reset machine. That is the credential store you just gave a weekend agent write access to.

?

Their verdict, the Paid upgrade (free plan available) price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.

Can you build it?asked by canivibecodeit.com ↗KINDAweekend project · multi-day
?

Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.

Should you ship it?asked by usDEMO ONLYvibe the v0, throw it away.

The honest answer

why the verdict is what it is

Everything about this entry turns on what you let the assistant touch. Saner.AI now describes itself as an ADHD-friendly assistant for notes, email and calendar — you chat with it, it searches your notes, triages your mail, schedules your tasks and checks in during the day. The notes half is what canivibecodeit is rating, and they are right that it is a few days: chunk, embed, retrieve, hand it to a model. The other half is not a feature, it is a category change. To manage email your app needs a Google refresh token with modify scope, stored somewhere, refreshed forever, attached to something that decides on its own when a thread is noise. Your mailbox is also, structurally, where every password-reset link you have ever received still lives, so the little service you deployed to a VPS in March has quietly become the single credential that unlocks your bank, your registrar and your cloud account. Nobody else is downstream of that, which is what keeps this blue rather than yellow. Build the notes half and enjoy it. Give the mail half read scopes and make yourself press the button.

What actually breaks

not "if". the specific failures.

  • The OAuth grant, in the most boring way available: an unverified Google app stays in testing mode, its refresh tokens expire after seven days, and your assistant stops seeing new mail without saying so
  • Restricted-scope verification, which is where personal projects that ask for gmail.modify go to sit — Google requires a security assessment before an app carrying those scopes leaves testing
  • Retrieval quality, once the note count passes a few thousand and the top five chunks stop containing the answer, with nothing in the app able to tell you that happened
  • The proactive part, because a scheduled job that reads your inbox and acts on it is a cron job wearing your identity, and cron jobs run at four in the morning with nobody watching
  • Archiving, which is a write: the model decided a thread was noise on the strength of a subject line and you will find out when someone asks why you never replied
  • Token storage, which will be a plaintext column or a .env baked into a Docker image you pushed to a registry
  • Calendar writes, which land in other people's calendars and generate invitation emails you cannot recall
  • Your embeddings, the day you change model and the old vectors and the new ones stop living in the same space — a full reindex nobody budgets for

Is that you?

the verdict is a default, not a law

ship it if
  • It is your notes, your machine, and the only outbound call is to a model API
  • Every mail and calendar scope you request is a read scope, and the app physically cannot send, archive or delete
  • Actions are proposals: it drafts, it suggests, and a human presses send
  • You are the only user, and the token in the database is your own
don’t ship it if
  • You are hosting it for anyone else, because you have become the custodian of other people's mailboxes
  • The agent holds a write scope and a schedule at the same time
  • The refresh token lives anywhere you would be relaxed about leaking — a repo, an image layer, an unencrypted column
  • Your notes contain client material you are contractually obliged not to hand to a third-party model
  • You could not answer, in writing, which model provider has seen your last six months of email

If you build it anyway

the checklist, then the prompt that enforces it

  1. Start with the notes. Chat over your own writing is the genuinely delightful part and it needs no OAuth at all — ship that, live with it for a month, and see whether you still want a mailbox in it.
  2. Request the narrowest scope that works and treat each widening as its own decision. gmail.readonly and calendar.readonly buy you triage, summaries and a daily plan; gmail.modify buys you an assistant that can be wrong irreversibly.
  3. Make it propose rather than act. A queue of drafted replies, suggested archives and proposed calendar holds that you approve in one screen is nearly all of the value and almost none of the exposure.
  4. Encrypt refresh tokens at rest with a key that does not live in the same database, and write the revocation path — one command that kills the grant — before you write the first API call.
  5. Log every action with the message id, the reasoning and an undo. An assistant with no audit trail is one you cannot debug on the morning something is missing.
  6. Never give a scheduled job a write scope. If a cron must run unattended, hand it read credentials and let it produce a list for you to look at.
  7. Decide explicitly what leaves the machine. Stripping attachments and quoted history before a body goes upstream is a twenty-line function and the difference between a tidy answer and an awkward conversation.
  8. Version the embeddings alongside the model that produced them, so changing model is a planned reindex rather than a silent collapse in answer quality.
the guardrail prompt
I am building a personal AI assistant over my own notes, email and calendar.
Build it in the order below. The mailbox is the dangerous part, so it arrives
last and it arrives read-only. Argue with me if I try to reorder this.

1. Phase one contains no OAuth at all: local notes, chunking, embeddings,
   retrieval, chat. Make that good before anything touches Google.
2. Keep the notes as plain files on disk. The vector index is derived and
   disposable; when the index and the files disagree, the files win.
3. When mail arrives, request read-only scopes only — gmail.readonly and
   calendar.readonly. Do not add gmail.modify, gmail.send or calendar write.
   If I ask for them, stop and make me say out loud what happens the first
   time the model is confidently wrong about a thread.
4. Explain Google's verification path for restricted scopes, and testing-mode
   refresh tokens expiring after seven days, before you assume a lasting grant.
5. Encrypt the refresh token at rest with a key held outside the database, and
   ship a one-command revoke script in the same commit that first stores one.
6. Every suggested action goes into an approval queue showing the source
   message, the proposed change and a one-click reject. Nothing executes on
   its own.
7. Redact before you send: strip attachments, quoted history and obvious secret
   patterns from message bodies before they reach a model, and show me the
   redacted payload.
8. Log every read and proposal with a timestamp, a message id and what went
   upstream, so I can answer "what has this thing seen" a year from now.
9. No scheduled job may hold a write credential. Unattended runs get read
   scopes and produce a list, nothing more.
10. Record which embedding model produced which vectors and refuse to mix
    generations in one index.
11. Out of scope: multi-user hosting, team sharing, and sending mail on my
    behalf. If I ask for those, tell me I have crossed from a personal tool
    into running mail infrastructure for other people.
paste this before you build — not after something breaks31 lines · 2019 chars

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

just pay for it

If the appeal is the proactive part — something that notices you never started the thing you said you would, and asks — buy it. That behaviour is tuned across thousands of users and you will not get it right for yourself in a weekend. Their own pricing page metadata puts the paid upgrade under ten dollars a month and there is a free tier, so the experiment is cheap. Build your own if what you actually want is search across your own notes with a model on top, which is the good half and the half that carries no credentials.

your exit plan, if you already built it

The exit is easy if the notes were files and painful if they were rows. Keep the writing as Markdown in a folder, keep the vector index as a rebuildable artefact, and the assistant becomes a layer you can delete without losing anything that mattered. The thing that does not exit cleanly is the OAuth grant: revoke it deliberately from your Google account's third-party access page rather than assuming that deleting the app deletes the access. An abandoned VPS with a live refresh token on it is the worst available way to stop using your own project.

prior art · someone already did this
Khoj

Self-hostable AI second brain that answers from your own documents and runs scheduled automations.

Logseq

Open-source local knowledge graph and outliner — the notes half, with no mailbox attached.

Questions

Why is this harsher than the Mem entry if both are AI note apps?

Because Mem is a note app and this is a note app wired to a mailbox. Saner.AI's own description leads with notes, email and calendar in one chat box, and the email part changes what you are holding. A note database leaks your thinking; a Gmail refresh token leaks everything that has ever been password-reset to that address. Same weekend of code, very different worst day.

What will an agent get wrong that I would not?

It will ask for gmail.modify on the first pass, because that is the scope that makes the demo work end to end, and it will label it "manage your email" on the consent screen it writes for you. It will also drop the refresh token into the same table as everything else and treat expiry as an error to retry rather than a state to surface. Neither is malice; both are what the natural implementation looks like.

Is the read-only version actually useful?

It is most of the product. A morning digest that reads unread mail, today's calendar and your notes and tells you what the day looks like needs nothing but read scopes, and it is the thing you will keep using. Each time you are tempted to add a write, notice that what you actually want is a button.

Does the ADHD framing change the risk?

Not legally — this is not a medical device and there is no health data in it. It changes the honesty of the argument. The people it is sold to are, by the vendor's own framing, the ones least well served by a tool that quietly stops syncing and says nothing. If you build it for yourself, build the failure states loudly: a stale-data banner is worth more than another feature.

sources
  • Google API Services User Data Policy — restricted scopes and app verification
did you build it?

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.

also on the regret index
MemDEMO ONLY

Semantic search over fifty notes is magic. Over five thousand it's a ranking problem you have no way to measure.

NapkinSHIP IT

The AI that connects your ideas is an embedding and a cosine. What you're paying for is two taps to capture.

ReflectDEMO ONLY

E2EE and an AI that reads your notes pull opposite ways. The homemade version resolves it by keeping your key.

last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice