affaan-m/ECC · error

Refusing to ' ': no trusted install root resolved.

Error message

Refusing to ${action} '${target}': no trusted install root resolved.

What it means

assertWithinTrustedRoot() refuses to perform the requested action when the trusted root parameter is empty/falsy — i.e. the library could not resolve the trusted install root against which containment would be checked. This is a fail-closed design: without a verified root there is no safe boundary, so any write/repair is rejected instead of defaulting to the current directory.

Solutions

  1. Ensure the trusted install root is resolved before the call — run the library's setup/init step or use its canonicalRoot() helper to obtain the root.
  2. Set or repair the configuration/env that supplies the install root (e.g. the plugin install location, install manifest, or documented env var).
  3. If calling the API directly, resolve and pass a real existing directory string as the root argument.
  4. Reinstall or re-run the installer so the trusted root metadata is written to the expected location.

Example fix

// before
assertWithinTrustedRoot(target, process.env.MY_INSTALL_ROOT, 'write') // unset
// after
const root = process.env.MY_INSTALL_ROOT || detectInstallRoot();
if (!root) throw new Error('Install root not configured; run setup first');
assertWithinTrustedRoot(target, root, 'write')
Defensive patterns

Strategy: try-catch

Validate before calling

if (!root || typeof root !== 'string') {
  throw new Error('Trusted install root is not configured; run the installer/setup step first.');
}
assertWithinTrustedRoot(target, root, action);

Type guard

function hasTrustedRoot(v) {
  return typeof v === 'string' && v.length > 0;
}

Try / catch

try {
  assertWithinTrustedRoot(target, root, 'write');
} catch (e) {
  if (/no trusted install root resolved/.test(e.message)) {
    console.error('Install root missing — re-run setup or set the install-root config/env, then retry.');
  } else throw e;
}

Prevention

When it happens

Trigger: Calling assertWithinTrustedRoot(target, '') or assertWithinTrustedRoot(target, undefined), or indirectly when root-producing helpers (canonicalRoot, resolveAllowedProjectConfigHome, etc.) fail to resolve the install root — e.g. env var unset, config file absent, or the resolution function returned null.

Common situations: Running the tool outside a recognized install (no trusted root recorded); ECC-related env/config not set up after a fresh clone or plugin migration; the root config file was deleted or renamed; calling the low-level guard directly without resolving the root first.

Understand the failure class

Background: "missing required config value" errors: why libraries refuse to start when a configuration key is empty, unset, or blank — this error's family across 48 libraries.

Related errors


AI-assisted analysis of affaan-m/ECC@8321021c54 (2026-09-16). Data as JSON: /api/errors/564cbb47627aa446. Report an issue: GitHub.

Appendix: source

Thrown at scripts/lib/path-safety.js:90

  }

  try {
    return resolveContainment(target, root).contained;
  } catch {
    return false;
  }
}

/**
 * Fail-closed guard: throw unless `target` is contained within `root`.
 * Returns the canonicalized target path on success.
 */
function assertWithinTrustedRoot(target, root, action = 'write') {
  if (!target || typeof target !== 'string') {
    throw new Error(`Refusing to ${action}: missing destination path.`);
  }
  if (!root) {
    throw new Error(`Refusing to ${action} '${target}': no trusted install root resolved.`);
  }

  let containment;
  try {
    containment = resolveContainment(target, root);
  } catch {
    containment = null;
  }
  if (!containment || !containment.contained) {
    throw new Error(`Refusing to ${action} outside the install root: '${target}' is not within '${root}'.`);
  }
  return containment.realTarget;
}

module.exports = {
  realpathNearestExisting,
  isWithinRoot,
  assertWithinTrustedRoot

View on GitHub (pinned to 8321021c54)