What causes "${i18next.t('mihomo.error.profileCheckFailed')}: ${error}" in mihomo-party-org/clash-party?

Verify the mihomo core binary exists at the configured core path and is executable (chmod +x on Unix).

${i18next.t('mihomo.error.profileCheckFailed')}: ${error}

Error message

${i18next.t('mihomo.error.profileCheckFailed')}: ${error}

What it means

Thrown when the profile-check process failed before producing stdout to classify — i.e. the child process itself errored (spawn failure, non-zero error object, permission problem) rather than the core reporting a config problem. The caught `error` value is stringified after the localized 'profileCheckFailed' prefix.

Source

Thrown at src/main/core/manager.ts:1003

        .filter((line) => line.includes('level=error') || line.includes('error'))
        .map((line) => {
          if (line.includes('level=error')) {
            return line.split('level=error')[1]?.trim() || line
          }
          return line.trim()
        })
        .filter((line) => line.length > 0)

      if (errorLines.length === 0) {
        const allLines = stdout.split('\n').filter((line) => line.trim().length > 0)
        throw new Error(`${i18next.t('mihomo.error.profileCheckFailed')}:\n${allLines.join('\n')}`)
      } else {
        throw new Error(
          `${i18next.t('mihomo.error.profileCheckFailed')}:\n${errorLines.join('\n')}`
        )
      }
    } else {
      throw new Error(`${i18next.t('mihomo.error.profileCheckFailed')}: ${error}`)
    }
  }
}

// 权限检查入口（从 permissions.ts 调用）
export async function checkAdminRestartForTun(): Promise<void> {
  await checkAdminRestartForTunWithRestart(restartCore)
}

View on GitHub (pinned to 911e090537)

Solutions

Verify the mihomo core binary exists at the configured core path and is executable (chmod +x on Unix).
Reinstall/re-download the core — a truncated or quarantined binary is the usual culprit.
Check the stringified error suffix in the message (e.g. ENOENT, EACCES) and address that OS-level cause.
Re-check the core path setting; reset it to the app-bundled core if it was customized.

Example fix

// before: binary not executable
$ ls -l mihomo
-rw-r--r-- mihomo

// after
$ chmod +x mihomo

Defensive patterns

Strategy: validation

Validate before calling

// verify the core binary is runnable before invoking a check
import { accessSync, constants } from 'fs'
accessSync(corePath, constants.F_OK | constants.X_OK) // throws ENOENT/EACCES early with a clear message

Try / catch

try {
  await checkProfile(configPath)
} catch (e) {
  if (/ENOENT|EACCES|spawn/i.test(String(e))) {
    throw new Error(`Core binary missing or not executable at ${corePath}; reinstall the core`)
  }
  throw e
}

Prevention

After every core update, re-check the binary exists and is executable.
Exclude the app/core directory from antivirus quarantine rules.
Never leave the core path setting pointing at a manually moved binary.

When it happens

Trigger: The core executable could not be run at all during profile check: binary missing at the resolved core path, lacking execute permission, wrong architecture, or the spawn/exec call rejected with an error object instead of producing output.

Common situations: mihomo binary quarantined/blocked by antivirus or macOS Gatekeeper; core not executable after update (missing chmod +x); corrupted core download; ENOENT because the core path setting points to a removed file.

Related errors

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