fix(electron): skip single-instance lock in dev to prevent dev server…

[dataCenter430]

Closes: #1260

Related Issue

1. Top-level
   as soon as the main process runs, it calls requestSingleInstanceLock(). If it returns false, the process calls app.quit() and process.exit(0).
2. In dev
   when run the app via the dev server(npm run dev), Vite starts the dev server and then starts the Electron main process(often as a child). If you start a second instance ( npm run dev again, or launch the app again), that second main process fails to get the lock and exits immediately. The dev tooling (e.g. vite-plugin-electron) sees that child process exit and can treat it as "Electron exited," so the second dev server can shut down or behave oddly.
   So the report that "the dev server can exit when a second instance starts" is correct.

Description

Single-instance is now enforced only when not running under the Vite dev server:

1. Top-level check
   The process only quits when it doesn't get the lock and it's not in dev:

• Use VITE_DEV_SERVER_URL (already set by the Vite dev server) to detect dev.
• If VITE_DEV_SERVER_URL is set, the early app.quit() / process.exit(0) is skipped, so the second instance in dev does not exit and its dev server stays up.

2. setupSingleInstanceLock()
   In dev we skip single-instance setup entirely:

• If VITE_DEV_SERVER_URL is set, setupSingleInstanceLock() returns without calling requestSingleInstanceLock() or app.quit(), so no second-instance handling and no quit in dev.

Result

• production/packaged app: Unchanged: only one instance; second instance quits and the first gets second-instance.
• development: multiple instances are allowed, so the dev server no longer exits just because a second instance was started.

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Contribution Guidelines Acknowledgement

• I have read and agree to the Eigent Contribution Guideline

[Wendong-Fan]

Thanks @dataCenter430 for the PR. I'm curious what specific use case requires running multiple instances instead of a single instance in dev?

Enabling multi-instance by default can introduce risks, if there's indeed have some usecase for this, would it be better to keep single-instance as the default, and only allow multi-instance when explicitly enabled via an environment variable, e.g. EIGENT_DEV_MULTI_INSTANCE=1?

[dataCenter430]

Hi, @Wendong-Fan thanks for your review.
I'm so happy to contribute here as a big fan of Eigent.
I addressed your review by keeping single-instance as the default in dev and making multi-instance opt-in via an environment variable.

Changes:

1. New env var: EIGENT_DEV_MULTI_INSTANCE=1
   When set (and only when running under the Vite dev server), the app skips the single-instance lock so multiple dev instances can run (e.g. multiple npm run dev).
2. Default behavior:
   Production / packaged: unchanged — single-instance only; second instance quits.
   Dev (default): single-instance — second instance quits even in dev, so no behavioral change unless you opt in.
   Dev with opt-in: run with EIGENT_DEV_MULTI_INSTANCE=1 (e.g. EIGENT_DEV_MULTI_INSTANCE=1 npm run dev or in .env.development) to allow multiple instances and avoid the dev server shutting down when a second instance starts.
3. Code:
   Introduced EIGENT_DEV_MULTI_INSTANCE and skipSingleInstanceInDev (true only when VITE_DEV_SERVER_URL is set and EIGENT_DEV_MULTI_INSTANCE=1).
   The top-level single-instance check and setupSingleInstanceLock() now use skipSingleInstanceInDev instead of “any dev,” so we only skip the lock when the env var is set.

I really appreciate your review with this and hope this will be merged in codebase.
Thanks again. 🙏

[dataCenter430]

Hi, @fengju0213
Could you please review the PR when you have a chance, since there is no review yet?
Thank you