Two Seals in One City: Two Imperial Seals on a Single Desk, the Deep-Link Misdelivery Affair, and the Only Narrow Gate to the Word Simultaneous

One city to host two living Buddhas — one PC to run two ZCode instances, each with its own account, each with its own quota. The feasibility review of this modest wish walked the full road this day, from source forensics to a real-world stumble.

I. Forensics of the Mechanism: Credentials Follow the Filing Cabinet

The evidence chain dug out of the local Electron asar is complete and dignified: login credentials live in v2\credentials.json inside the data directory, and one file records only the currently active account; the data root is decided by the environment variable ZCODE_DATA_BASE_DIR. Point a second instance at a different directory and it is blank paper, ready for another account. The single-instance lock binds to the Electron userData directory; change ZCODE_DESKTOP_USER_DATA_DIR and each lock guards its own gate. A search of the whole program finds not one hardcoded listening port — the two instances have no port to fight over. The main process even computes the data directory and actively passes it to the worker subprocess: this road is the official thoroughfare, not a smuggler trail.

II. The Misdelivery Affair: A Receipt to the Wrong Door

The only trap hides at the last step of login. The OAuth flow borrows the system browser: after authorization, the browser is kicked to zcode://oauth/callback, and the registry reads ZCode.exe -- "%1" — without any environment variables. The receipt thus raises a fresh process belonging to the default data directory, namely house A. The field test confirmed it: at 14:08 instance B wrote its own credentials, and at 14:10 the receipt knocked the current-login of A over to B — A’s interface declared the plan credential lost. Yet the credential body had lost not one entry (both coding-plan records and the token intact); only the switch reading which card is current had flipped. Switch back in settings or log in again, and all returns. Changing browsers is useless — couriers may change, but the delivery address is written in the property registry. Two fallbacks stand ready: paste an API key directly into B (never touching the browser), or the file-moving method that carries the login state over. The house rule stands written: A may log in freely; B must never log in rashly.

III. The Census: Of Three Roads Only One Leads to Simultaneous

The official documents and community tools were searched: native multi-account support can only switch — one account works at a time; the community account switcher likewise closes the app, swaps files and restarts — rotation in essence. For the word simultaneous, neither official nor community offers a ready road — dual instances are the only narrow gate, and its hardest step, the first browser login of B, has already been crossed. Data isolation is total: two directories, two workspaces, two task stores, each ignorant of the other; the single commandment is never to let two instances edit the same project folder at once.

IV. The Economics of the Narrow Gate

The true worth of this engineering is not the saved computer but the confirmed form of governance: isolation by directory, not by protocol; independence by environment variable, not by restart. Any system whose credentials live in files and whose identity lives in directories can reproduce this one-city-two-Buddhas pattern by the same strategy — and upgrades will hardly break it, for the mechanism is the official road itself.