Silent fallback to claude base modules for unsupported targets

resolveLegacyCompatibilitySelection validates target against the full SUPPORTED_INSTALL_TARGETS list (which includes codex and opencode), but LEGACY_COMPAT_BASE_MODULE_IDS_BY_TARGET only defines entries for claude, cursor, and antigravity. An unknown key lookup returns undefined, which then silently falls back to the claude config via the || chain:

const baseModuleIds = LEGACY_COMPAT_BASE_MODULE_IDS_BY_TARGET[target || 'claude']
  || LEGACY_COMPAT_BASE_MODULE_IDS_BY_TARGET.claude;

If this function is called with target: 'codex' or target: 'opencode' (both valid according to the guard on line 229), it will silently install claude-flavoured base modules instead of throwing a clear error. While the current call site in createLegacyCompatInstallPlan is protected by validateLegacyTarget, the public export of resolveLegacyCompatibilitySelection means future callers, tests, or direct usage could hit this silently wrong path.

The validation on line 229 should mirror the entries in LEGACY_COMPAT_BASE_MODULE_IDS_BY_TARGET rather than the broader SUPPORTED_INSTALL_TARGETS:

Orphaned modules left in selectedIds when a later sibling dependency fails target check

When resolving module A's dependencies in order [D1, D2]:

1. D1 is target-compatible → D1 (and all its transitive deps) are added to selectedIds and resolvedIds
2. D2 is target-incompatible → A is added to skippedTargetIds, false is returned
3. A is not added to selectedIds — but D1 is still there from step 1

D1 now appears in the final selectedModules even though the only top-level requester (A) was ultimately skipped. In shallow dependency trees this may be harmless (D1 might be requested elsewhere), but in deep or unique chains this results in modules being installed that have no remaining requester.

A minimal fix is to track which modules were added during the resolution of a particular root module and roll them back on failure:

visitingIds.add(moduleId);
const addedThisRound = [];
for (const dependencyId of module.dependencies) {
  const dependencyResolved = resolveModule(dependencyId, moduleId, rootRequesterId || moduleId);
  if (!dependencyResolved) {
    // roll back any modules added while resolving this branch
    for (const id of addedThisRound) { selectedIds.delete(id); resolvedIds.delete(id); }
    visitingIds.delete(moduleId);
    if (!dependencyOf) { skippedTargetIds.add(moduleId); }
    return false;
  }
  addedThisRound.push(dependencyId);
}

At minimum, this should be documented so future contributors are aware of the partial-selection behaviour.

Manifest always loaded even when moduleIds is empty

validateInstallModuleIds unconditionally calls loadInstallManifests, which reads and parses three JSON files from disk. When moduleIds is an empty array there are no IDs to validate, so the file I/O is wasted on every normalizeInstallRequest call that doesn't supply modules (e.g., all legacy-language installs).

A cheap guard avoids the unnecessary I/O:

claudeRulesDir forwarded but silently dropped in legacy-compat path

createLegacyCompatInstallPlan accepts claudeRulesDir in its options object (forwarded here from install-apply.js via CLAUDE_RULES_DIR), but neither createLegacyCompatInstallPlan nor the downstream createManifestInstallPlan consumes it. The old legacy mode honoured this env var to redirect the Claude rules destination; the new legacy-compat path silently ignores it.

This is a quiet breaking change for users who set CLAUDE_RULES_DIR. Consider either:

• Explicitly documenting that CLAUDE_RULES_DIR is no longer respected in legacy-compat mode, or
• Surfacing a warning when claudeRulesDir is non-null and the mode is legacy-compat.

Roll back resolved deps when skipping a module

When resolveModule bails out on an incompatible dependency, it returns false but keeps dependencies that were already added to selectedIds earlier in the same traversal. For mixed-support trees this installs modules even though the requested root is skipped: for example, resolving framework-language on antigravity selects rules-core/agents-core/commands-core before failing on platform-configs, so the plan applies partial modules instead of skipping the incompatible tree. This changes install results for explicit module requests and can unexpectedly mutate targets with modules users did not successfully request.

Useful? React with 👍 / 👎.

⚠️ Potential issue | 🟡 Minor

claudeRulesDir option is accepted but not forwarded to createManifestInstallPlan.

