@niroai/niro 0.12.0 → 0.15.0

package/CHANGELOG.md

@@ -4,6 +4,196 @@ Notable changes to `@niroai/niro`. Dates are release dates.
 
 ## Unreleased
 
+## 0.15.0 — 2026-09-21
+
+### Twenty more file types are offered for upload
+
+`niro init` and the folder sync decide which files to offer the server from a fixed list of
+extensions (`src/lib/folderSync.js`). That list was a hand-kept copy of the server's own list and
+had fallen behind it in two places:
+
+- the ten C++ extensions the parser routes to its C++ grammar besides `.cpp`, `.h` and `.hpp`:
+  `.cc`, `.cxx`, `.hxx`, `.hh`, `.h++`, `.c++`, `.tcc`, `.ipp`, `.inl`, `.tpp`. A C++ project with
+  `include/widget.hxx` and `detail/vector.tcc` never had those two files in its graph, because the
+  CLI never offered them.
+- ten more the parser has always understood but the CLI never offered: `.kts`, `.csx`, `.rake`,
+  `.gemspec`, `.phtml`, `.php3`, `.php4`, `.php5`, `.pyi`, `.pyw`.
+
+A test now reads the server's Java list and fails if the two drift apart again
+(`test/sourceExtensionDrift.test.js`); the server carries the mirror-image test.
+
+The server's own filter remains the final say, so an older CLI simply offers fewer files and a
+newer CLI against an older server has its extra offers declined. Either order of upgrade is safe;
+the new files reach the graph once both sides are current (ai-orchestrator `cadb5360` or later).
+
+Note: 0.14.0 was cut in this repository but never published to npm, so upgrading from 0.13.0 brings
+the 0.14.0 change below as well.
+
+### A file whose name contains `+` no longer stops a folder syncing
+
+After `niro init`, the server replies with the patterns saying which paths belong to the
+project, and the watch daemon checks every path against them: on each file event, on each
+delta and backstop pass, and once more before it asks the server to delete anything.
+
+For a file at the top level of a repository, the pattern the server sends is the filename
+itself. The daemon turned patterns into regular expressions but escaped only the dot, so a
+name carrying a character that means something in a regular expression was read as an
+instruction rather than as a name. With `main.c++` at a repository root, `main.c++` became
+`/^main\.c++$/`, which is not a valid expression. Every sync pass for that folder then failed.
+The daemon stayed up and printed nothing, so the folder simply went quiet.
+
+The `.c++` and `.h++` file types added in this same release are what would have exposed it. The
+same flaw had a quieter form that needed no C++ at all: a root-level file called `app (copy).js`
+built a valid expression with a capture group, so the file stopped matching its own pattern and
+was never synced again. A directory named `libstdc++` hit the throwing form, because saying yes
+to "New directory detected. Add to sync?" stores the directory's own name as a pattern.
+
+The matcher now escapes every character that has a special meaning, leaving only `*` and `**`
+as wildcards, so a pattern can no longer fail to compile. Behaviour for patterns that already
+worked is unchanged: old and new were compared over 10,701 path-and-pattern pairs taken from
+three real repositories and agreed on every one.
+
+## 0.14.0 — 2026-09-19
+
+### `niro init` on a folder of repos now indexes each repo, not the folder
+
+If you run `niro init` in a folder that is not itself a git repository but contains repositories —
+an `apps/` folder, a `~/projects/github/<org>/` folder, anything that groups checkouts — each
+repository is now onboarded in its own right, with its own git URL and its own branch, into one
+project.
+
+Before this, the folder itself was registered as a single repo. A folder has no git remote, so it
+got a synthetic `local://<folder-name>` URL and no branch at all, and the monorepo splitter then
+tried to recover the structure by reading folder layout. On one customer's tree that produced 92
+internal repos from 14 real ones: 92 of 92 carried `local://apps`, none had a branch, 58 of them
+were vendored copies and reference checkouts of other people's projects, and 45% of the indexing
+spend went on code the customer had never written. Because no repo had a URL of its own, MCP could
+not match a repo from inside its own folder, and kept offering to create a temporary project in
+code that was already indexed.
+
+The repositories underneath were the boundaries the customer had already declared. Reading them is
+better than re-deriving them.
+
+What you will see:
+
+```
+    apps is not a git repository, but contains 14 that are.
+    Niro will index each repo separately, with its own git URL and branch.
+
+        + voibe-backend
+        + voibe_app
+        - legal-docs — not a git repository, NOT indexed
+```
+
+Folders holding code but no repository are reported rather than skipped in silence: from that point
+on, editing a file in one of them does nothing, and you should know which ones they are. Run
+`niro init` inside one to add it.
+
+The scan stops at the first repository it finds down any path, so a repository vendored inside
+another — a submodule, a `third_party/` checkout — is indexed as part of its parent rather than as a
+service of its own.
+
+Unchanged: a folder that IS a git repository still indexes whole, submodules and all. A folder with
+no git anywhere still uploads as one repo, as before.
+
+### A folder whose repositories sit deeper than one level is no longer refused
+
+`niro init` requires a build file at the folder or just below it, which is right for a folder of
+documents and wrong for `~/projects/github/<org>/<repo>`, where the repositories are three levels
+down and every folder above them is empty. That was refused with "No project found" and a pointer to
+`--force`, and `--force` would then upload the entire tree as one repo. A folder holding
+repositories is now exempt from that rule, because it has already declared its projects.
+
+The refusal message for a folder that genuinely holds nothing indexable now says what Niro looks
+for, and suggests running from the folder where the code actually is.
+
+### Fixed
+
+- The background watcher was being installed once per repository when onboarding several at once,
+  asking for your password each time. It is one process; it is now set up once per run.
+
+
+## 0.13.0 — 2026-09-08
+
+### Upgrading
+
+You do not have `niro upgrade` yet, so this one takes two commands:
+
+```bash
+npm install -g @niroai/niro@latest
+niro upgrade --finish
+```
+
+The first gets the package. The second is the half npm cannot do: it re-runs the installer for
+every assistant you have configured and restarts the background watcher. Then restart your
+assistant. Skipping the second command leaves you on this version with the previous version's
+hooks, skills and instruction files, which is the exact problem this release exists to fix.
+
+From here on it is one command, `niro upgrade`, which does all of it.
+
+### `niro upgrade` gets the new version AND the things a new version cannot bring with it
+
+Upgrading was `npm install -g @niroai/niro@latest`, and every release note in this file said so and
+nothing else. That command is not enough, and has never been enough. The MCP entry is fine: it runs
+plain `niro` off your `PATH` with no version in it, so the new server is picked up for free. But the
+hooks, the skills and the CLAUDE.md/AGENTS.md/rules text are written into your home folder as fixed
+text at install time, not read from the package as it runs. npm cannot touch them. Nothing told you
+that, and nothing re-ran the installer, so a machine that installed once in June was still running
+June's instructions in September while reporting the current version. The background watcher had the
+same problem from the other end: it is a long-running process holding the code it loaded at start,
+so replacing files on disk left it on the old version until something restarted it.
+
+`niro upgrade` does all three. It replaces the package, re-runs the installer for every assistant it
+can prove is configured, and restarts the watcher if it is running.
+
+It runs as two processes, and the reason is worth writing down. Every command in this CLI is loaded
+lazily, inside its own action handler, and `npm install -g` replaces the folder those files are
+loaded from. One process that ran npm and then carried on would be running the modules it loaded
+before the swap alongside modules loaded after it. So phase one runs npm, executes the NEW binary
+with `--finish`, and stops, requiring nothing in between; phase two is a fresh process reading the
+new tree. `niro start` has always dodged the same trap the same way, by only installing globally
+when it is running from the npx cache and then handing over.
+
+Which assistants to refresh is worked out by looking, because nothing on disk records what you
+chose. All 14 clients are covered, because the installer leaves a file this repo owns in every case:
+eight write a JSON config whose path `setup.js` builds, and the other six also get a marker appended
+to a markdown file written here and stripped by `teardown.js` (`~/.claude/CLAUDE.md`,
+`~/.gemini/GEMINI.md`, `~/.copilot/copilot-instructions.md`, `~/.factory/AGENTS.md`), plus codex's
+`[mcp_servers.niro]` table and goose's `extensions:` entry. The marker is appended only after the
+registration command succeeded, so its presence means the client really was configured. Detection is
+read-only, and it is deliberately strict: a client whose entry is `enabled: false` or
+`disabled: true` is one you switched off, so it is left alone rather than switched back on; a
+marker has to be on a line of its own, because a sentence mentioning it is not an install; and every
+path has to be absolute.
+
+`niro upgrade --finish` on its own skips npm and only refreshes the assistant files and the watcher,
+which is what you want if you already ran `npm install -g` by hand.
+
+Without a usable home folder it checks nothing and says so. Every path would otherwise resolve
+against the current folder, which is how the reverted serve-time self-heal came to write into a
+project's own `.claude/settings.json` (see the 2026-07-30 revert). "Usable" means absolute, and it
+also means rejecting a `HOME` set to the empty string even when `USERPROFILE` would fill in, because
+four of the client path builders read `HOME` directly and would otherwise hand back a relative path.
+This command never writes a settings file itself: refreshing hooks means spawning the existing
+installer, once per client.
+
+It refuses to upgrade a copy you are not running. The first real run of this command was from a
+checkout linked with `npm link`, and `npm install -g` deleted that link and put the published
+package in its place. So before npm is allowed to touch anything, `niro upgrade` looks at which
+copy is running: the global package folder being a symlink means `npm link`, and it stops and says
+so; a checkout or an npx copy that is not the global install stops too. `--force` overrides either.
+
+It also asks the version it just installed whether it has an `upgrade` command before handing over
+to it, because the newest published version can predate the one you are running. Without that
+check the hand-over fails with a bare `error: unknown command 'upgrade'` and the advice printed is
+to re-run a command that does not exist. Now it prints the two commands that do work.
+
+Failures are visible. Each one has its own exit code (npm failed, no binary after npm, hand-over
+failed, refresh incomplete), an interrupted npm is reported as interrupted rather than as "nothing
+changed", a hand-over that cannot start prints why, and the hand-over carries a marker so a version
+that does not understand `--finish` cannot loop back into running npm again.
+
+
 ## 0.12.0 — 2026-09-06
 
 ### Before an edit to indexed source, Claude is asked to map the method and to verify those flows afterwards

