Why I built a local MyChart CLI while caring for a NICU baby

I am a little uneasy about turning a hard stretch of family life into a launch story. It is still the honest reason this tool exists.

While we were caring for a medically complex baby in the NICU, the chart kept changing. A new note could land after I thought I had caught up. Test results sat in a different part of MyChart. What I understood yesterday was not always enough for the next conversation.

I wanted a current local copy of the records we could already see. I also wanted to stop rebuilding that context by hand every time I asked a downstream tool for an explanation.

So I built mychart-cli.

What the tool does

mychart-cli opens MyChart in a dedicated Chrome profile and reads records that the signed-in user can already view. It stores the extracted records on the same computer and can export them as Markdown or JSONL.

The distinction between export and explanation matters. mychart-cli does not interpret a lab result. It does not make a diagnosis, recommend treatment, or contact a care team. Its job is to give another workflow fresh, structured source material.

In my case, a separate local workflow used the exports to produce timely explanations while I kept track of a complicated record. The explanation layer was replaceable. The source records stayed visible, inspectable, and under my control.

Why it uses a separate Chrome profile

MyChart authentication is not a normal API integration. MFA, device checks, and portal-specific login pages are common. I did not want the tool touching my everyday browser profile, so it launches a dedicated one.

You can log in manually and complete MFA yourself. The tool then connects to that prepared session. An optional --login path can read credentials from a local environment file, but it only does that when explicitly requested.

The profile is sensitive. It contains authenticated cookies and should be protected like a password. The record store and exports are sensitive too. On macOS and other POSIX systems, mychart-cli creates those files with private permissions.

What local-first means here

There is no mychart-cli backend, account service, telemetry, cloud sync, or built-in LLM.

That is a boundary, not a promise that every possible workflow is private. If you upload an export to another service, the other service can receive the medical data. Its retention and privacy terms apply. mychart-cli cannot change that.

I wanted the default path to be simple: records stay on the computer until the user deliberately does something else with them.

What the beta supports

The first public beta targets macOS, Node.js 20 or newer, and Google Chrome. Epic MyChart deployments vary in markup, routes, and authentication. The tool has a substantial synthetic regression suite, but I do not want to pretend it has been proven against every portal.

It is also unofficial. The project is not affiliated with Epic Systems or any health care provider. Users are responsible for following their portal’s terms and accessing only records they are allowed to view.

Try the synthetic demo

You can inspect the command and its JSONL shape without a MyChart account:

npx @lifan-builds/mychart-cli demo

The demo is deterministic and synthetic. It does not start Chrome, access the network, create a browser profile, or write a record store.

To install the beta:

npm install --global @lifan-builds/mychart-cli
mychart-cli --help

The code and setup guide are at:

https://github.com/lifan-builds/mychart-cli

I expect portal-specific bugs. If you find one, please recreate the shape with invented information. Do not paste records, screenshots, credentials, patient names, dates, or authenticated URLs into a public issue.

That warning makes support a little less convenient. Given what this tool touches, the inconvenience is worth it.