macos-dual-instancelisted

# Run two instances of a macOS app Duplicate and re-sign a macOS app bundle so it runs as a second, independent process the OS treats as a different app: its own sandbox container, its own login session, running alongside the original. Verified on WeChat.app (Tencent, sandboxed, container under `~/Library/Containers/`) 2026-09-19. ## Facts every step rests on - **`open -n -a` is not the fix.** It forces a new *launch request*, but an app with its own single-instance IPC check (most chat/IM apps) just detects the sibling and refocuses it — no new process shows up in `pgrep`. `LSMultipleInstancesProhibited` in Info.plist is a separate, OS-level flag; its absence doesn't mean the app allows a second copy of itself. - **The container follows the bundle ID, not the code signature.** A sandboxed app's data lives at `~/Library/Containers/<CFBundleIdentifier>/`. Change the identifier in a copy of the bundle and macOS hands the copy a fresh, empty container at launch — an independent login session with no shared state. - **Ad-hoc signing is enough to launch, not enough to trust.** `codesign --force --deep --sign -` replaces the vendor's signature so the copy can execute, but it strips notarization: a Finder double-click gets Gatekeeper-blocked (launch with `open` from Terminal, or right-click → Open once, instead). Some apps also run their own anti-tamper checks independent of the OS signature and refuse to start, or crash, after re-signing — a per-app roll of the dice, not guarant