What causes "Core is not running, restarting core instead of hot reload" in mihomo-party-org/clash-party?

Start the core first (await startCore / resolve the coreStartPromise) before calling mihomoHotReloadConfig if a hot reload is desired.

mihomo-party-org/clash-party · warning

Core is not running, restarting core instead of hot reload

Error message

Core is not running, restarting core instead of hot reload

What it means

mihomoHotReloadConfig logs this warning when the mihomo core process is not running (hasCoreProcess() returns false), so a hot reload via the /configs API is impossible. Instead of failing, it degrades gracefully by calling restartCore(), which boots a fresh core with the regenerated profile. It is a diagnostic breadcrumb, not a thrown exception.

Source

Thrown at src/main/core/mihomoApi.ts:433

      timeout: delayTestTimeout || 5000
    }
  })
}

export const mihomoUpgrade = async (): Promise<void> => {
  const instance = await getAxios()
  return await instance.post('/upgrade', undefined, { timeout: 90000 })
}

export const mihomoUpgradeUI = async (): Promise<void> => {
  const instance = await getAxios()
  return await instance.post('/upgrade/ui')
}

export const mihomoHotReloadConfig = async (): Promise<void> => {
  mihomoApiLogger.info('mihomoHotReloadConfig called')
  if (!hasCoreProcess()) {
    mihomoApiLogger.warn('Core is not running, restarting core instead of hot reload')
    await restartCore()
    return
  }
  const current = await generateProfile()
  const { diffWorkDir = false } = await getAppConfig()
  const configPath = diffWorkDir ? mihomoWorkConfigPath(current) : mihomoWorkConfigPath('work')
  mihomoApiLogger.info(`hot reload config path: ${configPath}`)
  const instance = await getAxios()
  try {
    await instance.put('/configs?force=true', { path: configPath })
  } catch (error) {
    if (hasCoreProcess()) throw error
    mihomoApiLogger.warn('Core exited before hot reload completed, restarting core', error)
    await restartCore()
    return
  }
  mihomoApiLogger.info('hot reload config completed')
  try {

View on GitHub (pinned to 911e090537)

Solutions

Start the core first (await startCore / resolve the coreStartPromise) before calling mihomoHotReloadConfig if a hot reload is desired.
Investigate why the core died before the reload — check core logs for config errors, port conflicts, or permission problems.
Accept the fallback: the warning indicates restartCore() was used, which is slower but equivalent; no action strictly required.

Example fix

// before
await mihomoHotReloadConfig()
// after
import { hasCoreProcess } from './core/process'
if (!hasCoreProcess()) {
  await startCore() // ensure core runs so hot reload path is taken
}
await mihomoHotReloadConfig()

Defensive patterns

Strategy: fallback

Validate before calling

import { hasCoreProcess } from '@/main/core/process'
if (!hasCoreProcess()) {
  await startCore() // or resolve coreStartPromise before hot reload
}

Try / catch

try {
  await mihomoHotReloadConfig()
} catch (e) {
  logger.error('hot reload failed, falling back to full restart', e)
  await restartCore()
}

Prevention

Gate config-reload calls behind a core-running check (hasCoreProcess or a coreStarted promise).
Subscribe to core process exit events to update UI state so reloads aren't fired against a dead core.
Treat this warning as informational — the restart fallback preserves correctness.

When it happens

Trigger: Calling mihomoHotReloadConfig() after the core process crashed, was manually stopped, or before the core was ever started (e.g. app startup race where config changes are applied before coreStartPromise resolves).

Common situations: Core crashed due to a bad config or port conflict and the UI triggers a config save; user toggles a setting while mihomo was stopped; a race during app init where profile edits happen before the core spawns.

Related errors

AI-assisted analysis of mihomo-party-org/clash-party@911e090537 (2026-08-30). Data as JSON: /api/errors/09af8100033e3e65. Report an issue: GitHub.