OpenRecord — MyChart for Claude

OpenRecord — Claude Desktop Extension

A Claude Desktop Extension (.mcpb) that gives Claude access to your Epic MyChart patient portal. Read your medications, lab results, imaging, messages, billing, and more — or send a message to your care team, request a refill, and manage emergency contacts — all through a natural conversation.

Install

cd claude-desktop-extension

bun install bun run pack # builds dist/server.cjs and produces openrecord.mcpb

Then double-click openrecord.mcpb (or drag it into Claude Desktop → Settings → Extensions).

Use

After installing, open a new Claude chat and say:

Set up my MyChart.

Interactive widget (recommended)

In Claude Desktop, Claude shows an inline step-based setup widget (get_setup_widget). It opens on a choice between two routes, and connects accounts one at a time: nearly every portal asks for a 2FA code, so each account runs to the end before the next is offered. The full flow is diagrammed in docs/mcpb-setup-flow.md.

Import from your browser (the easier one):

1. Permission — a screen saying what the scan reads, that passwords stay on this machine, and that macOS will raise its own keychain prompt. Nothing is read until Allow and search my browsers is clicked; that runs import_browser_passwords (and list_accounts, to mark logins already connected).
2. Pick one login — the confirmed MyChart logins, one to choose ("you can import more after this one"). One already connected, or saved without a username, is shown but can't be picked. The widget only ever holds import ids, never a password.
3. Connect it — connect_imported_account, then the same 2FA and passkey steps as below. If the saved password is stale, it becomes the manual sign-in step with the username filled in.

Enter manually:

