A Wednesday in late April, my hands typed git push from a terminal I was almost certain was Client A's. The lights flickered for a quarter-second behind my eyes. They were not Client A's. The shell was Client B's, the branch was a sandbox, nothing shipped. The flicker was the warning.
I run three to four fractional accounts in a typical week. That arrangement only works if per-switch friction is low and the chance of a mix-up sits near zero. Willpower does not get me there. Patterns do. These are field notes from rebuilding the switchover surface across one workweek, the version that holds up on a bad ADHD day.
entry: 2026-04-29, the lights flicker
Wednesday, mid-morning. I finished a Client A block and was heading into a quick admin pass on Client B's repo. I never closed the Client A tmux pane. The shell prompt looked the same gray it always looks. The repo on disk was Client B's because I had run cd after the switch, but the environment variables and the SSH agent identity were still Client A's. I almost pushed a sandbox branch from the wrong identity.
Nothing broke. But I felt the flicker, and the flicker is the part I take seriously now. The error was not in my attention. My attention had been fine. The error was that the environment was lying to me, and my attention was being asked to compensate for a lie. That is a losing arrangement on a calm day and an unworkable one on a hard week.
Switchover is environmental, not cognitive. If the room does not visibly tell me which client I am inside, I am one stray keystroke away from a real incident.
entry: 2026-04-30, one browser profile per client
I rebuilt the browser first. Until last quarter I ran a single Chrome profile with everything in it. Client A's Shopify admin, Client B's GitHub org, Client C's Supabase, plus my own banking. Cookies fought each other. Autofill suggested the wrong email when I logged into a dashboard. Tabs from one client haunted the second monitor while I was thinking about a different one.
Now there is one Chrome profile per client, plus one for me. Each is named with the alias I use on invoices, not the client's real name, so screen-shares never accidentally surface a billing label. Color, icon, and custom new-tab background differ across all of them. The OS window menu shows a tinted Chrome icon that tells me which world I am in before I read a single tab title.
The bookmark bar in each profile is short. Six entries, sometimes eight. Admin, analytics warehouse, staging URL, the Slack workspace, the GitHub org, the design file. If a tool is not in my top six I open it in a tab and let it close at the end of the block.
The biggest change is what the switch feels like. It is now "open the Client B profile window" instead of "log out of A, clear something, log into B, hope autofill picks the right credentials." Crossing the boundary costs three seconds and produces a window that looks visibly different from the one I was just in.
entry: 2026-05-01, the terminal that tells you who you are
The browser fix was the obvious one because the screen is right in front of me. The terminal had been masquerading as fine for longer because terminals all kind of look the same.
I now run one tmux session per client, named with the same alias the browser profile uses. Each session opens with a working directory pinned to that client's repo root, an environment variable PROJECT set to the alias so any agent run inherits the right scope, and a shell prompt color that matches the browser profile color. Client A's prompt is blue, Client B's is pink, mine is muted green. If I glance at the bottom of the screen and the prompt is the wrong color, my hands stop before they finish a command. That muscle has gotten reliable.
Secret retrieval is scoped per session. Tokens for Client A live in macOS Keychain entries with a client-a-* account tag. The session's shell pulls only those entries on first run via the security CLI, holds them in shell variables for the session's lifetime, and never writes them to disk. When the session ends the variables die with it. No .env file holds everything in one place. I wrote about the broader vault model in the credential management article for multi-client macOS; the per-session retrieval pattern is the consumer side of that vault.
The whole bundle is fronted by a single shell function, switch <client>. One argument, opens the matching Chrome profile, attaches to the tmux session (creating it if needed), prints a one-line status banner with the active client's alias and any pending wind-down note from the previous session. Three seconds, one keystroke. The cost of switching is now lower than the cost of resisting a switch.
entry: 2026-05-02, the vault rules I had to write down
Friday afternoon. I want to be honest about a mistake on Thursday. I needed to check one thing in Client B's Stripe dashboard during a Client A block, and instead of running switch b I just opened a new tab in the Client A profile and signed in. Touch ID approved it because Touch ID does not know which of my client identities is the right one. Five minutes later I had three Client B tabs inside the Client A window and was about to copy a Client B account number into a Client A document.
I caught it. The failure mode was clear, though. The browser profile pattern only works if I follow the rule "never log into Client B from Client A's profile, even briefly." Touch ID approving a sign-in across the boundary is the moment the boundary stops being a boundary. The vault has to enforce the rule that my hands forgot.
I wrote three rules and pinned them above the keyboard.
One vault per client, not one vault for everything. The macOS Keychain has separate access groups per client tag. Cross-project credentials (Cloudflare DNS, Supabase Personal Access Token) live in a single global vault any profile can reach. Client-specific credentials live behind the per-client tag.
Token rotation rides the same cadence as monthly invoices. First of the month I rotate scoped tokens for any client billed last cycle. Fifteen minutes per client when organized; multi-hour reconstruction job otherwise. Pinning rotation to invoicing means I cannot forget without also forgetting to bill.
I do not approve a Touch ID prompt that appears inside the wrong browser profile. If I see a modal asking me to authorize Client B's password vault inside Client A's window, I cancel it, close the window, and run switch b. Five extra seconds save the half-hour of cognitive recovery I would otherwise spend wondering if I had crossed a line.
“Touch ID approving a sign-in across the boundary is the moment the boundary stops being a boundary.
”
entry: 2026-05-03, the morning ritual that picks the active client
Saturday. The morning ritual that wraps all of this is a 10-minute block before any client-facing work touches my eyes.
Coffee on first. No screens for three minutes. Then I open the agent council in my own profile, not in any client's profile, and ask it to read the inbound from each active client overnight and produce a three-bucket triage. The buckets are "respond today," "decide today," "ignore today." The council does the reading. I do the deciding. The output is one short markdown document per client.
I read the three documents and pick the client whose block comes first on the calendar. Then I run switch <that client>. The browser opens to that profile, the tmux session attaches with the right environment, the prompt is the right color, the triage document is the first tab. By the time I am at the keyboard for real work, the room visibly says which client I am inside. The ritual carried the work; willpower was not asked.
If the previous day ended without a wind-down note for the last client, that note is the first thing I write before switching into anyone else. Two sentences, sometimes three. What I shipped, what is still open, what the next session starts with. Two sentences on Friday saves thirty minutes on Monday.
The ADHD-honest part is that the ritual replaces the thing my brain cannot reliably do, which is hold five clients' state in working memory and decide which one to focus on by act of will. The visible color, the named profile, the alias in the prompt, the markdown triage on screen: each is a cue. None require me to remember anything. On a hard day my focus is asked only to follow the cues, not to generate them.
This connects to the infrastructure I described in the post on the practice operating system. The switchover patterns are the terminal-and-browser layer of that operating system.
What the week taught me
Three patterns held across every entry above and I expect them to keep holding.
Switchover is environmental, not cognitive. The room, the screen, the prompt, the icon do real work. Trying to compensate for a flat unmarked environment with attention is a strategy that works for a few hours and then fails on the day you are tired. Build the cues into the surface and you stop asking attention to do the boundary's job.
Physical and visual cues do what habit doctrine usually attributes to focus. The blue prompt, the pink prompt, the tinted Chrome icon, the named tmux session: these are not aesthetic choices. They are control surfaces. A wrong-colored prompt has stopped my hands more often than any rule I have memorized.
One structural fix beats five days of trying harder. The switch <client> function is the highest-return thing I built last quarter. It cost me one afternoon. It returns somewhere between 30 and 60 minutes per day in switching friction and probably one near-incident per quarter. None of these patterns are clever. They are just permanent.
I wrote earlier about the cost of running multiple client stacks and the calendar tax fragmented scheduling produces. The patterns above are the per-switch implementation that makes the calendar architecture viable. For the broader question of which engagement structures actually demand this kind of multi-account life, the fractional engagement structure walkthrough is the companion piece. Sprints rarely require a switchover system because they consume one client's days in blocks; operator and embedded structures are where these patterns earn their keep.
FAQ
Why not run one super-browser-profile with all client cookies and just be careful?
Because careful is not a strategy that survives a hard week. The same browser holding Client A and Client B credentials is one autofill suggestion away from logging the wrong email into the wrong dashboard. The profile boundary is cheap, isolates cookies and saved sessions, and gives you a visible cue (the tinted icon) that a super-profile cannot. The first time the boundary saves you from a five-second mistake, the cost is paid back.
I use Arc or Brave or Firefox instead of Chrome. Same patterns?
Same patterns, slightly different mechanics. Arc has Spaces, which work like profiles and are arguably better designed for this. Brave has Profiles, mostly equivalent to Chrome's. Firefox has Containers, which are tab-scoped and excellent if you want lighter isolation. The principle is the same: per-client cookies, per-client autofill, per-client visible color cue.
A client wants me in their Slack workspace all day. Doesn't that break the boundary?
It does, which is why I do not accept that engagement shape if I can avoid it. The compromise I have used is a separate Slack desktop instance per client and only the current client's instance is open during their block. Others are quit, not minimized. If the client insists on always-on Slack presence, the engagement is closer to embedded than fractional and should be priced and scheduled accordingly.
One terminal session per client feels heavy if I only have two clients. Worth it?
Yes. The moment it pays back is the first time you accidentally run a destructive command in the wrong directory. Two clients still means two distinct production environments and two distinct credential sets. The tmux session takes 30 seconds to set up and is the cheap version of an insurance policy. From two clients on, you need this.
What about the phone? My personal device gets pings from clients too.
The phone is the leakiest surface in the system because iOS does not have profile boundaries the way browsers do. My imperfect answer is per-client Slack channels muted by default with only urgent threads and direct mentions allowed through, plus a single "Client work" Focus mode that suppresses everything else during work blocks. The phone is a worse story than the laptop and the part of the system I am least proud of.
Does this scale to six clients?
Six profiles and six tmux sessions still fit on one machine. The bottleneck shifts from the environment to the morning ritual. Triaging six clients in 10 minutes is hard; triaging four is comfortable. Above four the calendar tax is the limiting factor, not the switchover patterns.
Sources and specifics
- The patterns run on macOS 14+ with Chrome, iTerm 2, tmux 3, and macOS Keychain via the
securityCLI. 1Password is an alternative, not the primary vault. - The
switch <client>shell function is under 40 lines of Bash. It opens the matching Chrome profile viaopen -na, creates or attaches a tmux session, setsPROJECTandCLIENT_ALIASenvironment variables, and prints a status banner. The pattern is the load-bearing element, not the implementation. - The morning ritual time of 10 minutes is from one operator's tracking across April 2026, three or four active accounts; not a public benchmark.
- macOS Touch ID is per-process, not per-browser-profile, so canceling cross-profile prompts is the only enforcement the operator has against the boundary failure described in the 2026-05-02 entry.