feat(storage): let the user choose where projects are stored

[Lenouw]

Why

Projects, version history and media live in a hidden application data directory. Uninstalling or reinstalling the app sits on top of the user's work, and a user who wants that work on an external drive or a synced folder has no way to say so. This adds a project storage folder setting, next to the media directory one that already exists.

I hit this while using OpenChatCut for real editing work: I wanted the saved projects in my own backed-up folder, not under ~/.openchatcut.

How it resolves

Source	Behaviour
OPENCHATCUT_DATA_DIR	pins the root from a launch script, and the settings panel refuses to change it
~/.openchatcut/data-dir.json	pointer file written by the settings panel
neither	today's behaviour, unchanged

The chosen path cannot be stored in the settings keystore: an isolated dev profile keeps its keystore inside the storage root, so reading it would mean already knowing the root. Hence the small pointer file at a fixed location that never moves. A damaged pointer degrades to the default rather than blocking startup, because the profile resolves synchronously at module load and has nowhere to report an error.

Relocation safety

Saving copies the known store entries (project-store-v1, media, tombstones, generation operations) into the new root and never deletes the source: relocating must not be the step that loses someone's projects. An entry that already exists in a non-empty destination is skipped and logged, never overwritten. Regenerated files (logs, caches) stay behind.

The active profile is resolved at startup, so the move only applies on the next launch. The save response reports that with restartRequired, and the panel says so instead of the generic "saved" message.

Test suite hardening included

server/key-probes.verify.ts was not hermetic. Its local-directory assertions read the runtime profile, which resolves once at module load out of HOME and the profile environment, so a developer's own storage root, or an exported OPENCHATCUT_DEV_PROFILE_ID, could decide their outcome. Assertion 8 failed for me on a path outside the checkout. The suite now pins HOME and the profile environment to a throwaway directory before importing the module under test, so the existing assertions keep their meaning on any machine.

Verification

• server/data-dir.verify.ts (new): path expansion, pointer round trip and its degradation, writability probe, relocation safety, idempotent root creation. Registered in verify:runtime-profile.
• server/runtime-profile.verify.ts: environment variable wins over the pointer, ~/ expansion, relative path throws, damaged pointer degrades, isolated dev profile follows the chosen root, defaultRootDir() still answers "where does clearing the field lead?".
• server/key-probes.verify.ts: new storage/projects probe block (unset, relative, writable, recorded pointer, pinned by environment). Local disk only, no network request.
• tsc -b, oxlint, verify:i18n, verify:runtime-profile, verify:affected: all pass. The three suites above also pass with a hostile environment exported (OPENCHATCUT_DEV_PROFILE_ID + OPENCHATCUT_DATA_DIR set to unrelated values).

Happy to split the key-probes.verify.ts isolation into its own PR if you would rather review it separately.

[0xsline]

Reviewed the full diff against main (9f88aae). Holding merge for two P0 data-safety issues:

P0-1 Relocation skips the SQLite authority store

server/data-dir.ts:75-82 RELOCATED_ENTRIES only covers legacy JSON entries, but the authoritative store is project-store-v1.sqlite3 (server/storage/sqlite-store.ts:60-64, enabled by sqliteStoreEnabled()), which also carries FTS and semantic vectors, plus its receipt (sqlite-migration.ts:40,155-156). After relocation a SQLite-migrated user gets an empty store at the new root (projects/chat/versions/agent runs all appear gone). A plain cp of a live WAL-mode DB is also unsafe — this needs a store-locked, quiesced snapshot (VACUUM INTO / backup API), or an explicit refusal when SQLite is enabled.

P0-2 Media is copied from the wrong source in default mode

server/plugins/settings.ts:112-113 calls relocateDataDir(profile.rootDir, ...), but in default mode uploads live at cwd/public/media/uploads (web) or userData/public/media/uploads (packaged) — see server/media-dir.ts:18, desktop/chdir-first.ts:8-12. The media folder under ~/.openchatcut is empty, so after restart runtime-profile.ts:138 points mediaDir at an empty new-root directory and every existing /media/uploads/... reference goes offline. Copy from the actual uploadDir(profile) (reuse syncUploadDirectories), or gate the feature against MEDIA_DIR semantics.

P1

• runtime-profile.ts:101-103,117-122 + settings.ts:26-37: the global data-dir.json pointer is honored inside isolated dev profiles, bypassing the profile-isolation hard rule — isolated runs would write into (and be redirected by) the user's real storage root.
• data-dir.ts:86-107: relocation runs outside the store lock, non-atomically, with skip-if-nonempty — autosave/agent runs keep writing the old root during the copy, and an interrupted copy can never be completed afterwards.

