CLI: Rename process manager home from .studio/pm2 to .studio/daemon

[bcotrim]

Related issues

• Fixes STU-1390

How AI was used in this PR

Built collaboratively with Claude Code. I drove the design decisions (folder name, migration approach, what's in/out of scope) and reviewed each change. Claude handled the mechanical rename, the migration, and the tests. I ran eslint, targeted typecheck, and the tests after each step. After a first round, testing surfaced a race between an import-time mkdirSync in daemon-client.ts and the yargs migrations middleware — I diagnosed the bug, Claude fixed it.

Proposed Changes

Follow-up to the review thread on #2712 — the PROCESS_MANAGER_HOME default folder was named pm2 purely for back-compat, even though we no longer use pm2. This renames the folder and adds a migration so existing installations move cleanly.

• apps/cli/lib/paths.ts — change the default folder from ~/.studio/pm2 to ~/.studio/daemon. The env var STUDIO_PROCESS_MANAGER_HOME is unchanged (the name is already neutral).
• apps/studio/src/ipc-handlers.ts — the main process had a duplicate hardcoded PM2_HOME constant and a readPm2Logs helper. Renamed both to PROCESS_MANAGER_HOME / readProcessManagerLogs and updated the path.
• apps/cli/lib/daemon-client.ts — the module previously had a top-level fs.mkdirSync(PROCESS_MANAGER_HOME, …) side effect that ran at import time, before the yargs middleware ever called runMigrations. That caused the new folder to be created before the migration could check for it, so the rename silently skipped. Moved the mkdirSync into a lazy ensureProcessManagerHome() helper invoked from connectToDaemon().
• apps/cli/migrations/03-rename-pm-home.ts — new migration. If ~/.studio/pm2/ exists and ~/.studio/daemon/ does not, fs.renameSync the legacy folder to the new path. The rename preserves everything (including legacy pm2.log / pm2.pid artifacts from older Studio versions that actually ran pm2 — harmless to keep, and migrations shouldn't second-guess what the user had).
• apps/cli/migrations/tests/03-rename-pm-home.test.ts — 5 tests covering the no-op cases, the rename, and content preservation.

Why daemon?

It matches the file names already inside the folder (daemon.sock, daemon-events.sock, process-manager-daemon.ts). Short, concrete, and reads naturally (~/.studio/daemon/logs/…).

What's out of scope

Log rotation — the linked issue also mentions that pm2 gave us rotation for free and we should think about replacing it. That's already handled in #3132, so not bundled here.

Migration numbering note

I used 03- because #3132 already claims 02-. The two migrations are independent — order doesn't affect correctness. Whichever lands second will need a trivial rebase to register both in apps/cli/migrations/index.ts.

Testing Instructions

Build the CLI first: npm run cli:build. Then run node apps/cli/dist/cli/main.mjs site list (or any command that starts the daemon).

1. Fresh install:

• Remove ~/.studio/daemon/ and ~/.studio/pm2/ if present.
• Run the CLI.
• Verify ~/.studio/daemon/ is created with daemon.sock, daemon-events.sock, and logs/. No ~/.studio/pm2/ should appear.

2. Upgrade path (existing pm2 folder):

• Populate ~/.studio/pm2/ with a few dummy files (e.g. logs/site-test-out.log, pm-connection.lock, and even a pm2.log to confirm it comes along).
• Remove ~/.studio/daemon/ if present.
• Run the CLI.
• Verify ~/.studio/pm2/ is gone and ~/.studio/daemon/ has all the preserved files.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors? (Existing unrelated errors in apps/ui and apps/cli/logger.ts persist from trunk — not introduced here.)

[wpmobilebot]

📊 Performance Test Results

Comparing 917b494 vs trunk

app-size

Metric	trunk	917b494	Diff	Change
App Size (Mac)	1439.39 MB	1439.36 MB	0.03 MB	⚪ 0.0%

site-editor

Metric	trunk	917b494	Diff	Change
load	1607 ms	1872 ms	+265 ms	🔴 16.5%

site-startup

Metric	trunk	917b494	Diff	Change
siteCreation	8103 ms	8177 ms	+74 ms	🔴 0.9%
siteStartup	4946 ms	4944 ms	2 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[epeicher]

Thanks for removing leftovers about pm2 and adding the migration 👌. I have tested it, and I can confirm that the three scenarios work as expected. The end result is always the pm2 removed and the demon folder added successfully. LGTM!

Fresh install	Upgrade path	Both folders exist

I have observed that the migration includes existing files like pm2.log or pm2.pid, should we include them too?

[bcotrim]

@epeicher thanks for the review!
Good catch on the pm2 files. I thought about this and I think we should leave them in:

• Those files are harmless leftovers from older Studio versions that actually ran pm2. Moving them along with everything else keeps the migration as a plain "rename the folder" operation, which is the simplest and safest thing it can be.
• Filtering them out would mean the migration takes a stance on what's legacy junk vs. what's worth keeping. For users on older Studio versions, there might be other files we miss, better to preserve everything than risk dropping something useful.

What do you think?

FYI: I also dropped the merge scenario, I don't think there's a real use case where the user would have both folders.

[epeicher]

Those files are harmless leftovers from older Studio versions that actually ran pm2. Moving them along with everything else keeps the migration as a plain "rename the folder" operation, which is the simplest and safest thing it can be.
Filtering them out would mean the migration takes a stance on what's legacy junk vs. what's worth keeping. For users on older Studio versions, there might be other files we miss, better to preserve everything than risk dropping something useful.

Thanks for the explanation, I agree on both of these points!