--- title: "Gobbl Memory: how it reads your screen without screenshots" description: "Memory reads on-screen text through macOS Accessibility, not screenshots. Here's how it handles chat apps and secrets, and where the data lives." date: "2026-10-04" app: gobbl kind: build readingTime: "5 min read" image: "/img/build/gobbl/notch-tools.jpg" imageAlt: "Gobbl's tools tab with a focus timer, keep awake, mute mic, colour picker, screen text, quiet pet and share Gob controls." --- Memory, Gobbl's opt-in feature that keeps a timeline of your day, reads text through macOS Accessibility — not screenshots, and not a keylogger. That choice shapes every decision in how Memory works, and it came under pressure from a practical question about whether it could handle chat apps. ## Why Accessibility instead of screenshots macOS Accessibility is the framework behind screen readers: it gives an app a structured tree of the text visible in other apps, without capturing a pixel. Mail exposes message subjects and bodies. Notes exposes paragraphs. Most productivity software follows the same pattern. Reading through that tree means Memory never holds an image of your screen. A screenshot-based approach immediately captures everything visible — the browser address bar, file names in Finder, the wallpaper peeking behind windows — and filtering that after the fact is harder than not capturing it in the first place. With Accessibility, you read only the fields you want. Password fields are a useful example. macOS marks secure text fields explicitly in the Accessibility tree; apps that use the standard secure input control get that protection automatically. Memory skips them without any additional configuration. The full skip list goes further: private and incognito browser windows, banking, brokerage, crypto and health sites, the lock screen, and Gobbl's own interface. The app also stops reading when you step away from the keyboard or the screen locks. ## Chat apps and the contact list The first pass at Memory worked well for documents, email, and text editors. Chat apps created a different problem, and it surfaced during the build: > does this work for teams , slack etc also ? The difficulty is structure. A chat app window is not just the conversation: it's also a contact list, a sidebar, message previews, pinned threads, emoji reactions, and the draft you haven't sent. Reading the whole Accessibility tree of a Slack or WhatsApp window pulls in a lot of text that was never meant to be remembered — the names of everyone in your contact list, channel names you haven't opened, message previews that appeared for a second and then scrolled away. The fix required mapping the Accessibility tree for each app and making explicit decisions about which branches to include. In WhatsApp, the visible conversation is a specific subtree; the contact and chat list sits beside it and gets skipped. Drafts — anything in a composing field — stay out of Memory entirely. Only messages that have been sent or received go in. ![Gobbl's chat in the notch answering "What's on today?" and setting a reminder for 5:00 PM](/img/build/gobbl/notch-chat.jpg) *Chat in the notch: questions answered using what Memory has read from your screen.* ## What it masks on the way in Before anything reaches the local store, Memory looks for strings with the shape of secrets: card numbers, API keys and tokens, passwords, one-time codes, CVVs and IBANs. These are masked in the reading step, not in a cleanup pass afterwards. A secret that appears on screen never enters the database, even in redacted form. The same pass handles the skip list. A banking site doesn't leave a masked record that says "something was here". The content is simply not read. ## What Memory builds The text that passes these filters becomes a timeline. Each day gets a digest: what you worked on, the people involved, the decisions you made. People and projects get their own cards, built up across different contexts over time. Two mentions of the same person merge into one card only on a hard match — the same email address in both contexts — and softer matches become a prompt to confirm. To-dos are treated differently from facts. If Memory reads "send the Q3 report to marketing", it suggests a to-do but holds it open until there's proof it's done: a reply thread in the same inbox, or a confirmation in the same app. When that evidence appears on screen, the to-do ticks itself off. Undo is always available. All of this is stored in a local database on the Mac and never syncs anywhere. Search across the timeline runs on the device. The only traffic that leaves the Mac is for features that require a language model — day digests, memory chat, pre-meeting briefs. Those send short, already-masked snippets through Xeve's service to a provider that doesn't keep data, and every request is logged locally so you can see what was sent. ## The release Near the end of the build session, with Memory working and the Gobbl key writing and rewriting text in real time, the last significant prompt of the day was brief: > lets pubish notarized released with auto updates That produced version 0.1.0, signed and notarized, with Sparkle for automatic updates. Notarization matters specifically here. Gobbl needs Accessibility permission to read on-screen text, and asking for that permission while failing Apple's notarization check makes every request feel suspect. The app passes notarization before it ever asks for anything sensitive. Memory is off by default and you turn it on explicitly. You can pause it, delete any day's records, or turn it off entirely at any time. The details — what it reads, what it skips, and how the AI features work — are at [gobbl.xeve.io/memory](https://gobbl.xeve.io/memory). Gobbl is free and open source under the MIT licence, runs on macOS 14 and later, and the AI features (memory chat, digests and briefs) are free during the beta and will move to a paid plan later.