A developer in the Claude community described a familiar problem last week: wanting to run two Claude Max accounts at once inside Claude Code to avoid hitting usage limits, then discovering the login is tied at the operating system level. Their fix, untested at the time of writing, was setting up two separate macOS user profiles just to keep two sessions open at once.
It's a clever workaround. It's also a clear sign the business is on the wrong plan. If a team is creating fake user profiles on a laptop just to keep two people logged into the same tool, that's not a technical problem, it's a licensing problem, and it's one a lot of Australian businesses adopting Claude Code are quietly living with.
Why this happens
Claude Max is built for a single, high-volume user, not a team sharing one login. It's the right plan for a solo developer or founder pushing a lot of work through Claude Code on their own account. It's the wrong plan the moment a second or third person needs regular access, because the product was never designed to be split between people.
When two or three people share a Max account to save money, they run into the same wall this developer did: usage caps that reset on one shared clock, session conflicts when two people try to work at once, and now, apparently, operating-system-level workarounds just to open two windows. None of this is a bug. It's what happens when a consumer plan gets stretched to cover a team use case it was never priced or built for.
What shared logins actually cost you
The workaround itself is a minor annoyance. The things it's hiding underneath are the real cost.
Shared logins mean no audit trail of who ran what, which matters the moment a client asks what touched their data
Usage caps land at the worst possible time, mid-deployment, because everyone is drawing from the same pool
Troubleshooting “why did my session just log out” burns more staff hours over a year than the price difference between plans ever would
Offboarding a shared login is messy: when someone leaves, the whole team's access has to be rotated, not just theirs
Each of these is manageable in isolation. Together, over a year, they add up to more lost time and more exposure than most business owners realise until they actually sit down and total it.
The compliance question Australian businesses can't skip
For a solo user, a shared login is just inconvenient. For a business handling client data under the Privacy Act, it's a governance gap. If a client, an auditor, or a regulator ever asks which staff member accessed a particular file or ran a particular prompt against their data, “we're not sure, it was on the shared account” is not an answer anyone wants to give. Professional services firms in Sydney and Melbourne are increasingly asking their own vendors and subcontractors how AI tools are provisioned as part of standard due diligence, and “everyone logs into the same account” doesn't hold up well in that conversation.
This isn't a Claude-specific problem. It's the same principle that applies to shared email inboxes or shared admin logins on any system that touches client work: one login per person is the baseline expectation for an Australian business, not a nice-to-have.
The straightforward fix: seat-based provisioning
Anthropic's team and enterprise plans exist precisely so nobody needs a second macOS user account to use Claude Code properly. An Australian business running Claude Code across even two or three staff should be on seat-based licensing, not a single consumer Max login split awkwardly between people.
Provision one seat per person, tied to their own identity, with its own audit trail
Set usage budgets per seat instead of one shared ceiling that anyone can exhaust
Give whoever manages the account visibility into usage across the whole team, not just their own session
What proper provisioning looks like in practice
Moving off a shared login doesn't require ripping anything up mid-project. The practical version looks like this:
Audit who is actually using Claude Code today and how often, including the people quietly sharing a password
Map that usage against Team or Enterprise seat pricing to see where the break-even point actually sits
Set a review date, typically 90 days out, to check the seat count still matches who's using it
Build offboarding into the process so a departing staff member's access is revoked in minutes, not chased up weeks later
None of this needs to happen in one afternoon. It needs to happen before the next new hire gets handed a password on a sticky note instead of their own seat.
Getting the sizing right
The part most businesses get wrong isn't the decision to move to seat-based licensing, it's guessing at how many seats they actually need. Buy too few and the team is back to sharing logins within a month. Buy too many and it's paying for seats nobody opens. Getting a specialist to size the plan against actual usage is typically a $2,000 to $5,000 exercise in Australia, and it tends to save more than that in avoided workaround hours within the first year.
If a team is trading macOS user accounts just to keep two Claude Max sessions open, that's the signal to fix the plan, not the workaround. It's the kind of quick audit Automata AI runs for Australian businesses moving from one person trialling Claude to the whole team relying on it. Book a short call to work out what proper provisioning looks like for your team.
