Anthropic Claude, April 2026, read from a Mac that sends accessibility trees, not screenshots

A quiet but dense month. Claude Sonnet 4.6 stayed the default for speed-sensitive workloads. Opus 4.7 went GA on April 22 at $5 input and $25 output per million tokens. The Agent Client Protocol SDK pushed to 0.25.0 on April 7 and to 0.29.2 on April 20. The credit-exhaustion and rate-limit error shapes were reshaped mid-month, which is why several downstream desktop apps shipped small patches the same week. No banner announcement, but a steady drip of changes at the edges of the API. The Fazm repo ended April with 10 tagged releases covering those exact edges.

Because the API is only half the story on macOS. Claude is doing the reasoning, but the app has to deliver clean screen context for Claude to reason about, and has to route Claude's clicks back to real UI elements. If you send pixels, Claude runs OCR and guesses coordinates. If you send accessibility trees, Claude gets structured text with stable refs and is simply better at the task. The smarter Claude gets, the more leverage the input format has. Opus 4.7 on a screenshot-based pipeline still has to squint at the same pixel blobs.

It is testAccessibilityPermission in Desktop/Sources/AppState.swift, at lines 431 through 504. Layer 1, line 441: AXUIElementCopyAttributeValue against the frontmost app's kAXFocusedWindowAttribute. If that returns success, noValue, notImplemented, or attributeUnsupported, the permission is fine. If it returns apiDisabled, the permission is off system-wide. If it returns cannotComplete, that is ambiguous: it can mean our permission is broken, or it can mean the frontmost app just does not implement AX (Qt, OpenGL, Python-based apps like PyMOL). Layer 2, line 468: confirmAccessibilityBrokenViaFinder retries the same call against Finder, a known AX-compliant app. If Finder also fails, the permission is truly broken. If Finder succeeds, the original failure was app-specific and our permission is fine. Layer 3, line 490: if Finder is not even running, probeAccessibilityViaEventTap calls CGEvent.tapCreate with a listen-only mouseMoved tap. Tap creation checks the live TCC database, unlike AXIsProcessTrusted(), whose per-process cache can go stale on macOS 26 Tahoe. Three layers, one boolean.

Because it lies. On macOS 26, AXIsProcessTrusted caches the 'granted' result inside our process, and after certain OS updates, app re-signs, or TCC database rebuilds, the cached answer stays 'granted' even though real AX calls fail with apiDisabled. We hit this exact class of bug enough times that the fix had to stop trusting the cache. The event tap probe is the tiebreaker because CGEvent.tapCreate bypasses the cache and asks the kernel live.

The connection is the screen-context pipeline. Every piece of April news, Sonnet 4.6 settling in, Opus 4.7 GA, ACP 0.25.0 then 0.29.2, tightened error handling, makes Claude faster and more capable at reading UI and acting on it. But on a Mac, Fazm can only deliver the accessibility tree to Claude if the permission check succeeds. If the probe is naive and the TCC cache is stale, Fazm reports permission-granted to the user while every AX call silently fails, the tree is empty, and Claude gets zero signal. The smartest Opus model in the world cannot help an empty payload. The three-layer probe is what lets an April news item translate into real behavior on a user's machine.

On typical focused-window traversals we see a text payload in the low single-digit kilobytes. A PNG screenshot of the same window at 2x Retina is usually 500 KB to 2 MB before base64 encoding, which then inflates it by roughly a third. That is a 100x to 1000x difference in tokens. When Opus 4.7 runs at $5 input per million tokens, the pricing alone justifies the format. The larger win is accuracy: Claude receives labeled elements with roles, titles, frames, and focus state, so it can name the thing it wants to click instead of guessing coordinates.

Layer 2 is what saves us. testAccessibilityPermission will hit cannotComplete against the game. The naive response would be to flip isAccessibilityBroken to true and harass the user to re-grant permission. Instead, confirmAccessibilityBrokenViaFinder retries against Finder. Finder always responds, so if Finder succeeds, we know our permission is fine and the game was the problem. The user keeps working without a single false alarm. This exact branch fires routinely for users running PyMOL and certain Qt apps.

No. The probe lives at a different altitude than the model news. Sonnet 4.6 and Opus 4.7 care about the payload; ACP bumps care about the wire format; the permission check cares about macOS TCC. That is exactly why the probe stayed stable while the rest of the stack flexed through 10 tagged releases in 17 days. The design intent is that Anthropic model news never lands in this file.

Yes, easily. Run Fazm, then tail /tmp/fazm-dev.log and look for ACCESSIBILITY_STARTUP and ACCESSIBILITY_CHECK log lines. They are emitted from AppState.swift lines 237 and 450 respectively. Revoke Accessibility for Fazm in System Settings while the app is running and the log will immediately print either apiDisabled or a cannotComplete line followed by the Finder retry. Re-grant permission and the log prints TCC=true, broken=false on the next startup check.

It is if your app talks to Claude Code behind the scenes. ACP is how the Claude Code runtime communicates with client surfaces. Fazm uses it because the Fazm desktop app is an ACP client that wraps the Claude Code agent, which means ACP bumps land on us directly. If your product talks to Anthropic's public Messages API only, the ACP bumps are invisible. If you bridge to Claude Code, every ACP minor version can reshape the error payload shape, which is why a seven-line substring guard ended up more important than any model version bump.