package/README.md

@@ -71,6 +71,12 @@ Rebuild the index by hand and watch it finish. Like `niro status`, it picks the
 branch you are on, so on a branch with a temporary project it rebuilds that one. Name a project to
 rebuild a different one.
 
+```bash
+niro upgrade
+```
+Get the latest version, and bring your hooks, skills and watcher with it. See
+[Upgrading](#upgrading).
+
 ```bash
 niro doctor
 ```
@@ -254,6 +260,58 @@ Watch this folder in the foreground instead, for one session.
 
 ---
 
+## Upgrading
+
+**Check which you are on first:**
+
+```bash
+niro --version
+```
+
+**On 0.13.0 or newer**, one command:
+
+```bash
+niro upgrade
+```
+
+Replaces the package with the latest published version, then puts back the two things replacing the
+package cannot reach: it re-runs the installer for every assistant you have configured, and
+restarts the background watcher. Restart your assistant afterwards.
+
+**On anything older than 0.13.0**, you do not have `niro upgrade` yet, so it is two commands, once:
+
+```bash
+npm install -g @niroai/niro@latest
+niro upgrade --finish
+```
+
+The first gets the package. The second does the half npm cannot: your hooks, skills and the
+watcher. After that, `niro upgrade` on its own is enough. Do not stop after the first command:
+that leaves you on the new version running the old version's hooks, skills and instruction files,
+which is the problem `niro upgrade` exists to solve.
+
+**Why it is more than an npm install.** The hooks, skills and instruction files are written into
+your home folder as fixed text when you install, not read out of the package as it runs, so a newer
+package does not change them. The watcher is a long-running process still holding the code it
+started with. The MCP config is the one part that needs nothing done to it: it runs plain `niro`
+from your `PATH` with no version pinned in it, so the new server is picked up on its own.
+
+**Restart your assistant last.** Skills and hooks are read when it starts, so nothing above reaches
+a session that is already open.
+
+Fully by hand, if you would rather:
+
+```bash
+npm install -g @niroai/niro@latest
+niro mcp install       # once per assistant you use
+niro service install   # only if you run the watcher
+```
+
+`niro start` upgrades nothing. On a machine that has connected an assistant once it skips the
+connect step, so the old hooks and skills stay where they are.
+
+---
+
 ## Reference
 
 Add `--help` to any command for its flags. Add `--json` to `whoami`, `info`, `status`,
@@ -302,6 +360,10 @@ does nothing until you do.
 
 **Auto-sync is not running.** `npm install -g pm2`, then `niro service install`.
 
+**A command or feature in the changelog is missing.** You are on an older version. Check with
+`niro --version`, then see [Upgrading](#upgrading): before 0.13.0 it takes two commands, after it
+one. Plain `npm install -g` on its own always leaves your hooks and skills on the old version.
+
 **A folder was refused.** Niro will not index your home folder, or a folder with no build file
 in it. Point it at the repo you meant.
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@niroai/niro",
-  "version": "0.12.0",
-  "description": "Niro — one package: the niro CLI plus the Niro MCP server (code intelligence for AI coding assistants).",
+  "version": "0.15.0",
+  "description": "Niro \u2014 one package: the niro CLI plus the Niro MCP server (code intelligence for AI coding assistants).",
   "keywords": [
     "niro",
     "mcp",

package/src/commands/init.js

@@ -41,7 +41,7 @@ const color = require("../lib/color");
 const watchDaemon = require("../lib/watchDaemon");
 const { login } = require("./login");
 const { watchStatus } = require("./build");
-const { currentIndent } = require("../lib/nestedOutput");
+const { currentIndent, withIndent } = require("../lib/nestedOutput");
 
 /** Depth as spaces, for the \r-written lines that bypass withIndent's console wrappers. */
 function nestPad() {
@@ -99,9 +99,24 @@ async function init(pathArg, opts = {}) {
   // repo for must not start failing its re-run just because it has no build file.
   // See src/lib/onboardTarget.js.
   const knownEntry = watchState.get(targetDir, apiUrlBeforeLogin);
+  // A FOLDER THAT HOLDS GIT REPOS ALREADY DECLARES ITS PROJECTS, just not with a build file.
+  //
+  // The descriptor rule looks for package.json / pom.xml / go.mod in this folder or just below it,
+  // and refuses when it finds none. That is right for a folder of holiday photos. It is wrong for
+  // ~/projects/github/<org>/<repo>, where the repos are three levels down and the folders above them
+  // hold nothing at all: the scan found no descriptor, the user was told "No project found" and
+  // pointed at --force, and --force would then upload the whole tree as ONE repo — the exact outcome
+  // this release exists to prevent. The comment on CHILD_SCAN_MAX_DEPTH calls that layout the
+  // commonest one on disk. Reproduced on a demo tree on 2026-09-19 before this line existed.
+  //
+  // Cheap because it stops at the first repo it sees, and only runs when the descriptor scan already
+  // came back empty. Every other refusal in ensureOnboardable (home directory, filesystem root) still
+  // applies: this exempts the descriptor rule alone.
+  const holdsGitRepos = () => collectNestedGitRepos(targetDir).repos.length > 0;
   if (!onboardTarget.ensureOnboardable(targetDir, {
     ...opts,
     alreadyRegistered: !!(knownEntry && knownEntry.gitId),
+    hasGitReposBeneath: holdsGitRepos,
   })) {
     process.exitCode = 1;
     return;
@@ -244,6 +259,25 @@ async function init(pathArg, opts = {}) {
   // onboarded, so resolve each immediate git-repo child against the server too — this
   // catches children indexed via the web UI / as separate repos.
   const childScan = await scanIndexedChildren(targetDir, opts);
+
+  // THE FOLDER IS NOT A REPO BUT CONTAINS SOME: onboard each of them, not the folder.
+  //
+  // `git.inspect` walks UPWARDS, so repoRoot can be an ANCESTOR of targetDir. "This folder is a
+  // repo" therefore has to compare paths, not just test for a truthy repoRoot.
+  //
+  // Why this exists. Onboarding the parent registers ONE repo, and a folder with no git remote gets
+  // the synthetic `local://<name>` URL from step 4. Measured on a customer's tree on 2026-09-18:
+  // `niro init` in an `apps/` folder holding 14 real repos produced 92 internal repos, every one of
+  // them carrying `local://apps` and a null branch — so no repo had its own identity, none could be
+  // matched by MCP from its own folder (it kept offering to create a temp project inside indexed
+  // code), and nothing could track a per-repo branch. The repos beneath were the customer's own
+  // declared boundaries; the split was re-deriving them, badly, from folder structure.
+  const targetIsRepoRoot = !!gitInfo.repoRoot
+    && path.resolve(gitInfo.repoRoot) === path.resolve(targetDir);
+  if (!targetIsRepoRoot && childScan.all.length) {
+    return onboardDiscoveredRepos({ targetDir, defaultName, childScan, opts });
+  }
+
   if (childScan.indexed.length) {
     console.error(fail(`\n    This folder contains ${childScan.indexed.length} repo(s) already indexed in Niro:`));
     for (const c of childScan.indexed) {
@@ -642,7 +676,14 @@ async function init(pathArg, opts = {}) {
   }
 
   // --defaults promised "no prompts": never surface the PM2 install offer there.
-  const daemon = await watchDaemon.ensureWatchDaemon({ skipPrompts: !!opts.defaults });
+  // INSTALLED ONCE PER RUN, not once per repo. The daemon is a single global PM2 process that reads
+  // ~/.niro/projects.json, so a second install is a no-op that still shells out to `pm2 startup`,
+  // which asks for sudo. Onboarding a folder of 6 repos asked six times and printed six identical
+  // sudo failures (seen on the demo tree, 2026-09-18); the caller that onboards several repos
+  // installs it itself, after the last one.
+  const daemon = opts.skipDaemonSetup
+    ? { ok: true }
+    : await watchDaemon.ensureWatchDaemon({ skipPrompts: !!opts.defaults });
 
   // The closing banner must not read as an all-clear when auto-sync is dead —
   // customers were only discovering the missing daemon after a reboot.
@@ -694,6 +735,135 @@ const CHILD_SCAN_MAX = 60;       // bound the number of nested repos we resolve
 // single repo and 50 for this monorepo, versus 5 and 13 at depth 2.
 const CHILD_SCAN_MAX_DEPTH = 4;
 
+/**
+ * Onboard every git repo found beneath a folder that is not itself a repo, into ONE project.
+ *
+ * <b>Why one project and not one per repo.</b> Cross-service answers — who calls this endpoint, what
+ * breaks if I change this, trace this request across services — resolve by unioning the repos of a
+ * PROJECT. Fourteen projects would give fourteen islands and lose the thing the customer is paying
+ * for. So: one project, N repos, each carrying its own origin URL and its own HEAD branch.
+ *
+ * <b>Why each repo goes through init() again rather than a bespoke path.</b> Registering a repo is
+ * not one call: it dedupes against the same repo in this and other projects, reuses a gitId rather
+ * than re-uploading, filters the manifest, pushes include/exclude patterns, scans env vars and writes
+ * the per-folder watch entry. `start.js` already re-enters init this way with `nested: true`. A second
+ * implementation of that would drift from this one within a release.
+ *
+ * Folders holding code but no repo are REPORTED, never silently skipped: from this point on, editing
+ * a file in one of them does nothing at all, and the user has to have been told once. Silently
+ * dropping code is the failure ADR-023 was written against.
+ */
+async function onboardDiscoveredRepos({ targetDir, defaultName, childScan, opts },
+    runInit = init, readEntry = watchState.peek) {
+  const already = childScan.indexed;
+  const fresh = childScan.all.filter(
+    (r) => !already.some((c) => path.resolve(c.path) === path.resolve(r))
+  );
+  const codeFoldersWithoutRepo = nonRepoCodeFolders(targetDir, childScan.all);
+
+  console.log(`\n    ${ok(`${path.basename(targetDir)} is not a git repository, but contains ${childScan.all.length} that are.`)}`);
+  console.log(`    Niro will index each repo separately, with its own git URL and branch.\n`);
+  for (const r of fresh) console.log(`        ${ok("+")} ${path.relative(targetDir, r) || path.basename(r)}`);
+
+  // Already indexed elsewhere: SKIPPED, not a reason to refuse the rest.
+  //
+  // The whole-run refusal further down exists because onboarding the PARENT would upload that child's
+  // content a second time. Here the parent is never uploaded, so that reasoning does not apply, and
+  // refusing thirteen new repos because the fourteenth is known would be the wrong answer.
+  for (const c of already) {
+    const where = c.projects.map((x) => `"${x.alias || x.project_id}"`).join(", ");
+    console.log(`        ${warn("-")} ${path.relative(targetDir, c.path)} — already indexed in ${where}, skipping`);
+  }
+  for (const f of codeFoldersWithoutRepo) {
+    console.log(`        ${warn("-")} ${path.relative(targetDir, f)} — not a git repository, NOT indexed`);
+  }
+  if (childScan.unverified.length) {
+    console.log(`        ${warn("?")} ${childScan.unverified.length} repo(s) could not be checked against the server; they will be onboarded.`);
+  }
+  if (childScan.truncated) {
+    console.log(color.dim(`        (Stopped after the first ${CHILD_SCAN_MAX} repos; deeper ones were not scanned.)`));
+  }
+
+  if (!fresh.length) {
+    console.log(`\n    ${warn("Nothing new to index.")} Every repo here is already in Niro.`);
+    return;
+  }
+  if (codeFoldersWithoutRepo.length) {
+    console.log(color.dim(`\n    Folders marked NOT indexed will not sync. Run \`niro init\` inside one to add it.`));
+  }
+
+  if (!opts.defaults && !opts.force && !prompt.isNonInteractive()) {
+    if (!(await prompt.confirm(`\n    Index these ${fresh.length} repo(s)?`, true))) return;
+  }
+
+  // The FIRST repo creates the project; the rest attach to whatever it created. Hoisting project
+  // creation out of init() instead would mean duplicating the new-vs-existing resolution, the name
+  // availability check and the alias-to-project_id reassignment that init already does.
+  let projectRef = opts.addTo || null;
+  let onboarded = 0;
+  for (const repoPath of fresh) {
+    const name = path.relative(targetDir, repoPath) || path.basename(repoPath);
+    console.log(`\n    ${ok("▸")} ${name}`);
+    const childOpts = {
+      ...opts,
+      nested: true,
+      // One build for the project at the end, not one per repo.
+      confirmBuild: "no",
+      // ...and one watch-daemon install for the run, done below once every repo is in.
+      skipDaemonSetup: true,
+      // The project name is the FOLDER's, not the first repo's — `apps` reads better than whichever
+      // repo happened to sort first.
+      projectName: projectRef ? undefined : (opts.projectName || defaultName),
+      addTo: projectRef || undefined,
+    };
+    try {
+      await withIndent(4, () => runInit(repoPath, childOpts));
+    } catch (err) {
+      console.error(fail(`        Could not onboard ${name}: ${err.message}`));
+      continue;
+    }
+    const entry = readEntry(repoPath);
+    if (entry && entry.projectId) {
+      onboarded += 1;
+      if (!projectRef) projectRef = entry.projectId;
+    }
+  }
+
+  if (!projectRef || !onboarded) {
+    console.error(fail(`\n    No repo could be onboarded; nothing was created.`));
+    process.exitCode = 1;
+    return;
+  }
+  const daemon = await watchDaemon.ensureWatchDaemon({ skipPrompts: !!opts.defaults });
+  if (!daemon.ok) {
+    console.log(`\n    ${warn("auto-sync is OFF")} — these folders will not stay in sync (see above).`);
+  }
+  console.log(`\n    ${ok(`${onboarded} repo(s) indexed into project "${projectRef}".`)}`);
+  console.log(`    ${color.cyan(`niro build`)} to index them, or ${color.cyan("niro status")} to review first.`);
+}
+
+/**
+ * Immediate subfolders that hold files but are neither a git repo nor on the way to one.
+ *
+ * A grouping folder like `services/` that CONTAINS repos is not "skipped code" — its repos are being
+ * onboarded. Only a folder with no repo anywhere beneath it is genuinely being left out.
+ */
+function nonRepoCodeFolders(targetDir, discoveredRepos) {
+  const out = [];
+  let entries;
+  try { entries = fs.readdirSync(targetDir, { withFileTypes: true }); } catch { return out; }
+  for (const e of entries) {
+    if (!e.isDirectory() || e.name.startsWith(".") || CHILD_SCAN_SKIP.has(e.name)) continue;
+    const dir = path.join(targetDir, e.name);
+    const leadsToARepo = discoveredRepos.some((r) => {
+      const rel = path.relative(dir, r);
+      return rel === "" || (!rel.startsWith("..") && !path.isAbsolute(rel));
+    });
+    if (!leadsToARepo) out.push(dir);
+  }
+  return out;
+}
+
 /**
  * Collect directories under `root` that are their OWN git repo (have a `.git` entry),
  * scanning immediate children AND one level of NON-git grouping dirs (so `services/foo`,
@@ -741,7 +911,9 @@ function collectNestedGitRepos(root) {
  */
 async function scanIndexedChildren(targetDir, opts, resolve = resolveContext) {
   const { repos: gitChildren, truncated } = collectNestedGitRepos(targetDir);
-  if (!gitChildren.length) return { indexed: [], unverified: [], truncated };
+  // `all` is every git repo found beneath targetDir, indexed or not. The refusal below only ever
+  // needed the indexed ones; onboarding them (onboardDiscoveredRepos) needs the whole list.
+  if (!gitChildren.length) return { indexed: [], unverified: [], truncated, all: [] };
 
   const indexed = [];
   const unverified = [];
@@ -767,7 +939,7 @@ async function scanIndexedChildren(targetDir, opts, resolve = resolveContext) {
       else unverified.push(r);
     }
   }
-  return { indexed, unverified, truncated };
+  return { indexed, unverified, truncated, all: gitChildren };
 }
 
 /**
@@ -1226,4 +1398,6 @@ function logicalCwd() {
   return process.cwd();
 }
 
-module.exports = { init, parseOnOff, parseYesNo, parseQuietPeriod, promptEnvVars, promptActivePropertyFiles, scanIndexedChildren };
+module.exports = {
+  onboardDiscoveredRepos,
+  nonRepoCodeFolders, init, parseOnOff, parseYesNo, parseQuietPeriod, promptEnvVars, promptActivePropertyFiles, scanIndexedChildren };

package/src/commands/mcp.js

@@ -2,19 +2,28 @@
  * `niro mcp install` / `niro mcp uninstall` / `niro mcp serve` — drive the in-package MCP server.
  *
  * install():   spawn the bundled editor-config wizard as a child so it can prompt.
+ *              Takes optional wizard arguments; see runWizard.
  * uninstall(): spawn the teardown wizard — the exact inverse of install.
  * serve():     run the in-package stdio bridge directly in this process so the
  *              editor's MCP stdio talks straight to it.
  */
 const path = require("path");
-const { spawn } = require("child_process");
+const childProcess = require("child_process");
 
-/** Spawn a bundled wizard (setup.js / teardown.js) as a child so it can prompt on the TTY. */
-function runWizard(scriptName, label) {
+/**
+ * Spawn a bundled wizard (setup.js / teardown.js) as a child so it can prompt on the TTY.
+ *
+ * `args` overrides what is forwarded to the wizard. Callers that are themselves a `niro mcp ...`
+ * command leave it out and the user's own flags after `niro mcp install` are passed through.
+ * `niro upgrade` passes its own `--client <id>`, because the flags on its command line
+ * (`--finish`, `--from`) are not the wizard's.
+ */
+function runWizard(scriptName, label, args) {
+  const wizardArgs = Array.isArray(args) ? args : process.argv.slice(4);
   return new Promise((resolve, reject) => {
-    const child = spawn(
+    const child = childProcess.spawn(
       process.execPath,
-      [path.join(__dirname, "..", "mcp", scriptName), ...process.argv.slice(4)],
+      [path.join(__dirname, "..", "mcp", scriptName), ...wizardArgs],
       { stdio: "inherit" }
     );
     child.on("error", reject);
@@ -25,8 +34,8 @@ function runWizard(scriptName, label) {
   });
 }
 
-async function install() {
-  return runWizard("setup.js", "setup");
+async function install(args) {
+  return runWizard("setup.js", "setup", args);
 }
 
 async function uninstall() {

package/src/commands/start.js

@@ -560,6 +560,7 @@ module.exports = {
   printNextSteps,
   BOOK_A_CALL,
   runningFromNpxCache,
+  globalNiroPath,
   isOlder,
   describeProblem,
   expandHome,