Why every AI coding CLI allows one account per machine

It is worth understanding why the constraint exists, because the reason tells you whether waiting for it to be lifted is a plan.

The design is older than the problem

Every one of these tools follows the same convention: a config directory under your home directory, holding a credential for the signed-in account. It is the pattern most command line tools use, and for most of them it is correct.

That design assumes a machine has one user, that user has one identity with the service, and the identity rarely changes. For git, for a package manager, for nearly everything that came before, that is true.

It was true for these tools too, right up until it was not.

What changed was the plans

Two things happened at once. The subscriptions became meaningfully rate limited, so having a second one stopped being redundant and started being capacity. And the tools got good enough to run unattended, so wanting several working at once became a reasonable thing to want rather than a strange one.

Now a real developer plausibly has a work plan, a personal plan and a client's plan, and a genuine reason to have all three doing something on a Tuesday afternoon. The tool still thinks they are one person with one account, because nothing about the tool changed. The usage did.

Why it is unlikely to be fixed soon

Multi account support is not one feature. It is a credential store that holds several identities, a way to say which one a given invocation uses, a way to show you which one is active so you never send a client's work through your personal plan by accident, and a support burden for every confused report that follows.

Set against that, the vendors have limited incentive. Multi account support makes it easier to spread work across several plans, and none of these companies is in a hurry to optimise that path. It is not hostility, it is just not the roadmap.

The reasonable planning assumption is that this constraint is stable.

What that leaves

If the constraint is not going away, the question becomes what to build on top of it. Anything that works has to give each session its own credential storage, without asking the tool to support something it does not support.

The workarounds people use are a second macOS user account, a container per account, or signing in and out by hand. All three work. All three cost enough that most people end up using one account and leaving the others idle, which is the outcome the constraint was never meant to cause.

The other half

Separate credentials on their own do not get you very far, because the moment two agents are running they need somewhere separate to work as well. Two agents in one folder overwrite each other regardless of which account they are signed in as.

So the real requirement is a pair: an account per session, and a working copy per session. Get one without the other and you have half a solution.

Nuvoa is those two things on macOS, in one window. Each pane holds its own sign-in that no other pane can read, and its own branch and working copy of your project. Several accounts stay signed in at once, they can all work on the same repository, and you can see all of them.

That two accounts really are separate, and that neither can reach the other's sign-in, is checked rather than asserted. The check runs on your own machine, without a network and without a model.

Join the waitlist.