Preserve manual-only sync configs when defaulting intervalMinutes

Setting intervalMinutes to 15 here changes existing configs that already turned off the other automatic sync triggers (onSessionStart, onSearch, and watch) into background reindexing configs. MemoryManagerSyncOps.ensureIntervalSync() still schedules sync({ reason: "interval" }) regardless of those flags, so deployments that disabled auto-sync to avoid periodic CPU/embedding traffic will now start scanning every 15 minutes unless they discover and add a new intervalMinutes: 0 override.

Useful? React with 👍 / 👎.

Thanks for flagging. This is intentional --- the whole point of this PR is to provide a safety net when the chokidar watcher silently dies.

A few notes:

• The scenario (all three sync triggers disabled + no explicit intervalMinutes) is an extreme edge case. Users who go that far in disabling sync are almost certainly also setting intervalMinutes: 0 explicitly.
• Even when the interval fires, syncMemoryFiles compares file hashes and skips unchanged files (line 740), so there is no re-embedding cost --- just a lightweight file listing + hash check.
• Users who truly want zero background sync can still set intervalMinutes: 0 to opt out.

Adding conditional logic (e.g. only default to 15 when watch: true) would undermine the safety net --- if watch is disabled precisely because chokidar is broken, those users lose the fallback too.

Avoid default interval rescans for multimodal memory files

When intervalMinutes is omitted, this now enables a 15-minute background sync for every memory index. In that sync path, ensureIntervalSync() marks the manager dirty and syncMemoryFiles() rebuilds buildFileEntry() for every memory asset before it can decide the hash is unchanged (src/memory/manager-sync-ops.ts:715-749). For multimodal memory, buildFileEntry() rereads the entire file to compute dataHash (src/memory/internal.ts:205-243), so a workspace with several 5-10 MB images/audio notes will now incur recurring full-blob IO and RSS spikes every 15 minutes even when nothing changed. That is a meaningful performance regression for users who only took the default.

Useful? React with 👍 / 👎.

Thanks for flagging. The IO pattern you describe is accurate, but it is pre-existing behavior --- every sync trigger (watch, onSessionStart, onSearch) goes through the same syncMemoryFiles → buildFileEntry → readFile path. This PR does not change how sync works; it only adds an interval trigger as a fallback for when the watcher silently dies.

A stat-based fast path in buildFileEntry (skip readFile when mtime+size are unchanged) would be a worthwhile optimization, but that applies to all sync triggers equally and is out of scope for this fix.

Also worth noting: multimodal memory is opt-in and off by default, so the default-config user this comment is concerned about would not have large binary files in their memory directory in the first place.

Avoid enabling 15-minute rescans on permanently cached managers

This default is broader than a one-shot safety net because builtin managers are cached globally in src/memory/manager.ts:164-198 and most long-lived callsites never close them (for example src/agents/tools/memory-tool.ts:96-127 and src/agents/pi-embedded-runner/compact.ts:323-334). In a multi-agent gateway—or after any config change that produces a new cache key—each touched manager will now keep its own 15-minute interval sync loop forever, so background workspace scans accumulate across dormant managers instead of only the active one.

Useful? React with 👍 / 👎.

Thanks for the detailed analysis. The manager cache accumulation you describe is technically accurate — cached managers aren't evicted and each keeps its own interval timer.

However, this is a pre-existing property of the manager cache, not something introduced by this PR. Any intervalMinutes > 0 value (whether user-configured or defaulted) behaves identically. The fix here is adding a cache eviction / idle-cleanup policy to the manager cache itself, which is an independent concern and shouldn't block a safety-net default for silent watcher death.

In practice: default users have 1 manager (single agent, single workspace, same settings = same cache key). Even in multi-agent gateways, the number of distinct cache keys is small, and the interval sync is lightweight (stat + hash compare, unchanged files skipped).

Keep sync resolver default aligned with interval fallback

Changing mergeConfig() to default intervalMinutes to 15 here, while resolveSyncConfig() (used by resolveMemorySearchSyncConfig) still defaults to 0, introduces two conflicting defaults for the same setting. That divergence means callers using the sync-only resolver can still behave as if interval fallback is disabled even when the main memory config resolver enables it, which undermines the safety-net behavior this commit is introducing. Please centralize or mirror the default so both resolvers produce the same value when intervalMinutes is omitted.

Useful? React with 👍 / 👎.

Fixed in 29a4a1ab — resolveSyncConfig now defaults intervalMinutes to 15, matching mergeConfig. Good catch.

Keep sync defaults consistent across memory config resolvers

This change updates mergeConfig() to default sync.intervalMinutes to 15, but resolveSyncConfig() (used by resolveMemorySearchSyncConfig) still defaults it to 0, so two public resolvers now disagree for the same omitted config. Callers that depend on the sync-only resolver (for example extensions/memory-core/src/memory/qmd-manager.ts) will continue behaving as if interval fallback is disabled, which creates inconsistent runtime behavior and makes the new default safety net apply only on one code path.

Useful? React with 👍 / 👎.

Same fix as above — aligned in 29a4a1ab.

Skip interval fallback when memory source is disabled

Changing the omitted sync.intervalMinutes default to 15 enables periodic sync for configurations that only index sessions (sources: ["sessions"]) even though there is no file watcher to recover. ensureIntervalSync() still schedules sync({ reason: "interval" }) regardless of sources, so these setups now run background sync cycles (provider/vector preflight + metadata checks) every 15 minutes when they previously stayed idle unless session triggers fired. This is an unintended workload increase for session-only deployments and can produce periodic noise despite no memory-file source being enabled.

Useful? React with 👍 / 👎.

Fixed in 0032db90ab - added check to skip interval timer setup when memory files are not in configured sources. Session-only deployments now avoid the unnecessary background sync cycles.