How to set up a second Claude app on a second
subscription
– use two accounts side by side for twice the included usage.
Tell your Claude:
thomasbachem/second-claude-app – what exactly would it change on my Mac? If I decide to go ahead, let's set it up together.
Prefer the terminal? git clone, read it, then ./install.sh and ./login.sh – fully reversible
Both accounts stay signed in, both apps run at once – the long session on one plan, interactive work on the other. When one runs dry, the other keeps going.
Its own name, Dock tile, ⌘-Tab entry, and Notification Center presence – plus a teal icon auto-derived from Claude's, and a matching live tint on its window, so you can tell them apart at a glance.
Different accounts for different budgets: billing stays cleanly split, and switching is a ⌘-Tab instead of a logout/login round-trip.
A background keeper pre-builds the updated clone when Claude updates and swaps it in the instant you quit – the same rhythm the original upgrades with.
It clones Claude.app. A keeper rebuilds the clone from scratch
on every Claude update – never patching the copy you're running:
ditto copies the installed app – or a freshly downloaded update before Claude has even installed it – into a staging dir.
New bundle id and display name in Info.plist, the claude:// scheme claim dropped. CFBundleName stays "Claude" – Electron resolves its helpers by that name.
The real main binary moves aside – a tiny compiled shim takes its place, sets CLAUDE_USER_DATA_DIR, and execvs the real one. Same PID, same bundle, so NSBundle reports the clone's id and every child process inherits the profile.
Exactly two codesign calls: nested code legally keeps its own signature, so Anthropic's frameworks and helpers stay untouched and valid. Only what the patch invalidated gets re-signed – under a persistent self-signed cert, so permission grants survive every rebuild.
codesign --verify --strict --deep plus structural checks gate the staging build – only then does it atomically replace the live clone. A failed build never bricks the working copy.
The whole thing is around 2,500 lines of shell and Swift – no binaries, no network calls, meant to be read before it's run:
second-claude-app/
├── install.sh # cert + keychain, shim, keeper, launch agents
├── login.sh # one-time: hands claude:// to the clone to sign in
├── status.sh # read-only health check of the whole chain
├── uninstall.sh # confirms first, then reverses everything
├── config.default.sh # every name and id in one place
└── src/
├── lib.sh # shared shell helpers
├── icon.swift # hue-shifts Claude's icon; badges the keeper's
├── clone/ # rederive.sh, shim.c, entitlements.plist
└── keeper/ # the Swift keeper: updates, claude:// guard, accentsSequential – one subscription's included usage at a time, with a sign-in dance at every switch. That friction is also why a personal-vs-work split never sticks.
Two copies of the same app collapse into one "Claude" – macOS tells apps apart by an internal id, and the Dock, ⌘-Tab, and notifications all follow it. Launcher and profile tricks don't change that – only an app with its own id does.
CLAUDE_CONFIG_DIR does exactly that in a terminal – and if that's your whole workflow, you don't need this. The clone is for when the second account needs the app: Cowork, connectors, its sessions, its notifications.
install.sh asks before it creates and trusts the cert – and --adhoc or SIGN_ID skips it entirely. The cert is trusted at the user level for code signing only – it can't vouch for anything it didn't sign – and lives in its own keychain, not your login one. ./uninstall.sh removes the trust entry, then deletes the keychain. It's the price of keeping the signature stable across rebuilds without an Apple Developer identity – and why this is a readable repo, not a download.
Ordinary, paid work – two subscriptions, each within its own limits (if anything, Anthropic earns twice). The only change is to a local copy of the app their servers never see. Their terms don't restrict a second subscription, and what they do restrict – sharing a login, reverse-engineering, botting the service – isn't what this does. Not legal advice, so skim them yourself.