affaan-m/ECC · error · Error

Refusing to trust managed install-state at ${plan.installSta

Error message

Refusing to trust managed install-state at ${plan.installStatePath}: target identity does not match the current Kimi install plan.

What it means

Thrown by assertPriorInstallStateMatchesPlan when the install-state's recorded target identity ({id, target, kind}) does not equal plan.adapter's {id, target, kind}. The installer will only trust an install-state that was written by the same adapter (target type + id + kind) as the current plan; a mismatch means the state belongs to a different harness/install kind and its ownership claims do not apply. This prevents a Kimi plan from inheriting ownership recorded by an unrelated adapter.

Source

Thrown at scripts/lib/multi-harness-setup.js:106

    currentFingerprint.exists !== expectedFingerprint.exists
    || currentFingerprint.sha256 !== expectedFingerprint.sha256
  ) {
    throw new Error(
      `Refusing to overwrite an unowned or changed install-state at ${plan.installStatePath}. `
      + 'Re-run the guided preview and review the existing state before retrying.'
    );
  }
}

function assertPriorInstallStateMatchesPlan(state, plan) {
  const target = state.target || {};
  const adapter = plan.adapter || {};
  if (
    target.id !== adapter.id
    || target.target !== adapter.target
    || target.kind !== adapter.kind
  ) {
    throw new Error(
      `Refusing to trust managed install-state at ${plan.installStatePath}: `
      + 'target identity does not match the current Kimi install plan.'
    );
  }
  if (!pathsMatch(target.root, plan.targetRoot)) {
    throw new Error(
      `Refusing to trust managed install-state at ${plan.installStatePath}: `
      + 'recorded root does not match the current install root.'
    );
  }
  if (!pathsMatch(target.installStatePath, plan.installStatePath)) {
    throw new Error(
      `Refusing to trust managed install-state at ${plan.installStatePath}: `
      + 'recorded install-state path does not match the current install-state path.'
    );
  }
}

View on GitHub (pinned to 01e15490f0)

Solutions

Remove the install-state at plan.installStatePath and re-run the guided preview so it is recreated by the current adapter.
Verify plan.adapter.id, plan.adapter.target, and plan.adapter.kind match the target that originally authored the state (inspect state.target in the JSON).
If migrating adapters intentionally, discard the old state rather than trying to reuse it.
Confirm you are running the intended harness/profile; an accidental target switch produces this mismatch.

Example fix

// before: state authored by adapter A, now applying adapter B's plan
// state.target = { id:'kimi-cli', target:'kimi', kind:'managed' }
// plan.adapter = { id:'kimi-editor', target:'kimi', kind:'managed' }
await applyMultiHarnessPlan(plan); // throws [281]

// after: discard mismatched state and regenerate
fs.rmSync(plan.installStatePath, { force: true });
const fresh = await createMultiHarnessPlan(req);
await applyMultiHarnessPlan(fresh);

Defensive patterns

Strategy: validation

Validate before calling

const fs = require('fs');
function assertStateAdapterMatches(statePath, adapter) {
  if (!fs.existsSync(statePath)) return; // nothing to mismatch
  const state = JSON.parse(fs.readFileSync(statePath, 'utf8'));
  const t = state.target || {};
  if (t.id !== adapter.id || t.target !== adapter.target || t.kind !== adapter.kind) {
    throw new Error(`Existing install-state was authored by a different adapter (${t.id}/${t.target}/${t.kind}); remove it or change plan.adapter.`);
  }
}
// before applying:
assertStateAdapterMatches(plan.installStatePath, plan.adapter);

Type guard

function isAdapterConsistent(plan) {
  return plan && plan.adapter
    && typeof plan.adapter.id === 'string'
    && typeof plan.adapter.target === 'string'
    && typeof plan.adapter.kind === 'string';
}

Try / catch

try {
  await applyMultiHarnessPlan(plan);
} catch (err) {
  if (/target identity does not match the current Kimi install plan/.test(err.message)) {
    fs.rmSync(plan.installStatePath, { force: true });
    const fresh = await createMultiHarnessPlan(plan.request);
    await applyMultiHarnessPlan(fresh);
  } else throw err;
}

Prevention

Never reuse an install-state across adapter types; delete and regenerate on adapter change.
Pin the ECC version when you need stable adapter identifiers across runs.
Inspect state.target before applying if the project was cloned from elsewhere.
Keep plan.adapter construction in one place so id/target/kind are consistent.

When it happens

Trigger: Reached via readOwnedDestinations -> assertPriorInstallStateMatchesPlan when plan.installStatePath exists and parses. Fires when state.target.id !== plan.adapter.id, state.target.target !== plan.adapter.target, or state.target.kind !== plan.adapter.kind. Common when reusing an install-state path across adapter types, after an adapter migration, or when plan.adapter was constructed with a different id/kind than what wrote the state.

Common situations: Switching the managed install target kind while pointing at the same install-state path; a stale state left by an older ECC version that used different adapter identifiers; manually copying a project directory that contains another adapter's install-state; running a Kimi profile install over a state file authored by a different target.

Related errors

AI-assisted analysis of affaan-m/ECC@01e15490f0 (2026-08-13). Data as JSON: /api/errors/ce375379b856fb4a. Report an issue: GitHub.