Details and the remaining P2s (isolated keystore not relocated, non-atomic pointer write, no data-merge on clearing, models field carrying a path, missing SQLite/isolated-pointer/media test coverage): see the full review. The zero-regression default path and the pointer/no-keystore cycle-break design are sound — the mechanics of the copy are what need rework.

[Lenouw]

Thanks for the review, it was precise and both P0s were real. Rebased on d16bc20 and reworked.

P0-1 · SQLite · relocation now refuses while sqliteStoreEnabled(), with an explicit message rather than a silent empty root. I took the refusal you offered rather than attempting a snapshot: doing it properly needs a quiesced backup under the store lock, and that deserves its own change instead of sitting behind a settings field that looks harmless. A test asserts the refusal copies nothing at all.

P0-2 · media · media is out of the root-entry list entirely, since in the default profile uploads never live under the root. The caller now copies through the existing syncUploadDirectories() from the resolved uploadDir(profile) into relocatedUploadDir(target), so the copy lands where the relocated profile will actually resolve its writable upload dir.

P1 · isolated profiles · you were right that this broke the isolation rule. The pointer file is now honored for the ordinary profile only; isolated profiles accept OPENCHATCUT_DATA_DIR explicitly and nothing else, and the settings endpoint refuses to change the storage directory while one is active. Covered by a test that sets a pointer and asserts the isolated root is unchanged.

Still open, and I would rather say so than paper over it: the copy still runs outside the store lock, so a write landing during the copy stays in the old root. With SQLite refused and the JSON store writing per-file atomically the blast radius is "the last few seconds of autosave", not corruption, but it is not zero. The clean fix is to relocate at startup before anything opens the store, so there are no concurrent writers by construction. Happy to do that here if you prefer it in one go, or as a follow-up.

Verification: runtime-profile, data-dir, key-probes verifies, tsc -b, oxlint, all re-run with a hostile HOME + OPENCHATCUT_DATA_DIR + OPENCHATCUT_DEV_PROFILE_ID exported to prove the suites stay hermetic.

The P2s you listed (isolated keystore, atomic pointer write, merge-on-clear, models carrying a path) are noted and not addressed here, to keep this diff reviewable. Tell me which you want folded in.

[Lenouw]

Follow-up: I put the reworked diff through an adversarial pass before asking you to look again, and it found a hole I had left open. Pushed as 7573bfc.

Clearing the field bypassed the SQLite refusal. expandDataDir('') returns null, so the whole relocation block was skipped: no refusal, no copy, pointer just cleared. A migrated user who moved their storage and then cleared the field to go back to default restarted on an empty or stale root, with projects, chat and versions apparently gone. Same failure you blocked on P0-1, reached through the other door. Clearing is now treated as what it is, a relocation to defaultRootDir(profile), with the same refusal and the same copy.

Entry copies were not atomic. cp() wrote straight into the destination, so an interrupted relocation left a half-copied store that the non-empty guard then treated as complete forever, and every retry skipped it. Each entry is now copied to a staging sibling and renamed into place: it exists whole or not at all, and a leftover staging directory from a crashed attempt is discarded on the retry. That also removes the "skip-if-nonempty defeats incremental repair" edge you flagged in P1.

Both are covered by tests: clearing while relocated, and a retry after a simulated crash that must adopt the real store and leave nothing of the partial one behind.

Verification unchanged in method: runtime-profile, data-dir, key-probes, tsc -b, oxlint, all also re-run with a hostile HOME + OPENCHATCUT_DATA_DIR + OPENCHATCUT_DEV_PROFILE_ID exported.

The store-lock point from my previous comment still stands as the remaining known gap, and I still think relocating at startup before anything opens the store is the honest fix for it. Say the word and I will do it here rather than as a follow-up.

[0xsline]

Merged into main (1186471 + rework commits + one follow-up fix d4052ab).

The remaining clear-direction media target issue from the re-review is fixed: clearing the field now copies media back to the checkout-relative DEFAULT_UPLOAD_DIR (matching the no-dataDir branch of resolveRuntimeProfile) instead of ~/.openchatcut/media/uploads, extracted as relocatedMediaDestination with verify coverage for both directions. tsc/lint and data-dir/runtime-profile/key-probes verifiers pass.

Store-lock-atomicity stays deferred as the agreed P2 (legacy-JSON only, SQLite relocation refuses outright).