ATBClone: a macOS app cloning engine for isolated second instances

What ATBClone is for, and who actually needs it

macOS gives you one copy of an application bundle and one set of preferences, caches and login state per user account. If you want a second signed-in session of the same app, the usual options are a second macOS user, a virtual machine, or hand-editing the bundle yourself. ATBClone takes the third route and automates it. It was built for people who need two instances of the same app side by side: a work and a personal WeChat, two Chrome profiles with separate proxy routes, or several AI desktop clients logged into different accounts. The README calls out WeChat, QQ, Telegram, Chrome, Edge, Arc, Cursor, VS Code, Firefox, Brave, Tor and Zed among the supported targets, plus 34 built-in recipes for popular apps and AI agent tools. It is a macOS-only tool. Nothing in the repository suggests a Linux or Windows path, and the GUI is built with Toga under Briefcase for a macOS bundle.

Hard clone versus soft clone: two mechanisms, one command

The engine has two distinct strategies and picks between them per app. A hard clone duplicates the entire App Bundle, rewrites Info.plist and the Bundle Identifier, and then injects isolated HOME and TMPDIR directories into the running process. The README describes two injection routes for that: an in-process dynamic library called libatbclone_env.dylib, or a Mach-O binary launcher hijack. The same path can strip App Sandbox restrictions and then re-sign the bundle ad-hoc. That is the part with real consequences, and it is why the tool is not a simple copy script. A soft clone avoids all of that. It generates a lightweight wrapper bundle that passes isolated --user-data-dir or --profile launch arguments, plus proxy environment variables, to apps that already support them. Editors and browsers fall in this group. The split matters because the soft path does not touch code signing at all, while the hard path does. If you are deciding whether to trust the tool with a given app, the first question is which strategy it chose, and the App Prober exists to answer that: it inspects Mach-O architectures, frameworks and sandbox entitlements for an app with no pre-configured recipe and proposes a strategy.

Installing ATBClone and cloning your first app

There are two distribution packages with, per the README, identical core functionality. The GUI is a macOS .dmg installer named like ATBClone-arm-x.x.x.dmg, downloaded from the GitHub Releases page; the README tells beginners to drag ATBClone.app into Applications and launch it. The CLI is a standalone binary archive, ATBCloneCli.tar.gz, described as requiring zero Python dependencies. If you would rather run from source, pyproject.toml requires Python 3.12 or newer and pulls in click, pydantic, rich and pyyaml, with a gui extra adding toga and requests. The console entry point is atbclone.

pip install -e .
atbclone wizard

The wizard is the intended first run. The README lays out its workflow: drag and drop a .app path into the terminal, let it auto-match a recipe, set the clone name, set the display name and icon, choose a destination directory, optionally set a custom data directory, optionally configure a proxy, then confirm. If you prefer flags over prompts, the GUI can also be started from source:

bash scripts/run_gui.sh

After creation, the clone appears in the dashboard as a card showing its strategy, proxy status and creation time. The README notes that writing to ~/ATBClone/Apps needs no admin rights, while writing into /Applications triggers a single macOS osascript authorization prompt. Start with the home-directory destination for your first clone so you can delete it without an admin prompt.

Recipes, proxies and where the isolation stops

Recipes are YAML descriptions of how a given app should be cloned. ATBClone ships 34 or more of them and lets you override or add your own under ~/ATBClone/recipes/. The App Prober can generate a recipe for an unlisted app, which is the honest answer to the question of what happens when your app is not in the list. Per-clone proxies are HTTP or SOCKS5 with authentication support, and the README is explicit that they do not interfere with host system or primary application traffic. That is a genuinely useful property if you run one clone through a corporate proxy and keep the main app direct. The isolation is not a container, though. It is a cloned bundle with a redirected HOME and TMPDIR. Anything the app stores outside those variables, or anything it looks up through the system keychain, shared containers or a launch agent, is not covered by the mechanism as described. The README does not claim otherwise, and it does not document rollback for a clone that misbehaves. The removal command is the escape hatch: remove with --with-data or --keep-data decides whether the isolated data directory goes with it.

The sandbox and code-signing trade-off

Stripping App Sandbox entitlements and re-signing a bundle ad-hoc is the mechanism that makes hard cloning work for sandboxed apps, and it is also the reason to be careful. An ad-hoc signature is not a Developer ID signature. Any app that validates its own signature, checks for a receipt, or relies on entitlements that only a real signing identity can grant may refuse to run or lose functionality after cloning. The README presents sandbox removal as an optional step in the hard clone path, which is the right framing: it is a switch, not a default you should ignore. The same applies to the dynamic library injection. Loading libatbclone_env.dylib into a process is how HOME and TMPDIR get redirected, and it is also the kind of change that hardened runtime and library validation are designed to block. The repository does not document a compatibility matrix for which apps survive this, so the practical test is to clone and launch. If the app crashes on start or silently loses account state, the hard path is the wrong tool for it, and the soft path may not be available either if the app does not accept a user-data-dir argument.

How ATBClone compares to running a second macOS user

The realistic alternative is a second macOS user account, which gives each app a genuinely separate HOME, keychain and container set with no bundle modification and no re-signing. The difference in approach is total. A second user account isolates at the OS level and costs you a login switch plus duplicated disk usage for every app you install there. ATBClone isolates inside one user session, keeps both instances launchable from the same desktop, and lets you point the data directory at an external SSD, which the README lists as a supported option in the GUI. What you give up is the OS guarantee: a second user account cannot break an app's signature checks, and a cloned bundle can. For a browser profile where the soft path applies, that gap is small. For a sandboxed chat app on the hard path, it is the whole question. A virtual machine is the third option and the most expensive; it is the one to reach for when the app must not see your real HOME at all.

Maintenance, updates and the GPL-3.0 licence

The project is not archived, and the last push to main was on 2026-09-16, one day before this writing, with v1.8.0 released on 2026-09-13 after v1.7.0 and v1.6.0 the same day. pyproject.toml pins the package version at 1.8.0 and requires Python 3.12 or newer, so a source install tracks a fairly recent interpreter. The upgrade cost that matters is not the tool's own version, it is the cloned apps. The README documents an update command that re-clones after the primary app is upgraded while preserving user and chat data. That is the operation to test before you depend on it, because it re-runs the clone pipeline over a bundle that has changed underneath it, and the README does not spell out what happens when the new version changes its sandbox entitlements or its bundle layout. The licence is GPL-3.0-or-later, declared in both pyproject.toml and the LICENSE file. If you redistribute ATBClone or a modified version, the copyleft terms apply to that distribution. Whether your own internal use of the CLI triggers anything is a question for your legal team, not for this article.

Editorial conclusion

Adopt ATBClone if you need several isolated instances of a macOS app and you are willing to accept ad-hoc re-signing and sandbox removal in exchange. Do not adopt it for apps that depend on iCloud keychain sharing, push notifications or App Store receipt validation, because the clone is a modified bundle and those checks can fail. Before you commit, run the wizard on one app you can afford to lose, confirm the clone launches and holds its own data directory, and check what the update command does to that data when the primary app is upgraded.

Frequently asked questions

Official sources

1. aitobox/ATBClone on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases