The three things I said I would send you at the end of our 1 September session. Cloud scheduling, your other email accounts, and Granola. Each one is a short sequence you can run on your own, with the prompts already written.
Open a fresh Claude Code session in your vault, name it after the runbook, and work down the page. One runbook per session, then /wrap and close it. That is the archiving habit we talked about, applied to setup work.
Sonnet is fine for all three. If something goes sideways and you want it to actually diagnose rather than guess, switch to Opus on medium thinking and paste the error in.
Where this actually stands. Two of the three layers are already fixed. Your Mac points at the RemixSystems address, you confirmed that live in the session. You are an admin on RemixSystems/kristin-vault, I confirmed that again this morning. So the repo is right and your access is right.
The Claude GitHub app is what authorizes a cloud routine to write back to your vault. When we tried to install it on the RemixSystems organization it came back asking for a Claude Team or Enterprise plan. Organization installs are gated behind those plans. Your plan is a personal one, and so is mine.
That gate is the whole remaining problem. Nothing on your machine is wrong.
What I recommend, and it is the thing I would want anyway. Move the repo out of my organization and into your own GitHub account, kmsteele8, with me added back as a collaborator. The app installs against a personal account with no plan gate, cloud routines start working, and you end up owning your own vault outright. That was always the destination. This just gets there sooner.
The trade. You become the owner, so the repo shows in your account and you carry the backup. I keep collaborator access so I can still push fixes. You can remove me at any point with two clicks, and nothing in your vault breaks when you do.
The alternative is that I move Remix Systems onto a Claude Team plan so the org install is allowed. That costs money every month, it buys you nothing you do not get from owning the repo, and it leaves your vault in my account. I would not do it.
A transfer is not something I will start on my own. Reply to my email and I will kick it off. GitHub will email you an invitation to accept, and it takes about a minute.
Step 1, after you accept the transfer. Your Mac is still pointed at the organization address, so repoint it.
My vault repo has moved from the RemixSystems organization to my own GitHub account, kmsteele8. Update the git remote to the new address, verify a push works, then show me the address you ended up with.Step 2, install the GitHub app. This one is clicks, not a prompt, because it happens in your browser. In the Claude app go to Settings, then Connectors or GitHub, and install the Claude GitHub app on your kmsteele8 account. When it asks which repositories, choose only select repositories and pick kristin-vault. Do not grant it your whole account.
Step 3, prove it runs in the cloud.
Set up a cloud routine that runs my daily brief at 6:30am Mountain time. Then trigger it once right now and show me the result, including whether it ran on Anthropic's servers or on this Mac. I want to see the difference.Step 4, the one that was the point of all of this. Once the brief runs in the cloud it no longer cares whether your Mac is awake, which also closes the sleeping-machine problem and the brief landing in the evening.
Move my morning brief and my nightly recap off local scheduling and onto cloud routines, then list everything still scheduled locally and tell me whether each one needs to be.If step 3 still returns a 403, stop and send me the error rather than working around it. That would mean the app installed but did not attach to the repo, which is a two minute fix on my side.
Your Multi-Account Google Connectors note from 7 September is right, and it is better research than I would have handed you. Claude keys MCP tokens by server URL alone, Google's hosted endpoints are one fixed URL each, so every account after the first collides by construction. You verified it against the closed Anthropic issue rather than taking a research agent's word for it, and you caught that one of the cited bugs was already fixed. That is the correct instinct and it is the whole reason this works.
You also landed on the same fix this runbook uses, one self-hosted instance per account on its own port, which is exactly why it works. So this page is not a counter-proposal. It is the setup steps for the thing you already decided, and the installer below is what keeps five processes alive without you babysitting them.
The connector you have now is the single-account kind. What you want is the setup I run, one small always-on server per account, which is why I can say "use my Velare email" and it knows which one. Same thing here, one line per account.
On your half-day estimate. Fair for building it from scratch. It should be shorter with the installer, because the part you budgeted 30 minutes for, keeping five processes alive across crashes and reboots, is already written. The installer registers each account as a launchd service that starts at login and restarts itself. That is the piece that turns this from five terminal windows into something you forget about.
Your list, and what each one actually takes.
| Account | What it needs |
|---|---|
kjsteelio@gmail.com | Already connected. Nothing to do |
kristin.m.steele@gmail.com | One line, one consent click. Do this one first |
kristin@doozysolutions.com | A Workspace domain, so Doozy IT may have to allow the app. Try it, and if consent is blocked that is what happened |
mpatreasurer@mullenhigh.com | Needs your acting treasurer for the verification codes, and possibly Mullen IT. Worth doing, but not on the same afternoon as the others |
president@skinnermspto.com | You found the real address on 5 September. This is the one you actually want working, so make it the second account after your own |
kmsteele8@yahoo.com, kmjorge@yahoo.com | Not Google. Use the Claude app's own mail connector, which is a different and much shorter path |
kj@steelio.net, kristin@steelio.net | Depends who hosts them. If it is Google underneath they join the list below, if it is the old POP3 host they do not connect at all |
| Klugo | Out, by your call on 14 August |
Step 1, the one part that is clicks. You need a Google OAuth client of your own, so the tokens belong to you and you can revoke the whole thing without asking me. Ten minutes in the Google Cloud console, signed in as kjsteelio@gmail.com.
Kristin Vault.~/.config/google/.If a screen looks different from that, screenshot it and send it over rather than guessing. Google moves this console around constantly.
Step 2, write the accounts file.
Create ~/.config/google/gws-accounts.conf. One line per account in the format: name, port, email, secret filename, separated by spaces. Start at port 8001 and go up by one. Use my client secret JSON in ~/.config/google/ for all of them. The accounts are personal for kjsteelio@gmail.com, kristin for kristin.m.steele@gmail.com, and pto for president@skinnermspto.com. Show me the file when you are done.Start with those three. Adding doozysolutions later is one more line and one more consent click, and the same is true for every account after it.
Step 3, install the servers. The installer is here. Download it into ~/.config/google/ and then run this.
Asking it to read the script back to you first is a habit worth keeping for anything I hand you. It takes ten seconds and it is the honest version of "always allow."
Step 4, point Claude at them.
Add each account from my gws-accounts.conf to my ~/.mcp.json as an http entry pointing at its own port, then tell me to restart my session so it picks them up.Step 5, one consent click each. The first time it touches an account it hands you a Google link. Click it, approve, done. The token lives on your Mac only and never goes near GitHub or near me.
Step 6, prove it.
List every Google account you can now reach. For each one, tell me the sender and subject of the most recent email and nothing else. Do not draft anything and do not send anything.Step 7, clear the wreckage. The gmail-president, calendar-president, drive-president and docs-president connectors you set up last week all point at Google's shared URLs, so they will keep fighting your native connector for the same token slot. Once the servers above are answering, remove them.
Your call on whether kjsteelio stays on the native connector or joins the self-hosted set. I would move it over for consistency once the others are proven, but there is no urgency and nothing breaks either way.
The draft-never-send rule holds across all of them. Adding accounts does not loosen it.
This is the one that closes your original July complaint, copying action items out of meeting emails by hand. Granola listens to your microphone and your system audio, so it has both halves of the call, and the notes land in your vault next to everything else instead of in another inbox.
Step 1, yours, and it has to be first. Create the account at granola.ai using kjsteelio@gmail.com, the account that hosts most of your calendar. Install the Mac app. Connect that calendar when it asks, and your meetings start showing up on their own with a prompt to record.
Free gives you the AI notes and action items. Full transcripts are the paid plan at 14 dollars a month.
Your back history is the reason to decide early. The free tier only keeps a short recent window, so anything older falls off before you get to it. If you want the last month of calls to come across, turn the plan on before the first sync rather than after.
Step 2, record something. Do a real call, not a test. The phone app is worth installing too, for the meetings where you are sitting across a table from somebody.
Step 3, wire it into Obsidian. In Obsidian, open Settings, then Community plugins, then Browse, and install Granola Meetings Simple Sync. Enable it, open its settings, and connect your Granola account. Then set it like this.
| Setting | Value |
|---|---|
| Folder path | 90-Meetings |
| Filename pattern | {date} {title} |
| Sync frequency | 15 minutes |
| Sync time range | Last 30 days |
| Sync transcripts | On, if you are on the paid plan |
| Match attendees by email | On. This is what links a meeting to the person note in 20-People |
| Skip existing notes | On, so a re-sync never overwrites your own edits |
I run a second, heavier sync on my own machine that pulls full transcripts into folders per client. You do not need that yet. If you get to the point where you want transcripts filed by person rather than by date, tell me and I will wire it.
Step 4, make the vault do something with them. A folder of meeting notes is not the win. This is.
Read every new meeting note in 90-Meetings. For each one, pull out what I committed to and what somebody committed to me, add them to my loops with the right lane, and link every person mentioned to their note in 20-People. Show me the list before you write anything.Step 5, the one that earns its keep.
Before my next Doozy call, read every Doozy meeting note from the last sixty days and give me one page. What was decided, what stalled, and the three things I should not leave the call without.Fathom is still on the roadmap and still worth connecting for its back catalogue. Granola is the one that changes your week, so it goes first.
Not runbooks. Things I said I would do, with where each one is.
The rename, which you closed without me. On 3 September you renamed 10-Loops to 10-Tasks yourself, took the command with it so /loops is now /tasks, and left nothing behind but two mentions inside old archived briefs, which are dated records and should stay as they are. That is the whole job, done properly, and it is the clearest sign yet that you do not need me for this class of work.
Loops was my word for it anyway. Tasks is yours, and it is the better one.