1. Pick a health system — an autocomplete dropdown over the full MyChart directory. Results appear only once you type (no default list); each shows the system's banner logo. A portal the directory lacks can be reached by typing its web address, which adds a "Use " row. Search test, springfield, or fake-mychart to find the Springfield General Hospital (test) entry, which points at the fake-mychart.fanpierlabs.com sandbox (Homer Simpson fake data, no real credentials needed — sign in with homer / donuts123).
2. Sign in — the chosen system's logo sits above username + password fields. Submitting runs the real login scrapers via setup_account. Validation/login errors show inline beneath the button.
3. Two-step verification — shown only if setup_account reports the portal requires a code; entering it calls complete_2fa.
4. Set up a passkey? — shown after login only when the account has no passkey saved. It explains what a passkey changes (no password or code when the session expires), where the private key is stored (the server's live answer — keystore or the file fallback — not a promise), that it adds a credential to the MyChart account until removed, and that some portals refuse registration. Set up passkey calls register_passkey; Skip for now finishes without one, and the message handed back to the chat says which happened so Claude doesn't offer again.

After every account, either route lands on one list: the accounts connected so far, then Connect for another imported login (while any are left), Enter an account manually, and I'm done, which sends one message to the chat naming the connected accounts and how each passkey offer went.

A call that outruns Claude Desktop's timeout comes back parked (see pending-call.ts) — most likely the scan, waiting on the keychain prompt. The note carries the call's id as structuredContent.pending_call.id, and the widget waits it out with check_pending_call rather than showing the note.

The widget is a small React app in src/setup-widget/: flow.ts is the whole flow as a reducer (every tool result is interpreted there, and unit-tested), host.ts is the MCP Apps JSON-RPC bridge, and the .tsx files only render. scripts/bundle-setup-widget.ts bundles it with esbuild, and a tsup plugin inlines the result into dist/server.cjs as the virtual:setup-widget module, so the resource is still one self-contained HTML page.

Logos. MyChart's only per-instance brand asset is the wide banner logo

(media.epic.com, ~640×230), so the widget uses it everywhere — a

banner-shaped slot in the dropdown and a banner above the inputs on the

sign-in / 2FA steps. Square favicons aren't used: ~half of instances are

multi-tenant (many orgs share one host, e.g. 200+ on mychart.ochin.org) and

favicons are per-host, so they can't distinguish those orgs; most are also

just the generic Epic icon.

That host has to be named in the widget resource's _meta.ui.csp

(SETUP_UI_RESOURCE_META in src/ui.ts): the MCP Apps host builds the

sandbox CSP from that declaration and every directive defaults to 'none',

so an undeclared origin — data: included — renders as a broken image.

Tool-call fallback

Without the widget (Claude.ai web, other MCP clients), Claude walks through the same setup sequence using ordinary tool calls:

1. `search_mycharts` — Claude asks you for your health system name (e.g. "uchealth", "mass general") and looks up the hostname. Searches Epic's live directory, falling back to the list bundled with this build when it can't reach it.
2. `setup_account(hostname, username, password)` — Claude asks you for your credentials in chat, then logs in. Credentials are stored locally in ~/.openrecord-mcpb/ on your machine. Never sent to Anthropic.

Or skip typing a password entirely, if your browser already has one saved:

• `import_browser_passwords` — scans this machine's browser password stores (Chrome, Arc, Brave, Edge, Firefox) for MyChart logins. Read-only; on macOS it raises the system keychain prompt, which is where you consent. Only accounts it can confirm are offered — a known Epic instance, or one whose login page it verified. No passwords are returned — each entry carries an opaque import_id, and the credential stays on your machine. A login saved in more than one browser is one entry, even when the browsers hold different passwords.
• `connect_imported_account(import_id)` — connects the one you picked, using the password already in your browser (each saved password in turn, until MyChart accepts one). Same 2FA and passkey flow as setup_account.

Anything it cannot confirm is left out rather than guessed at — use setup_account for those, or run the import again later if a portal was temporarily unreachable. See read-local-passwords/README.md for what is read and how confirmation works.

1. `complete_2fa(pending_id, code)` — if MyChart requires 2FA, Claude asks you for the 6-digit code.
2. `register_passkey(account)` — recommended, and never automatic. Logging in changes nothing about how your account signs in; Claude offers you a passkey afterwards and registers one only if you say yes. With one, future logins skip the password and the 2FA prompt entirely. The private key is stored in your OS keystore (the Keychain on macOS — see Architecture) and never sent to Anthropic; the credential itself lives on your MyChart account until you remove it with delete_passkey or disconnect_account.

After setup, every data tool takes a required account parameter — the account id returned by list_accounts, username@hostname. Multiple accounts can be active at the same time — just pass a different account per call. That includes several logins on the *same* hostname (a household sharing one health system): each keeps its own credentials, passkey, and session. An id resolves only on a perfect hostname + username match; there is no hostname-only shorthand, so a call can never land on the wrong login.

The data tools are not listed anywhere in this package. They are generated from the shared capability registry (shared/capabilities/), which is also what the CLI and the mobile app derive their surfaces from — so this extension cannot quietly support less than they do. registerAllTools hand-writes only the five account-management tools above, which manage credentials on this machine and have no counterpart in the other clients.

What's my next appointment at uchealth?

Refill my lisinopril (use my mass general account).

Send a message to Dr. Smith asking about my latest blood pressure reading.

Show me my last imaging study.

Google Calendar sync (macOS)

connect_google_calendar puts every connected account's upcoming appointments on a Google calendar and keeps them there. The setup widget offers it after I'm done when the accounts have appointments to sync; otherwise ask Claude to "sync my appointments to Google Calendar".

• Scope. The only Google scope requested is calendar.app.created: OpenRecord creates a "MyChart Appointments" calendar and can see and change only that one. It never reads the user's other calendars.
• All TypeScript, one binary. src/google-calendar/worker.ts is compiled with bun build --compile --aot into openrecord-calendar, one binary per Mac architecture, using this extension's own scrapers, credential store and passkeys: tray (the menu-bar item), connect (loopback + PKCE consent in the browser), sync (one pass) and disconnect.
• The menu-bar item (tray.ts) drives AppKit through bun:ffi (objc.ts). [NSApp run] owns the main thread, and menu clicks, timers and wake notifications call straight into JS, so the process sleeps in the run loop while idle (0% CPU, about 80 MB). A sync runs as a child process of the same binary, started with NSTask, and writes its outcome to the state file the menu reads. It syncs when 4 hours have passed since the last sync, checking every 15 minutes and 30 seconds after a wake (once Wi-Fi is back), because a timer's clock stops while the Mac sleeps. Its icon is the medical cross (cross.case; macOS has no hospital symbol). The menu lists the connected MyChart accounts and has Sync Now, Open Google Calendar and Turn Off Calendar Sync.
• Signing in to MyChart. A sync signs in with machineLogin (resolveSessionWithoutUser), so it never makes MyChart send a 2FA code: nobody is there to type one. An account that has only a password and hits 2FA fails with a hint to save a passkey. See docs/login-modes.md.
• When a sync fails, three tries, then stop. Any failure counts: a sign-in MyChart refuses, a network error, Google, or a run that crashed or hit the 10-minute timeout. A failure is retried at the next four-hour sync. The third failure in a row stops scheduled syncs, for that account or, when the failure came before any account (Google, a crash), entirely. Repeated rejected passwords can lock a MyChart account. Then macOS shows a notification, once per stop (posted with osascript, since UNUserNotificationCenter refuses a binary that isn't an app bundle), and the menu says why. Sync Now retries everything with the count reset to zero, and so does connecting again.
• Install. The binaries are not in the .mcpb, which would be ~200 MB bigger. deploy.sh uploads them beside it as https://openrecord.fanpierlabs.com/calendar/openrecord-calendar-darwin- - . Content-addressed names make them immutable, so every released bundle keeps finding its own. What ships is applet/calendar-binaries.json, the SHA-256 per architecture. On first connect the tool downloads the matching binary and installs it at ~/.openrecord-mcpb/bin/openrecord-calendar only if the