Morning after an OS update

macOS updates are optimistic about your week. They rearrange permissions, bounce long-lived daemons, and occasionally forget that you already granted Full Disk Access last quarter. Your terminal tabs do not survive. Neither does the quiet assumption that yesterday’s tray state is still true.

After an OS update, the board is the source of truth — not the coffee-machine memory of “everything was fine before I clicked Restart.”

What actually breaks

Not every update is catastrophic. The failures cluster:

Permissions reset or re-prompt. Accessibility, Full Disk Access, screen recording (for Mesh Screen), and notification prompts can reappear. Without them, parts of Rig or helpers look “broken” when they are blocked.
Long-lived processes die. Queues, Vite, Docker Desktop, Herd/Valet helpers, and the MCP hub do not magically resume because the kernel came back.
Ports reshuffle. Something else claims 3000 while you were offline. Yesterday’s bookmark lies.
Hub / editor links go stale. Cursor or Claude still point at a hub port that moved or a hub that is not running yet.
Docker / PHP / Git path quirks. Tooling that lived in a login shell may need a nudge; Setup diagnose exists for that class of “binary missing after update.”

None of this is unique to Rig. Rig just makes the aftermath visible in one place instead of six tabs and a Slack thread titled “is it just me.”

The recovery ritual (do this in order)

Open Rig before you open the project in the editor. Let the control plane start. Do not assume the menu bar icon from yesterday means the hub is healthy today.
Start the group you actually use. Prefer the named group over ad-hoc script clicks so start order and health gates still apply.
Read red items first. Attention board before email. Crash loops and failing health checks after a reboot are common; fixing the database container before the API saves an hour of fake app debugging.
Re-approve macOS permissions if prompted. Full Disk Access / Accessibility are not optional folklore — if macOS forgot, grant them again and relaunch what needed them.
Check Docker Desktop (if you use managed DB containers). A green Rig row cannot invent a daemon Docker has not started yet.
Re-link or restart the MCP hub if editors fail tool calls. Open Connections, start the hub, confirm the editor config still matches. Project-scoped tokens still apply; do not paste a new shell “just to get unblocked.”
Confirm ports and URLs. If Live Link or LAN share was mid-flight overnight, stop the share deliberately — do not leave a preview hanging because the Mac rebooted under you.

What not to do

Do not assume the tray survived. Menu bar presence ≠ healthy projects. Click in.
Do not kill -9 randomly. After updates, the wrong pid is easy to hit. Use reclaim / restart from the board so the supervision story stays coherent.
Do not redeploy to “fix” a local stack. The failure is almost always local process or permission state.
Do not blame the app first when diagnose lists missing PHP/Docker/Git. Fix the checklist, then re-test the project.

How Continuity and catalog sync fit (and do not)

If you use Rig Cloud, catalog metadata and Continuity backups can make a second Mac feel familiar. They do not replace re-granting OS permissions on *this* Mac after an update. Encrypted setup sync is not a kernel permission grant.

If you stay local-only, you are not behind — you just own the recovery ritual yourself. Either way, source code was always on disk; the update did not “lose the repo.” It lost process state.

Agents the morning after

Tell Cursor or Claude the Mac rebooted. Ask for status and health before asking for a refactor. A good first prompt is closer to “what is running and what is red?” than “why is checkout broken?” Scoped MCP tools can restart a dead sidecar; they should not invent a second Vite because the first one is still starting.

If the hub itself is down, fix Connections first. Tool call failures after an OS update are often transport, not application logic.

A short checklist you can paste into a sticky note (then delete)

After any major macOS update:

[ ] Rig open, group started
[ ] Attention board clear or understood
[ ] Permissions re-granted if prompted
[ ] Docker / Herd / Valet up if the stack needs them
[ ] MCP hub running; editor linked
[ ] Ports match bookmarks; stale shares stopped
[ ] One successful health pass on the critical path (API + DB, or WP + MySQL, etc.)

When that list is muscle memory, convert it into a Rig group and health checks so the sticky note can die. That is the same argument as Sticky notes are not a control plane — updates are when the note fails you.

When it is still broken after the ritual

Run Setup diagnose and read the checklist before rewriting application code. Reclaim stuck ports explicitly. If Mesh Screen or Wake misbehave, confirm permissions and that a second Mac exists on the network for wake — one lonely Mac cannot be woken by folklore.

If the Mac app itself will not start, check the status page mindset from Status page, Mac still fine: cloud status and local app health are different planes.

Yesterday’s tray state did not survive. The board did — once you open it and tell the truth about what came back.

https://userig.app/blog/morning-after-an-os-update