What

A freshly connected Apple Calendar listed nothing on macOS 26 even though the permission popup was accepted. The native events route returned HTTP 500 on every poll, so users re-clicked "Connect" in a loop.

Root cause

macOS 26's static +[EKEventStore authorizationStatusForEntityType:] keeps returning a non-FullAccess value (e.g. Not Determined) for minutes after an in-process grant. request_access() returns granted = true, but each read rebuilds a fresh EKEventStore, re-checks that stale static status, and hard-fails with AuthorizationDenied. So GET /connections/calendar/events 500s and the UI shows no events until the OS cache refreshes or the app relaunches.

Confirmed from a user log bundle: request_access succeeded repeatedly while the native calendar route 500'd both before and after each grant. The Google Calendar route returns 401 when unauthenticated, so it was ruled out of those 500s. v2.5.x already resets the store inside calendar_authorize, but that instance is dropped and every read builds its own fresh store that hits the same stale static status.

Fix

• Remember a successful grant in-process (ACCESS_GRANTED_THIS_SESSION).
• Read gate: FullAccess reads; Denied / Restricted block; anything else with a grant seen this session calls reset() + refreshSourcesIfNecessary() and reads anyway instead of failing.
• Add refreshSourcesIfNecessary() to the read path (the eventkit fork only refreshed on write paths, so a brand-new read store could return stale data even when fully authorized).
• Bump macOS calendar read logging debug to info / warn and log the live auth status on failure (Windows already did this), so the next occurrence is visible in logs instead of silent.

Files

• crates/screenpipe-connect/src/calendar.rs (read gate, session flag, refresh, logging)
• apps/screenpipe-app-tauri/src-tauri/src/calendar.rs (publisher gate, for meeting auto-naming)

Verification

• cargo check -p screenpipe-connect passes clean.
• The app-crate hunk is a 2-line gate change calling the new pub fn access_granted_this_session(). src-tauri is not a member of the root cargo workspace, so it was not separately compiled here.
• Needs on-device confirm (macOS 26): revoke Calendar in System Settings > Privacy, reconnect in-app, and events should list immediately without a relaunch. Watch for the new calendar: fetched N events and "granted this session, reading anyway" log lines. If it is still empty until relaunch, the data layer (not just the status cache) is gated, and the right follow-up is a "restart to finish connecting Calendar" prompt instead.

Notes

• calendar_status can still report "not connected" during the stale window, but the meeting-notes list does not depend on it (it falls back to a successful events fetch), so events still appear.
• The flow image lives in .github/pr-media/ (matching the existing PR-media convention). Drop the second commit if you would rather not keep it in tree.

🤖 Generated with Claude Code