Every Notion April 2026 release landed as a bigger .txt on disk, not a bigger tool response.
Most April 2026 release write-ups list what Notion shipped. This one is about the other half: when the new mic button, the new shareable-AI-chat menu, or the Workers for Agents panel enters the desktop window, what does a third-party Mac agent actually read to reach it. The answer is a compact summary over stdio plus a literal grep hint pointing at a file on disk, emitted by a 1,917-line Swift binary that has never heard of Notion.
Every Notion April 2026 release, tagged by the AX role it enters the tree as
The framing every other April 2026 roundup skips
Open any notion-releases-april-2026 SERP page and you get a list: voice input on the 6th, shareable AI chats on the 7th, mute on the 8th, new cover art on the 9th, tab display on the 10th, the big 3.4 Part 2 drop on the 14th. Which plan you need, what changed in the API, what got faster. That is the product-release view.
The automation view is different. When Notion pushes a new Electron build overnight, the macOS accessibility framework picks up every rendered control automatically. A third-party agent that reads that tree instead of a screenshot gets every new Notion feature on the day it ships, with zero vendor cooperation. The interesting question is not "did the agent see the new feature" (it did, the AX tree is authoritative). The interesting question is "what did the agent have to read to find it" and "did that response scale with the UI."
The April 2026 answer, for an agent running on top of Fazm's bundled mcp-server-macos-use binary, is that the on-the-wire response stayed the same shape across all eleven releases. The tree got denser (Notion 3.4 Part 2 added sidebar subtrees, a Workers for Agents panel, a custom-instructions field, admin controls). The disk files got bigger. The stdio response did not.
The anchor fact: the tool response literally tells the agent to grep
Inside the bundled binary, at Sources/MCPServer/main.swift line 731, lives a function called buildCompactSummary. Thirty lines down, at line 761, it appends a single line to the stdio response that is unusual in agent tooling: an explicit grep command. Here it is verbatim.
“lines.append("hint: grep -n 'AXButton' \\(filepath) # search by role or text")”
main.swift line 761, inside buildCompactSummary
The structural numbers behind the April wave
The 1,917 is wc -l on the checked-in main.swift. The 0 is grep -ci Notion main.swift. The 6 is a literal count of let X = Tool( declarations, each at a line number this page quotes. The 2 is the two noise-filter functions that run before the tree ever hits disk, dropping scrollbars and empty rows so the grep stays targeted.
Three numbers from inside the binary
Lines in main.swift. Zero of them name Notion. Every April 2026 Notion release reached through this same file.
Line number of the grep hint appended to every tool response. The agent is invited to grep, not to consume the tree.
Server version declared at main.swift line 1413. Held steady across the entire April release wave.
The two functions that keep the grep targeted
Notion 3.4 Part 2 added a dashboards preview pane with many nested rows, a sidebar with more subtrees, and a Workers for Agents config panel with numerous small controls. Dump the raw AX tree of that window and you get thousands of elements, most of them scrollbars and empty row containers. Two small filters run in buildToolResponse before the tree is written to disk.
Neither function references Notion. Neither references any app. Both take a role string and return Bool. When Notion 3.4 Part 2 added more sidebar rows on April 14, these filters dropped the empty ones before anything ever hit /tmp/macos-use/. So a grep for "Workers" or "Custom instructions" landed on the one line that mattered instead of wading through empty rows.
What a screenshot-based agent reads vs. what a Fazm-style agent reads
Same Notion window, same April 6 voice input button, two very different wire formats. The left column is what every screenshot-based computer-use tool burns through the model. The right column is what Fazm's bundled binary returns.
Turn 1: user says 'press the voice input button in Notion'
Screenshot agent: capture the full Notion window, compress to PNG, upload. The model sees a 1-2 MB image, scans pixels, guesses coordinates for a 32x32 button. Every additional April 2026 release (custom instructions panel, Workers for Agents config, Mute context menu) means another screenshot round and another pixel guess. Cost scales with UI density and screenshot resolution.
- 1-2 MB PNG in the model context per turn
- Click coordinates are probabilistic
- Cost grows with each new Notion release
- No structured way to ask 'where is the Mute item'
April 6 voice input, end to end, in one sequence
A single user turn on the day Notion shipped voice input on desktop. Walk it through the five actors. No Notion-specific code is invoked at any step.
User: 'dictate a task into Notion's voice input'
Five April 2026 releases, one pipeline
Notion releases on the left enter the Electron window. The accessibility tree picks them up. The traversal writes to disk. The summary, the only thing over the wire, carries a grep hint. The agent greps.
How every April 2026 Notion release reaches the agent
What one tool call actually returns
Wire the bundled binary up over stdio and call macos-use_open_application_and_traverse against Notion. The compact summary below is the whole response that goes over the wire. The tree itself sits on disk, ready to grep. Notice the line after file_size.
Each April 2026 release, mapped to the grep pattern that finds it
The tree is plain text. Finding a Notion feature is a grep. The grep is the same shape for every release. Only the pattern changes.
Voice input on desktop (Apr 6)
grep -n 'Voice input' /tmp/macos-use/*.txt. The match is one line with role AXButton and 32x32 geometry. click_and_traverse with element='Voice input' hits it.
Shareable AI chats (Apr 7)
grep -n 'Shared AI chats' finds the menu item under Settings > Public pages. No API endpoint. The tree finds it.
Mute discussion replies (Apr 8)
Right-click a thread, refresh, grep -n 'Mute'. Returns a single AXMenuItem line. One click closes it out.
Cover art collections (Apr 9)
Open the picker. grep -n 'Met' or 'USDA' or 'NMAA' or 'Texturelabs'. Each collection is an AXImage row. scroll_and_traverse paginates the list.
Database tab display (Apr 10)
Open the view menu. grep -n 'Text and icon|Text only|Icon only' returns three AXRadioButton lines. Pick one.
Notion 3.4 Part 2 (Apr 14)
Workers for Agents, custom-instructions field, admin auditing controls, Connect n8n / Salesforce / Box buttons. Each is one grep away. grep -n 'Custom instructions' or 'Workers' or 'Connect n8n' on the 1842-element tree lands on the exact line. Same 6 tools, same buildCompactSummary, same 1.6.0 binary.
Release-day lifecycle, from Notion push to agent action
Eight steps, zero of which require a Fazm update, a vendor integration, or a model retraining round. This is what happened on April 6 for voice input, on April 8 for Mute, and on April 14 for every Notion 3.4 Part 2 control.
Notion pushes an Electron update overnight
The desktop app auto-updates. The new UI is now rendered in the Notion window.
macOS accessibility framework picks it up
The new control becomes an AXUIElement with a role, a label, and a frame. No Notion cooperation required. This is a platform guarantee.
Agent calls open_application_and_traverse
mcp-server-macos-use walks the AX tree starting from the app process. Two noise filters (main.swift 592, 600) drop scrollbars and empty structural rows.
Full enriched tree is written to /tmp/macos-use/<ts>.txt
One element per line in the format [Role] "text" x:N y:N w:W h:H visible. 10-30 KB for a typical Notion window.
Binary emits compact summary over stdio
status, pid, app, file, file_size, hint: grep -n 'AXButton' file, screenshot, summary. Under 500 bytes.
Agent greps the .txt by label
grep -n 'Voice input' or whatever the user asked about. One or two matching lines.
Agent calls click_and_traverse with element=<label>
Tool auto-centers click based on geometry in the tree. No coordinate math. No pixel guess.
Diff summary returns, containing only what changed
If a panel opened, it shows up as added AX nodes. If a toggle flipped, as a modified attribute. Agent confirms the action took.
What goes over the wire: three ways to drive April-2026 Notion
Same user goal (interact with a Notion feature Fazm shipped this month). Three different surfaces. The trade-offs are structural.
| Feature | Notion API or screenshot agent | Fazm (AX tree + file + grep hint) |
|---|---|---|
| Response size per tool call | API: JSON payload. Screenshot: 1-2 MB PNG per turn. | ~300 bytes summary over stdio |
| Where the full state lives | API: Notion's servers. Screenshot: in model context. | /tmp/macos-use/<ts>.txt on disk, greppable |
| Reaches voice input (Apr 6) | API: no endpoint. Screenshot: pixel guess. | Yes, grep -n 'Voice input' |
| Reaches Mute item (Apr 8) | API: no endpoint. Screenshot: menu easy to miss. | Yes, grep -n 'Mute' |
| Reaches Workers for Agents (Apr 14) | API: partial via Workers for Agents endpoints. Screenshot: dense panel. | Yes, grep -n 'Workers' |
| Day-of-release coverage | API: wait for endpoint. Screenshot: wait for model or prompt update. | Yes, automatic (AX tree is authoritative) |
| Cost per turn | API: rate-limited. Screenshot: image cost per turn. | One stdio round trip + one grep |
| Response shape stability | API: varies per endpoint. Screenshot: varies with UI density. | Constant across April 2026 wave |
| Need to update Fazm when Notion ships | API: needs new endpoints. Screenshot: needs new prompts. | No. Binary stayed at 1.6.0. |
Why this response shape holds across every Notion release
Nine facts about the binary. Each one is independently verifiable on any machine that has the Fazm app installed.
Nine grep-verifiable facts
- main.swift is 1,917 lines (wc -l confirms).
- grep -c 'Notion' main.swift returns 0.
- buildCompactSummary is defined at line 731.
- The grep hint is appended at line 761 verbatim: hint: grep -n 'AXButton' <filepath>.
- isScrollBarNoise at line 592 drops scrollbars, value indicators, page and arrow buttons.
- isStructuralNoise at line 600 drops empty AXRow, AXCell, AXColumn, AXMenu containers.
- The six Tool declarations are at lines 1300, 1329, 1349, 1363, 1384, 1402.
- Server version is '1.6.0', declared at line 1413 inside the Server initializer.
- acp-bridge/src/index.ts lines 1056 to 1064 mount the binary into the Fazm session.
Want to see the grep hint in action on your own Notion workspace?
Book a 20-minute walkthrough. We run tools/list live against the bundled binary, then drive voice input, Mute, and Workers for Agents end to end.
Book a call →Frequently asked questions
What did Notion release in April 2026?
Eleven user-facing changes between April 1 and April 14, 2026. Apr 1: v7.9.1 bug-fix. Apr 6: voice input for Notion AI on desktop (v7.10.0) plus AI Meeting Notes from Command Search. Apr 7: shareable AI chat links and markdown comment bodies in the API. Apr 8: muted discussion replies. Apr 9: four new museum-sourced page cover art collections (Met, USDA, NMAA, Texturelabs). Apr 10: customizable database tab display (text, icon, both). Apr 14: Notion 3.4 Part 2, including Workers for Agents, the Views API with eight endpoints, smart filters with relative dates, AI Meeting Notes API access, Custom Agents to n8n, Salesforce and Box connectors, heading 4 + tab block writes, writable wiki verification, approved-tools admin controls, and a 28% faster initial page render.
What is the anchor fact in the Fazm codebase for 'Notion releases April 2026'?
The Swift file at /Users/matthewdi/mcp-server-macos-use/Sources/MCPServer/main.swift is 1,917 lines. Running grep -c 'Notion' against it returns 0. Running grep -c 'notion' (lowercase) also returns 0. The binary built from that file is bundled into the Fazm.app package at Contents/MacOS/mcp-server-macos-use and reports itself as SwiftMacOSServerDirect version 1.6.0 when an MCP client runs tools/list against it. Every Notion April 2026 release was reached by an agent running on top of this binary without any change to the file.
Why is the file-backed traversal pattern important for Notion releases?
When Notion ships a denser UI (Notion 3.4 Part 2 adds the dashboards pane, presentation mode toolbar, and Workers for Agents config view), the AX tree grows. The MCP response does not grow with it. buildCompactSummary at main.swift line 731 writes the full enriched traversal to /tmp/macos-use/<timestamp>_refresh_traversal.txt and returns only a short summary with the file path, the element count, and a literal grep hint: hint: grep -n 'AXButton' /path/to/file.txt. The agent then uses a grep tool on that file to find the one element it needs (the new voice input button, the new Mute item, the new custom-instructions field). So denser Notion UIs produce bigger .txt files on disk but the same-sized response over the stdio wire.
What are the two noise filters that keep the on-disk tree readable?
isScrollBarNoise at main.swift line 592 drops anything whose role lowercases to scrollbar, scroll bar, value indicator, page button, or arrow button. isStructuralNoise at main.swift line 600 drops AXRow, outline row, AXCell, cell, AXColumn, column, AXMenu, and menu containers when they have no text. Both run during buildToolResponse, before the tree is written to disk. Neither function mentions Notion or any app by name. Both operate on a lowercased role string only. When Notion 3.4 Part 2 added more nested list rows to its sidebar, these filters already dropped the empty ones before the agent had to grep.
Which file in Fazm mounts mcp-server-macos-use into the agent loop?
acp-bridge/src/index.ts at lines 1056 to 1064. The bridge checks that the macosUseBinary path inside the app bundle (Contents/MacOS/mcp-server-macos-use) exists and, if it does, pushes a server entry named 'macos-use' into the MCP server list with empty args and empty env. The binary then gets discovered by the standard MCP tools/list flow and every downstream Claude Code agent session picks up the six tools. The mount is unconditional on the Notion version. When voice input shipped on April 6, no bridge code changed.
How is this different from a screenshot-based computer-use agent reading Notion?
Screenshot agents compress the full Notion window to a PNG, send it to a vision model, and ask the model to predict click coordinates. Each turn costs a megabyte-scale image in the model context. The Fazm-style agent never sends screenshots of Notion to the model for UI targeting. It receives a compact summary over stdio (status, pid, file path, element count, grep hint, and one summary line, usually under 500 bytes), then greps the .txt file on disk for the AX label it wants. The vision model is only invoked after the click, as a sanity check against the screenshot emitted alongside the tree.
Does every April 2026 Notion feature need the same six tools?
Yes, and the six are not Notion-specific. The full list is macos-use_open_application_and_traverse (main.swift line 1301), macos-use_click_and_traverse (1329), macos-use_type_and_traverse (1349), macos-use_press_key_and_traverse (1384), macos-use_scroll_and_traverse (1402), and macos-use_refresh_traversal (1363). These six are defined in ~120 lines of tool declarations. Every Notion April 2026 feature (voice button press, shareable AI chat menu walk, Mute context-menu click, cover-art grid scroll, database tab display toggle, Workers for Agents panel walk) reduces to some combination of those six verbs against the AX tree.
Why does the Server declare version 1.6.0 at main.swift line 1413?
The string '1.6.0' is passed as the version argument to the Server initializer on line 1413 (the line starts with let server = Server(name: 'SwiftMacOSServerDirect', version: '1.6.0', ...)). When an MCP client runs the initialize request, it gets that version back in serverInfo. Fazm shipped the binary at 1.6.0 through the entire April 2026 Notion release wave. The version is structural, not a snapshot: new Notion features change labels and geometry in the AX tree, not the verbs the tools expose.
If I open /tmp/macos-use/ after using Notion through Fazm, what do I see?
A sequence of timestamped .txt files, one per tool call, plus .png screenshots. Example filenames: 1744032517_open_application_and_traverse.txt, 1744032519_click_and_traverse.txt, 1744032519_click_and_traverse.png. Each .txt contains the enriched accessibility tree at that tool call, one element per line in the format [Role] "text" x:N y:N w:W h:H visible. The agent (or a human) can grep these for labels like Voice, Mute, Custom instructions, or Workers to find the nodes that Notion shipped in April. The directory is created by the bundled binary; no permissions setup needed.
Does the grep hint actually appear in every tool response?
Yes. main.swift line 761 is lines.append("hint: grep -n 'AXButton' \(filepath) # search by role or text") inside buildCompactSummary. Every call that returns a tree (open, click, type, press, scroll, refresh) appends this line. The hint is a literal invitation to the agent to use a generic grep tool on the file instead of consuming the tree in context. For Notion's April wave, that means a 14 KB tree of Notion 3.4 Part 2 does not burn 14 KB of agent context. It burns roughly 300 bytes of summary, then a targeted grep for the label the user asked about.
What happens when Notion ships more releases in May or June 2026?
The same six tools in the same 1,917-line file will reach them without a binary change, for the same structural reasons. Notion's macOS Electron shell continues to expose new rendered controls to the AX tree automatically. The tool verbs remain open/click/type/press/scroll/refresh. The noise filters remain role-based. The grep hint remains in the response summary. The only thing that changes is the Notion release note and the labels on the tree. Fazm's mcp-server-macos-use binary does not need a Notion update path because it never had a Notion code path.
Where exactly do I download Fazm to verify any of this?
https://fazm.ai ships a signed and notarized DMG for macOS 14+. After installation, the binary lives at /Applications/Fazm.app/Contents/MacOS/mcp-server-macos-use. You can run it directly with a JSON-RPC initialize + tools/list over stdio and get back serverInfo { name: 'SwiftMacOSServerDirect', version: '1.6.0' } plus the six tools. The source of truth for everything above is the MIT-licensed mcp-server-macos-use repo, which Fazm builds and bundles.
Adjacent anchors in the same codebase
Keep reading
Notion updates April 2026: the 6-tool surface
The same binary, viewed from the tools side. Six stable tools reach every April Notion release on day zero.
Accessibility API vs. screenshot agents
Structured text vs. probabilistic pixel reads, compared turn by turn.
Notion update April 2026 release notes
Plan tiers, the Custom Agents trial ending May 3, and what the API does and does not expose.
Eleven Notion releases. One response shape. Zero Notion code.
The April 2026 releases are real. The reason a Fazm agent keeps reaching them without a binary update is that the tool response was never the tree. It was a pointer to a file, plus a grep hint.
Download Fazm
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.