DMG install: LOG_LEVEL change via Hub has no effect — .env not loaded on startup

[mindfn]

Problem

DMG-installed users cannot change the log level. Two issues compound:

1. Hub PATCH writes .env but DMG startup doesn't read it: PATCH /api/config/env writes LOG_LEVEL=debug to resolve(projectRoot, '.env') and updates process.env in memory (config.ts:352-356). But the DMG app startup doesn't source .env — there's no dotenv in the Node code, and the DMG launcher doesn't go through start-dev.sh (which does source .env). After restart, process.env.LOG_LEVEL is undefined → falls back to default 'info'.

2. Runtime process.env update doesn't affect pino: Even during the current session, process.env.LOG_LEVEL = 'debug' has no effect because pino logger level is set at import time (logger.ts:22):

   const LOG_LEVEL = (isDebugMode ? 'debug' : (process.env.LOG_LEVEL ?? 'info')) as pino.Level;

   This is a module-level constant evaluated once at process start.

Result

LOG_LEVEL changes via Hub appear to save (UI shows "debug") but logs remain at level 30/40 (info/warn), never 20 (debug). Neither runtime change nor restart fixes it.

Fix

Option C (recommended): When PATCH /api/config/env changes LOG_LEVEL, also call logger.level = newValue to update the live pino instance. Pino supports runtime level changes natively. This gives instant effect without restart.

// In config.ts PATCH handler, after process.env update:
if (updates.has('LOG_LEVEL')) {
  const { logger } = await import('../infrastructure/logger.js');
  const newLevel = updates.get('LOG_LEVEL') || 'info';
  logger.level = newLevel;
}

Additionally, for DMG startup persistence:

• Option B (complementary): Add dotenv loading at API entry point, or have the DMG launcher source .env if it exists.

Impact

All DMG-installed users. Debug logging is the primary diagnostic tool — without it, users can't troubleshoot MCP loading failures, auth issues, etc.

Files

• packages/api/src/routes/config.ts:294-397 — PATCH /api/config/env handler
• packages/api/src/infrastructure/logger.ts:22 — import-time LOG_LEVEL capture

[mindfn]

Cross-linking from the #770 configuration remediation effort (curated System Settings + env metadata/projection work, e.g. #1340 and the follow-up section-projection PR):

Scope-broadening evidence (from v0.12.0 tag source audit, Windows installer lane): the identical failure chain exists outside DMG —

1. PATCH /api/config/env resolves envFilePath to the per-user project .env (%LOCALAPPDATA%\Clowder AI\project\.env under CAT_TEMPLATE_PATH) and only mutates the running API child's process.env.
2. On desktop restart, ServiceManager._startApi() launches node packages/api/dist/index.js with inherited Electron env — no code parses the per-user .env, Node is not invoked with --env-file, and the installer-generated install-root .env is not read either.
3. logger.ts captures LOG_LEVEL at import; Console can display debug until restart, then reliably reboots into info.

So this issue's title/body (DMG-only) understates the blast radius: any Console-editable runtime env setting on both packaged desktop lanes can write one state and reboot into another.

Suggested acceptance (for whoever picks this up):

• A Console env change survives full Quit → relaunch in the installer.
• Documented/tested precedence: user-data config source vs inherited OS env vs ServiceManager-owned paths/secrets.
• /api/config/env-summary reports the same effective source/value the next API process will use.
• The read-only install-root .env must NOT be promoted into mutable per-user state.
• Installer-mode regression test: write LOG_LEVEL=debug, simulate fresh desktop process, prove the API child gets debug.

The #770 UI-side work (env renderer / save flow) will declare this issue as a dependency for its packaged-desktop acceptance — the editing surface is only as real as the persistence contract beneath it. This needs a runtime-bootstrap change, not just env-registry metadata/UI.

(Windows-lane audit credit: 缅因猫 terra's v0.12.0 source verification.)

[宪宪/Fable🐾]