The function accepts options.claudeRulesDir (documented by the caller in runtime.js) but does not pass it to createManifestInstallPlan. If a user sets CLAUDE_RULES_DIR expecting custom rules directory support, the legacy-compat path will silently ignore it.

   return createManifestInstallPlan({
     sourceRoot,
     projectRoot,
     homeDir: options.homeDir,
+    claudeRulesDir: options.claudeRulesDir,
     target,
     profileId: null,
     moduleIds: selection.moduleIds,

#!/bin/bash
# Check if createManifestInstallPlan accepts claudeRulesDir
rg -n 'claudeRulesDir' scripts/lib/install-executor.js

Verify each finding against the current code and only fix it if needed.

In `@scripts/lib/install-executor.js` around lines 501 - 531, The
createLegacyCompatInstallPlan function accepts options.claudeRulesDir but does
not forward it to createManifestInstallPlan; update the
createManifestInstallPlan call inside createLegacyCompatInstallPlan to include
claudeRulesDir: options.claudeRulesDir (or options.claudeRulesDir || undefined)
so the provided CLAUDE_RULES_DIR is honored when building the legacy-compat
install plan; reference createLegacyCompatInstallPlan and
createManifestInstallPlan when making this change.

⚠️ Potential issue | 🟡 Minor

#!/bin/bash
# Verify createLegacyCompatInstallPlan does not use claudeRulesDir
rg -n -A 30 'function createLegacyCompatInstallPlan' scripts/lib/install-executor.js | head -40

# Check if createManifestInstallPlan accepts claudeRulesDir
rg -n -B 5 'function createManifestInstallPlan' scripts/lib/install-executor.js | head -20

# Check the non-legacy path around line 38-47 in runtime.js to see how it handles claudeRulesDir
sed -n '27,50p' scripts/lib/install/runtime.js

# Get full createManifestInstallPlan function signature and first 50 lines to see parameters
sed -n '570,620p' scripts/lib/install-executor.js

# Check createLegacyInstallPlan to see if it uses claudeRulesDir
rg -n -A 20 'function createLegacyInstallPlan' scripts/lib/install-executor.js

Remove unused claudeRulesDir parameter or pass it through to downstream functions.

claudeRulesDir is passed to createLegacyCompatInstallPlan but is never extracted or used within the function. In contrast, createLegacyInstallPlan (the non-compat legacy path) properly extracts and uses this parameter. This inconsistency creates a misleading API and could cause bugs if custom rules directories are configured.

Either pass claudeRulesDir to createManifestInstallPlan for consistency, or remove the parameter from the call site if legacy-compat mode intentionally does not support custom rules directories.

Verify each finding against the current code and only fix it if needed.

In `@scripts/lib/install/runtime.js` around lines 27 - 36, The call to
createLegacyCompatInstallPlan currently supplies claudeRulesDir but that
parameter is unused downstream; either remove claudeRulesDir from the argument
list in the request.mode === 'legacy-compat' branch, or (preferred for parity)
forward it into the compat plan by updating createLegacyCompatInstallPlan to
accept and pass claudeRulesDir through to whatever downstream function
createLegacyInstallPlan or createManifestInstallPlan uses; locate the branch
keyed by request.mode, adjust the call site to match createLegacyInstallPlan's
signature or update createLegacyCompatInstallPlan to accept a claudeRulesDir
parameter and use it consistently.

⚠️ Potential issue | 🟡 Minor

Isolate the unknown-module failure test from real environment paths.

This case currently runs without temp cwd/HOME. If failure timing regresses, the test can write into the invoking environment. Run it in temp dirs and assert no state file was created.

-  if (test('rejects unknown explicit manifest modules before resolution', () => {
-    const result = run(['--modules', 'ghost-module']);
-    assert.strictEqual(result.code, 1);
-    assert.ok(result.stderr.includes('Unknown install module: ghost-module'));
-  })) passed++; else failed++;
+  if (test('rejects unknown explicit manifest modules before resolution', () => {
+    const homeDir = createTempDir('install-apply-home-');
+    const projectDir = createTempDir('install-apply-project-');
+
+    try {
+      const result = run(['--modules', 'ghost-module'], { cwd: projectDir, homeDir });
+      assert.strictEqual(result.code, 1);
+      assert.ok(result.stderr.includes('Unknown install module: ghost-module'));
+      assert.ok(!fs.existsSync(path.join(homeDir, '.claude', 'ecc', 'install-state.json')));
+      assert.ok(!fs.existsSync(path.join(projectDir, '.cursor', 'ecc-install-state.json')));
+    } finally {
+      cleanup(homeDir);
+      cleanup(projectDir);
+    }
+  })) passed++; else failed++;

Verify each finding against the current code and only fix it if needed.

In `@tests/scripts/install-apply.test.js` around lines 316 - 320, The test
"rejects unknown explicit manifest modules before resolution" currently runs in
the real environment; modify it to create and use a temporary directory as both
process cwd and HOME before invoking run(['--modules', 'ghost-module']) (e.g.,
by chdir or passing env to run), run the command there, assert result.code === 1
and stderr contains 'Unknown install module: ghost-module', then assert that no
state file (the project's state file name used elsewhere in tests) was created
in that temp dir, and finally clean up/reset cwd and HOME; update references in
the test body surrounding run(...) and assertion calls to use the temp dir
environment.

P1: Skipping a module due to an incompatible dependency can still leave earlier dependencies selected, producing orphan installs from a tree that should have been skipped.

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/lib/install-manifests.js, line 376:

<comment>Skipping a module due to an incompatible dependency can still leave earlier dependencies selected, producing orphan installs from a tree that should have been skipped.</comment>

<file context>
@@ -248,15 +368,27 @@ function resolveInstallPlan(options = {}) {
+        moduleId,
+        rootRequesterId || moduleId
+      );
+      if (!dependencyResolved) {
+        visitingIds.delete(moduleId);
+        if (!dependencyOf) {
</file context>