How to use Claude Code to file every meeting into your notes, automatically

Claude Code is Anthropic's assistant that lives in the Terminal, the black window with the blinking cursor that most sensible people avoid. Stay with us, because the trick of this guide is that you won't write any code. You'll ask Claude Code to build the automation for you, and then check its work.

What you'll have at the end: the moment Weeve finishes summarising a meeting, a tidy note appears in your notes folder (Obsidian, or any app that reads Markdown files) with the date, title, attendees, and notes, and your action items copied into one running to-do file. Not on a schedule. Within seconds of the summary being ready, powered by a small helper that macOS itself triggers whenever your meetings folder changes.

This is the guide for readers who want the fastest, most self-sufficient version of a Weeve automation and are willing to touch the Terminal twice to get it. (If "Terminal" is a hard no, our Claude Cowork guide gets you most of the way with none of this.)

What you need

The Claude Code app installed (Anthropic's site has a one-line installer, and a Claude subscription covers it), Weeve with auto-generate summaries turned on, and a notes folder, say ~/Notes/Meetings.

Step 1: Give launchd a folder it is allowed to watch

In Weeve: Settings → Data & Storage → Change folder. Create a folder called Weeve in your home folder and pick it. Every meeting then lives at Weeve → Users → (one long-named folder, your account) → Recordings, one small file per meeting.

This step is not housekeeping, and it is the reason this guide starts here rather than at the automation. Weeve's default location sits inside ~/Library/Application Support, and macOS treats that path as protected. A launchd job watching a folder in there runs into permissions problems that are tedious to diagnose, because the failure is silent: the job is registered, the file changes, and nothing happens. Moving the library to your home folder sidesteps the whole category of problem before it starts.

Open the folder in Finder once, just to see it. Those files are what everything below reads.

Step 2: Ask Claude Code to build the automation

Open Terminal (press Cmd-Space, type "Terminal", press Enter), type claude, and press Enter. You're now chatting with Claude Code. Paste this. It's a description of what you want, not code:

Build me a macOS automation with these pieces:

1. A small script that looks through every file in
   ~/Weeve/Users/<the-long-folder-name>/Recordings/.
   Each file is a meeting: it has "title", "recordedAt", "summary"
   (Markdown notes), "speakers" (names under "label"), and
   "summaryStatus". Only act on files where summaryStatus is
   exactly "ready", because Weeve rewrites these files several times while
   processing, and only "ready" means finished. Keep a list of
   already-handled meeting ids so nothing is ever processed twice.

2. For each new finished meeting, write a note to ~/Notes/Meetings
   named <date>-<title>

Build me a macOS automation with these pieces:

1. A small script that looks through every file in
   ~/Weeve/Users/<the-long-folder-name>/Recordings/.
   Each file is a meeting: it has "title", "recordedAt", "summary"
   (Markdown notes), "speakers" (names under "label"), and
   "summaryStatus". Only act on files where summaryStatus is
   exactly "ready", because Weeve rewrites these files several times while
   processing, and only "ready" means finished. Keep a list of
   already-handled meeting ids so nothing is ever processed twice.

2. For each new finished meeting, write a note to ~/Notes/Meetings
   named <date>-<title>

Build me a macOS automation with these pieces:

1. A small script that looks through every file in
   ~/Weeve/Users/<the-long-folder-name>/Recordings/.
   Each file is a meeting: it has "title", "recordedAt", "summary"
   (Markdown notes), "speakers" (names under "label"), and
   "summaryStatus". Only act on files where summaryStatus is
   exactly "ready", because Weeve rewrites these files several times while
   processing, and only "ready" means finished. Keep a list of
   already-handled meeting ids so nothing is ever processed twice.

2. For each new finished meeting, write a note to ~/Notes/Meetings
   named <date>-<title>

Claude Code will write the script, explain it, create the trigger, and ask permission before installing anything. Read what it proposes; approve it. This is the honest division of labor in 2026: you describe the outcome and the safety rules, the AI handles the plumbing, and everything it builds sits on your Mac in plain text where you (or any developer, or Claude itself) can inspect it later.

Step 3: Test it

Record a ten-second meeting in Weeve. Say something with a task in it: "Note to self, send Marloes the proposal Tuesday." Stop, wait for the summary to finish, and watch your notes folder. A new file should appear within moments, and your Inbox file should have gained a checkbox.

If nothing happens, tell Claude Code exactly that ("the note didn't appear, here's what the meeting file looks like") and let it debug its own work. It's good at that.

Why launchd, and not a schedule

Every other way of connecting Weeve to something else polls. A scheduled job wakes up every fifteen minutes, or every hour, looks for new meetings, and goes back to sleep. That is fine, and it is what most of these setups do.

This one does not. launchd is macOS's own service manager, and it can watch a folder and fire the moment something inside it changes. The practical difference is the gap between a meeting ending and the note existing: seconds rather than up to an hour. You walk out of a call, switch to your notes app, and it is already there.

The cost is that event-driven jobs are noisier than scheduled ones. Weeve rewrites a meeting file several times while it processes, so a naive watcher fires repeatedly for one meeting. That is what the summaryStatus rule and the cooldown in the prompt are for, and it is why both are stated explicitly rather than left to the model to infer.

When it breaks, and it will once

Two failures account for almost everything, and neither announces itself.

The job is not registered. Run launchctl list | grep -i weeve in Terminal. If nothing comes back, the job never installed, whatever the transcript said. Ask Claude Code to install it again and watch for the permission prompt.

The job is registered but silent. This is the common one, and it is nearly always the folder path. If the library is still in ~/Library/Application Support, or you moved it after the job was built, the watcher is pointing at somewhere nothing changes. Ask Claude Code where its script thinks the Recordings folder is, and compare that with what Weeve's Settings pane shows.

When you ask Claude Code to build this, add one line to the prompt: have it write a log file to ~/Weeve/automation.log recording every meeting it handled and every one it skipped, with the reason. Ten seconds of prompt, and the difference between debugging this in two minutes and giving up on it.

How to switch it off

Worth knowing before you install anything that starts itself. launchctl bootout gui/$(id -u)/<the-job-label> stops and unloads it, and deleting the .plist file from ~/Library/LaunchAgents removes it permanently. Ask Claude Code to tell you the exact label and file path at install time and write them down. An automation you cannot confidently remove is one you will end up living with.

Why this design is worth having

Three properties make this setup better than most off-the-shelf integrations. It's instant: macOS notices the file change and fires the script within seconds, no polling, no half-hour waits. It's transparent, since every piece is a readable file on your Mac and the script keeps a log of what it handled. And nobody can discontinue it, because there's no company in the middle and no subscription beyond Claude itself.

Once it works, extend it by asking. "Also file notes into a subfolder per project." "If a meeting mentions a date or deadline, add it to a Deadlines file." "Draft a follow-up email for any external meeting and save it to Drafts." Each is one more conversation with Claude Code, not a rebuild.

The privacy line, drawn clearly

Weeve records, transcribes, and summarises entirely on your Mac. That never changes. And here's the quiet advantage of this particular setup: the automation Claude Code builds is an ordinary script, so once it's installed, the filing loop runs entirely on your Mac too. No meeting content goes anywhere at run time; the prompt above forbids it explicitly. The one cloud touchpoint is the building and debugging itself. While you're describing the automation to Claude Code, and especially if you paste a meeting file to help it debug, that text goes to Anthropic's servers. Build and debug with a throwaway test meeting rather than a real client call, and even that touchpoint stays harmless.

Two visits to the Terminal, one honest conversation about what you want, and the gap between "meeting ended" and "notes filed, tasks captured" drops to zero. Permanently.

If this one is not the right fit

This is the most technical of the five ways to connect Weeve to something else, and it buys you the fastest and the most self-sufficient result. It is not the right pick for everyone.

If the Terminal is a hard no, Claude Cowork does the weekly-review version entirely in a normal app window. If you want the outcome to reach your phone in the evening rather than land in a folder, Hermes sends a nightly digest through Telegram or Signal. If you want the filing without building anything yourself, OpenClaw does it on a heartbeat with no launchd involved. And if you mostly want to ask questions of past meetings rather than file them anywhere, Codex is the smaller setup.

Filing is the first half. For what happens when those filed notes start compounding into something the whole company reads, see how we built an AI company brain at Weeve.

If you do not have the recording half yet, Weeve's free Starter plan covers 10 meetings a month and writes the transcript and summary on the Mac, which is what this whole setup reads from. It needs Apple Silicon and macOS 14 or later. On any other machine there is no local library to point Claude Code at, but the browser transcriber will still turn a recording you already have into a transcript inside the tab.