@niroai/niro 0.5.0 → 0.7.0

package/CHANGELOG.md

@@ -2,7 +2,165 @@
 
 Notable changes to `@niroai/niro`. Dates are release dates.
 
-## Unreleased
+## 0.7.0 — 2026-08-17
+
+A data-loss release. If you use `niro watch`, upgrade.
+
+### Upgrading
+
+```bash
+npm install -g @niroai/niro@latest
+```
+
+Nothing extra is needed from 0.6.0. **From 0.4.x or earlier, upgrade urgently** — every fix
+below is client-side, so a server update alone does not protect you.
+
+### Why this release exists
+
+On 31 July a repository lost 494 source files. The client reported them deleted, the server
+removed the working copy and the durable backup, and the client's own record then said
+"deleted", so nothing ever re-sent them. Eleven days passed before anyone noticed.
+
+The cause was a `git checkout`. Git removed a directory of test files and wrote it straight
+back a moment later. In that gap the watcher looked, saw nothing, and reported 249 files
+deleted. Everything below follows from that one sentence: **the watcher believed a file was
+gone because it could not see it at one instant.**
+
+### Fixed — the client no longer infers a deletion from a failure to look
+
+- **Deletes now wait for the folder to go quiet.** A file that disappears is queued, not
+  reported. One timer per folder resets on every new disappearance, so a three-file checkout
+  holds for a few seconds and a ninety-second rebase holds for ninety seconds. When the folder
+  settles, whatever is still missing is deleted and whatever came back is dropped.
+
+  This covers `git checkout`, `git stash`, rebases, `npm ci`, `make clean`, a Docker remount and
+  editors that save by deleting and rewriting — without needing to know which of them is
+  happening. A real deletion now reaches the server about five seconds later than before.
+  Set `NIRO_DELETE_SETTLE_MS` to change that.
+
+- **A file that cannot be READ is no longer treated as deleted.** A permission error, a
+  transient lock, a file being rewritten or simply too many open files all made the hash return
+  nothing, and the file was then reported gone. It now keeps its previous state.
+
+- **A DIRECTORY that cannot be read is no longer treated as "everything under it was deleted".**
+  The same mistake one level up, and worse: an unreadable folder lists as empty, which is
+  indistinguishable from one whose files were all removed. Renaming a watched folder and
+  restarting reported the entire project as deleted, in a pass that reported itself successful.
+  An unreadable root now aborts the pass; an unreadable subdirectory keeps its files while the
+  rest of the tree syncs.
+
+- **A delete the server refuses is retried instead of forgotten.** It was marked done regardless
+  of the outcome, and once out of the local record it could never be re-attempted — so a
+  transient error became permanent.
+
+- **`niro discard-temp-project` no longer loses the work done in the temporary project.** The
+  file record followed the folder back to the source repository, so the source appeared to
+  already hold edits it had never received, and the next sync uploaded nothing. Discarding now
+  clears that record and re-uploads once.
+
+- **Excluding a path removes it again.** A guard added in the same work stopped an excluded file
+  ever being removed from the index, which mattered most for a path excluded *because* it holds
+  secrets.
+
+- **No delete calls for files that were never uploaded.** Editor scratch files are rejected on
+  the way in, but a delete was still sent when the editor renamed them away — 21% of all file
+  events on one real repository, every one of them pointless traffic.
+
+### Fixed — the retry flood
+
+- **The 60-second re-scan now backs off.** It retried at full rate forever, so a two-day server
+  problem became roughly 1,400 failed requests a day per folder and buried the real error. The
+  delay now doubles to a 30-minute ceiling and resets on success. It never gives up entirely, so
+  a recovered server is picked up within half an hour on its own.
+
+- **A pass whose file operations failed is no longer counted as a recovery**, which previously
+  reset the backoff mid-incident and printed a green "Sync recovered" while the outage continued.
+
+### Changed — worktrees and temporary projects
+
+You get one temporary project per project, and creating another moves it rather than adding one.
+With several worktrees open that meant they silently took it from each other.
+
+- A second worktree is no longer told to create one. It is told which branch currently holds it
+  and to use its own tools for that folder.
+- `niro discard-temp-project` asks before moving the slot away from another folder.
+- A folder that has lost the slot stops uploading, instead of blending two branches into one copy.
+- A branch switch is now told apart from another folder taking the slot.
+- `niro info` shows which local folder and branch syncs each project, and marks the one you are
+  standing in.
+
+### Also fixed
+
+- **A sync finishing after the folder was re-pointed no longer writes its stale record.** A pass takes
+  minutes on a large tree; if `niro new-temp-project` or `niro discard-temp-project` re-pointed the
+  folder while it ran, its results were written anyway, against a repository they did not describe.
+  For discard that undid the clean slate above and the re-upload was skipped. The record now belongs
+  to one repository and a pass that no longer matches is dropped, the same way a folder release has
+  always been handled.
+
+- **A folder whose root cannot be read now says so once**, and says when it can be read again. It used
+  to repeat the same error every sixty seconds for as long as the folder stayed away.
+
+## 0.6.0 — 2026-08-11
+
+### Upgrading
+
+```bash
+npm install -g @niroai/niro@latest
+```
+
+If you are coming from 0.3.x you also still need `niro mcp install` once per assistant — see
+the 0.5.0 notes below. Upgrading from 0.5.0 needs nothing extra.
+
+### Changed — read this before upgrading
+
+- **`--api-url` now applies to `niro login` only.** Every other command refuses it and exits 1.
+
+  It was a global flag, but only half of the code honoured it. Ordinary API calls took it,
+  while the file-upload path built its own address from your stored credentials and never saw
+  it. So `niro init --api-url http://localhost:8095` while logged in to another backend listed
+  projects from localhost and uploaded your source to the backend you were logged in to. One
+  command, two servers, no warning.
+
+  The backend is a property of a session, not of a single command: your credentials, tokens,
+  repo ids and sync records are all scoped to one backend, so a per-command override could
+  only ever mix them. Choose it once instead:
+
+  ```bash
+  niro login --api-url <url>          # log in to that backend
+  NIRO_API_URL=<url> niro <command>   # or set it for every command
+  ```
+
+  `NIRO_API_URL` and the `apiUrl` config setting still work everywhere, because both feed the
+  same resolution the uploader uses. **If you script `--api-url` on any command other than
+  `login`, that script now fails with a message** telling it which of the two forms to use.
+
+- **`niro init` and `niro add repo` now refuse a folder that is not a project.** Onboarding a
+  folder used to work anywhere, including your home folder, which uploaded source from every
+  project on the machine, pinned `~/.niro-project` and started a watcher over your whole home
+  directory. Two rules now apply before anything is uploaded:
+
+  - Your home folder, the filesystem root, a parent of your home folder and the system folders
+    are refused outright. `--force` does **not** override this.
+  - Any other folder must look like a project: a build file (`package.json`, `pom.xml`, `go.mod`,
+    `*.csproj`, and the rest of the set the indexer already understands) at the folder itself or
+    just below it. A monorepo root whose build files sit one or two levels down is fine.
+
+  **If you script either command**, a folder with no build file now exits `1` where it used to
+  onboard. Pass `--force` for that case. `niro add repo` gains `--force` for this; on `niro init`
+  the existing `--force` now covers it too.
+
+  A folder this backend already has a repo for is exempt from the build-file rule, so an existing
+  sync keeps working. The home and root refusal still applies to it.
+
+  The check runs before the login and before any server call, so a refused folder leaves nothing
+  behind: no registered repo, no orphan project, no pin file, no watcher.
+
+- **`niro init` now notices nested repos deeper in the tree.** The "this folder contains repos
+  already indexed in Niro" refusal only looked two levels down, so it never fired for the common
+  `~/projects/<host>/<org>/<repo>` layout. It now looks four.
+
+## 0.5.0 — 2026-08-06
 
 ### Upgrading from 0.3.x — one manual step
 

package/README.md

@@ -98,7 +98,9 @@ During `init` you'll be asked, **per environment variable**, which value to use
 **Ask the agent**
 > "Onboard this folder into Niro." The `niro-cli` skill checks auth, runs `niro info` to see if it's already indexed, then runs `niro init` for you and walks you through the env-var values in chat.
 
-**Note for cloud:** Niro indexes your folder by **uploading its files** (it can't read your laptop's disk). Source and committed config files (`package.json`, `pom.xml`, `application.yml`, …) are uploaded; anything in your `.gitignore` (like a real `.env`) is **never** uploaded.
+**Note for cloud:** Niro indexes your folder by **uploading its files** (it can't read your laptop's disk). Source and committed config files (`package.json`, `pom.xml`, `application.yml`, …) are uploaded; anything your repo `.gitignore`s (like a real `.env`) is **never** uploaded. One caveat: that filtering needs the folder to be a git repository. If you onboard a plain folder that is not a git repository, there is no `.gitignore` to honour and only the filename rules apply, so keep secrets out of it.
+
+**What can be onboarded:** the folder has to look like a project — a build file (`package.json`, `pom.xml`, `go.mod`, `*.csproj`, …) at the folder itself or just below it. A monorepo root whose build files sit one or two levels down is fine. A folder with no build file is refused; pass `--force` if you really mean it. Your home folder, the filesystem root and system folders are refused outright, and `--force` does not override that — onboarding one of those would upload source from every project on the machine.
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@niroai/niro",
-  "version": "0.5.0",
+  "version": "0.7.0",
   "description": "Niro — one package: the niro CLI plus the Niro MCP server (code intelligence for AI coding assistants).",
   "keywords": [
     "niro",

package/src/commands/add-repo.js

@@ -25,30 +25,57 @@ const { startWatch } = require("./watch");
 const color = require("../lib/color");
 const watchDaemon = require("../lib/watchDaemon");
 const { login } = require("./login");
+const onboardTarget = require("../lib/onboardTarget");
 
 async function addRepo(pathArg, opts = {}) {
+  const targetRaw = pathArg || ".";
+  const isRemote = targetRaw.startsWith("http://") || targetRaw.startsWith("https://") || targetRaw.startsWith("git@");
+
+  // Backend URL as it looks BEFORE the login. Used for ONE thing only: the gate's
+  // already-registered lookup, which has to run before the login. It is NOT reused
+  // afterwards — a login can change which backend this session talks to, and tagging a
+  // watchState entry with a stale value stamps it with a backend that did not issue its
+  // gitId, which silently stops the daemon syncing that folder. See the same note in
+  // init.js. The authoritative value is re-read after ensureLoggedIn below.
+  const apiUrlBeforeLogin = api.currentBaseUrl();
+
+  // LOCAL FOLDER: validate and gate BEFORE the login, for two reasons. Refusing a folder
+  // should not first cost the user a browser device-flow. And an abandoned login used to
+  // swallow the refusal entirely: ensureLoggedIn returned null, the bare `return` printed
+  // nothing and left process.exitCode undefined, so `niro add repo ~ && echo ok` printed
+  // ok. A remote URL has no folder to gate, so it stays behind the login.
+  let targetDir = null;
+  if (!isRemote) {
+    targetDir = path.isAbsolute(targetRaw) ? path.resolve(targetRaw) : path.resolve(process.cwd(), targetRaw);
+    if (!fs.existsSync(targetDir) || !fs.statSync(targetDir).isDirectory()) {
+      console.error(color.red(`Not a directory: ${targetDir}`));
+      process.exitCode = 1;
+      return;
+    }
+    // Same onboarding gate as `niro init` — this command uploads a folder too, so it must
+    // refuse $HOME / the filesystem root on the same terms. A folder this backend already
+    // has a repo for is exempt from the BUILD-DESCRIPTOR half: that half gates new
+    // onboarding, and must not break the re-sync branch below for a descriptor-less folder
+    // onboarded by an earlier CLI. See src/lib/onboardTarget.js.
+    const known = watchState.get(targetDir, apiUrlBeforeLogin);
+    const alreadyRegistered = !!(known && known.gitId);
+    if (!onboardTarget.ensureOnboardable(targetDir, { ...opts, alreadyRegistered })) {
+      process.exitCode = 1;
+      return;
+    }
+  }
+
   const creds = await ensureLoggedIn(opts);
   if (!creds) return;
 
-  // Backend the CLI is pointed at — scopes watchState so a cached gitId from
-  // another stack is never reused here.
+  // Authoritative backend, re-read AFTER the login (see the note above).
   const currentApiUrl = api.currentBaseUrl();
 
-  const targetRaw = pathArg || ".";
-
-  // Remote URL?
-  if (targetRaw.startsWith("http://") || targetRaw.startsWith("https://") || targetRaw.startsWith("git@")) {
+  if (isRemote) {
     await addRemoteRepo(targetRaw, opts);
     return;
   }
 
-  const targetDir = path.isAbsolute(targetRaw) ? path.resolve(targetRaw) : path.resolve(process.cwd(), targetRaw);
-  if (!fs.existsSync(targetDir) || !fs.statSync(targetDir).isDirectory()) {
-    console.error(color.red(`Not a directory: ${targetDir}`));
-    process.exitCode = 1;
-    return;
-  }
-
   // --sync-mode local|remote skips the interactive [1]/[2] sync-type choice.
   // --no-confirm skips any confirmation prompt.
   const syncMode = parseSyncMode(opts.syncMode);

package/src/commands/info.js

@@ -13,7 +13,10 @@
  * NEVER prints secrets: it only emits project ids, aliases and status fields —
  * no env-var values, tokens or credentials are touched here.
  */
+const path = require("path");
 const api = require("../lib/api");
+const watchState = require("../lib/watchState");
+const tempProject = require("../lib/tempProject");
 const credentials = require("../lib/credentials");
 const color = require("../lib/color");
 const { resolveContext } = require("../lib/resolveContext");
@@ -91,8 +94,58 @@ async function info(pathArg, opts = {}) {
       // A status fetch failure for one project must not abort the whole command.
       status = null;
     }
+    // Which local folders sync to THIS project, and on what branch. Purely local: ~/.niro/projects.json
+    // already records branch and projectId per folder.
+    //
+    // A developer gets ONE temporary project per project, and creating another RELABELS it onto the new
+    // branch. So with several worktrees open, exactly one of them is reflected by Niro and the others
+    // are not, with nothing on screen to say which. This is that missing line: it lets someone see that
+    // the temporary project is bound to worktree A on feature/x while they are standing in worktree B.
+    //
+    // Matching on projectId ALONE could never show the one folder this line exists for. Taking over a
+    // folder rewrites its entry's projectId to the TEMPORARY project's id, and /api/projects/resolve
+    // deliberately never returns temporary projects (they share the source project's git URL, so
+    // including them would make every teammate's resolution ambiguous). So for a taken-over worktree
+    // the two ids can never be equal, and the folder Niro actually reflects was the only one missing
+    // from the list, while the folder it does NOT reflect was the only one shown.
+    //
+    // takeover.sourceProjectId is the link back to the source project. It is written when the temporary
+    // project is created and cleared on discard, so it is present exactly while there is something to
+    // report. `niro release` already pairs the two this way.
+    //
+    // apiUrl comes from api.currentBaseUrl(), not opts: `--api-url` is refused outside `niro login`, so
+    // opts.apiUrl is always undefined here, and an undefined backend makes allLocal match entries
+    // belonging to ANY backend.
+    const localEntries = watchState.allLocal(api.currentBaseUrl())
+      .filter(e => e.projectId === p.project_id
+        || (e.takeover && e.takeover.sourceProjectId === p.project_id));
+    const folders = localEntries.map(e => ({
+      path: e.folderPath,
+      branch: e.branch || null,
+      // The temporary project's own id when this folder is bound to one, else null.
+      temp_project_id: e.takeover && e.takeover.sourceProjectId === p.project_id ? e.projectId : null,
+      // Whether the temporary project is currently reflecting THIS folder. null when it has none, or
+      // when the server could not be asked.
+      reflected: null,
+    }));
+
+    // A temporary project can only be bound to one branch at a time, so listing several folders as
+    // "via temporary project X" implies they are all covered when at most one is. That is not
+    // hypothetical: two worktrees of one project end up sharing a repo id, and I have watched this
+    // command mark "you are here" against a folder the server had stopped reflecting. The branch the
+    // copy is on is the answer, and only the server knows it, so ask once per temporary project.
+    const tempIds = [...new Set(folders.map(f => f.temp_project_id).filter(Boolean))];
+    for (const tempId of tempIds) {
+      const owner = localEntries.find(e => e.projectId === tempId);
+      const heldBranch = await tempProject.currentBranch(tempId, owner && owner.gitId);
+      if (!heldBranch) continue; // could not ask — say nothing rather than guess
+      for (const f of folders) {
+        if (f.temp_project_id === tempId) f.reflected = f.branch === heldBranch;
+      }
+    }
     projects.push({
       project_id: p.project_id,
+      folders,
       alias: p.alias || null,
       // Matched repo's registration kind (REMOTE_GIT / LOCAL_PATH / AGENT_UPLOAD),
       // or null. Lets agents warn on remote-git projects (auto-build only on commits).
@@ -166,6 +219,23 @@ function printHuman(p) {
     if (proj.doc_gen_status) bits.push(`docs: ${proj.doc_gen_status}`);
     if (proj.updated_at) bits.push(`updated: ${proj.updated_at}`);
     console.log(`  - ${name}${bits.length ? "  — " + color.dim(bits.join(", ")) : ""}`);
+    for (const f of proj.folders || []) {
+      // Marked so the folder you are STANDING IN is obvious at a glance; the whole point is telling
+      // "this worktree is the one Niro reflects" from "this one is not".
+      const here = path.resolve(f.path) === path.resolve(p.git_root) ? color.green("  <- you are here") : "";
+      // Say plainly which folder holds the temporary project. Without this the line reads as though
+      // Niro were answering from the source project for that folder, which is the opposite of the truth.
+      let temp = "";
+      if (f.temp_project_id && f.reflected === false) {
+        // The line that used to mislead. Say plainly that this folder is not the one being reflected.
+        temp = color.yellow(` — NOT reflected: temporary project ${f.temp_project_id} is on another branch`);
+      } else if (f.temp_project_id) {
+        temp = color.dim(` via temporary project ${f.temp_project_id}`)
+          + (f.reflected === null ? color.dim(" (could not confirm)") : "");
+      }
+      console.log(color.dim(`      syncing from ${f.path}`) +
+        (f.branch ? color.dim(` on branch ${f.branch}`) : "") + temp + here);
+    }
   }
 }
 

package/src/commands/init.js

@@ -36,6 +36,7 @@ const credentials = require("../lib/credentials");
 const prompt = require("../lib/prompt");
 const git = require("../lib/git");
 const niroProjectFile = require("../lib/niroProjectFile");
+const onboardTarget = require("../lib/onboardTarget");
 const color = require("../lib/color");
 const watchDaemon = require("../lib/watchDaemon");
 const { login } = require("./login");
@@ -62,6 +63,36 @@ async function init(pathArg, opts = {}) {
     process.exitCode = 1;
     return;
   }
+  // Backend URL as it looks BEFORE the login. Used for ONE thing only: the gate's
+  // already-registered lookup, which has to happen before the login prompt.
+  //
+  // It is deliberately NOT reused after the login. currentBaseUrl() reads the backend out
+  // of the stored credentials, so a login can CHANGE it: `niro init --api-url <local>` on a
+  // machine with no session resolves the production URL here and the local one afterwards.
+  // Tagging a watchState entry with this stale value would stamp an entry with a backend
+  // that did not issue its gitId, after which watchState.get(dir, realBackend) returns null,
+  // the daemon never syncs the folder, and the next run re-registers a duplicate repo and
+  // re-uploads everything. The authoritative value is re-read below, after the login.
+  //
+  // Being wrong here only affects the alreadyRegistered waiver, which can at worst refuse a
+  // folder that --force reopens. It can never waive the protected-root refusal.
+  const apiUrlBeforeLogin = api.currentBaseUrl();
+
+  // Onboarding gate — runs BEFORE the login prompt and before any server call, so a
+  // refused folder leaves nothing behind: no registered repo, no orphan project, no
+  // .niro-project pin, no watcher. Refuses $HOME / the filesystem root outright, and
+  // refuses a folder with no build descriptor at it or just below it. --force covers only
+  // that second rule, and so does alreadyRegistered: a folder this backend already has a
+  // 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);
+  if (!onboardTarget.ensureOnboardable(targetDir, {
+    ...opts,
+    alreadyRegistered: !!(knownEntry && knownEntry.gitId),
+  })) {
+    process.exitCode = 1;
+    return;
+  }
 
   let creds = credentials.load();
   if (!creds || !creds.token) {
@@ -71,8 +102,9 @@ async function init(pathArg, opts = {}) {
     if (!creds || !creds.token) return;
   }
 
-  // The backend the CLI is pointed at. watchState entries (cached gitIds) are
-  // scoped to this so a backend switch never reuses a gitId from another stack.
+  // Authoritative backend, re-read AFTER the login: the login is what establishes which
+  // stack this session talks to. Every watchState read and write below uses THIS value, so
+  // an entry is always tagged with the backend that actually issued its gitId.
   const currentApiUrl = api.currentBaseUrl();
 
   const gitInfo = git.inspect(targetDir);
@@ -640,7 +672,13 @@ const CHILD_SCAN_SKIP = new Set([
   "node_modules", "target", "dist", "build", "out", ".next", "vendor", "__pycache__",
 ]);
 const CHILD_SCAN_MAX = 60;       // bound the number of nested repos we resolve
-const CHILD_SCAN_MAX_DEPTH = 2;  // immediate children + one level of grouping dirs (services/, packages/, apps/)
+// Immediate children plus three levels of grouping dirs. Real checkout layouts nest
+// deeper than one grouping level (~/projects/github/<org>/<repo> is depth 3), and at
+// depth 2 this scan silently found NOTHING there — so the "parent of indexed repos"
+// refusal never fired for the most common layout. The walk never descends INTO a git
+// repo, so the extra depth only costs readdir on grouping dirs: measured 9 dirs for a
+// single repo and 50 for this monorepo, versus 5 and 13 at depth 2.
+const CHILD_SCAN_MAX_DEPTH = 4;
 
 /**
  * Collect directories under `root` that are their OWN git repo (have a `.git` entry),

package/src/commands/release.js

@@ -151,6 +151,22 @@ async function release(pathArg, opts = {}) {
         ...e,
         gitId: backup.previousGitId || null,
         projectId: sourceProjectId,
+        // The baseline describes what the TEMPORARY project holds, so it MUST NOT survive the move
+        // back to the source repo. Carrying it across told the daemon the source already had every
+        // file at its sandbox-era fingerprint — which it did not, because those edits only ever went
+        // to the temporary copy. The next pass then compared disk against that baseline, found no
+        // difference, and uploaded nothing. Every edit made during the temporary project was silently
+        // lost to the source project, with no error and nothing to prompt a re-sync.
+        //
+        // Clearing it makes the next pass treat every file as new and upload it. That is a full
+        // re-upload once, which is the cost of being sure: the client cannot know which files the
+        // source repo is missing, so the only safe assumption is all of them.
+        //
+        // The opposite direction already gets this right — takeover.js seeds fileHashes with what it
+        // actually uploaded to the new gitId. A baseline belongs to ONE gitId; when that changes, so
+        // must it.
+        fileHashes: {},
+        lastSyncedAt: null,
         takeover: undefined,
       }, e.apiUrl || baseUrl);
       repinned.push(e.folderPath);

package/src/commands/takeover.js

@@ -13,6 +13,7 @@
  *
  * Undo with `niro discard-temp-project` (deletes P'; routing falls back to P automatically).
  */
+const path = require("path");
 const api = require("../lib/api");
 const color = require("../lib/color");
 const folderSync = require("../lib/folderSync");
@@ -27,12 +28,14 @@ const warn = (s) => color.yellow(s);
 const step = (s) => color.cyan(s);
 
 async function takeover(pathArg, opts = {}) {
-  // --api-url is threaded only into project resolution, not the clone/build POSTs or the agentApi upload
-  // chain — so a global `--api-url X` would resolve against X but clone/upload/watch-tag against the DEFAULT
-  // backend, mixing two stacks in one flow. Fail fast BEFORE any server mutation rather than corrupt state
-  // across backends. (Full per-backend threading is future work; set the default backend via login/config.)
+  // Second layer. src/index.js refuses `--api-url` for every command except `niro login`
+  // before the action ever runs, so a CLI user never reaches this. It stays for a
+  // PROGRAMMATIC caller (a test, a skill, a future internal call) that constructs opts
+  // directly and bypasses commander entirely: a per-command backend override mixes two
+  // stacks in one flow, and this is the one command that clones, uploads and tags watchState
+  // in a single pass.
   if (opts.apiUrl) {
-    throw new Error("`--api-url` is not supported for `niro new-temp-project` yet (it would mix backends). "
+    throw new Error("`--api-url` is not supported for `niro new-temp-project` (it would mix backends). "
         + "Select the backend with `niro login` / your config first, then run this without --api-url.");
   }
   const targetDir = require("path").resolve(pathArg || process.cwd());
@@ -71,6 +74,40 @@ async function takeover(pathArg, opts = {}) {
     throw new Error("Server did not report which repo of the project matches this folder (git_id missing).");
   }
 
+  // ONE temporary project per project. If a DIFFERENT folder already holds it, moving it here stops
+  // Niro reflecting that folder — and until now that happened silently: the other folder kept uploading
+  // its own branch into the copy, so two branches blended into one and every answer drawn from it was a
+  // mixture. Verified live with two worktrees.
+  //
+  // The SAME folder is deliberately not asked. Switching branch in place loses nothing: the copy was
+  // already reflecting this folder, and the branch it names has moved on. The server relabels it, which
+  // is right, and a prompt there would be pure friction.
+  const here = path.resolve(repoRoot);
+  const holder = watchState.allLocal(api.currentBaseUrl()).find((e) =>
+    e.takeover && e.takeover.sourceProjectId === source.project_id
+    && path.resolve(e.folderPath) !== here);
+  if (holder) {
+    const onBranch = holder.branch ? ` on branch \`${holder.branch}\`` : "";
+    console.log(warn("\n  Niro keeps ONE temporary project per project, and this project's is already"));
+    console.log(warn("  held by another folder:"));
+    console.log(`    ${holder.folderPath}${onBranch}`);
+    console.log(color.dim("  Moving it here stops Niro reflecting that folder: it falls back to the original"));
+    console.log(color.dim("  project until `niro new-temp-project` is run there again."));
+    if (prompt.isNonInteractive()) {
+      // Refuse rather than hang, and rather than proceed. Proceeding is what caused the problem; hanging
+      // would break any agent or script that runs this unattended. The way forward is two explicit
+      // commands, which is clearer than a flag that quietly takes the slot from another folder.
+      throw new Error(
+        "Refusing to move the temporary project without confirmation (nothing to prompt on). "
+        + "Niro keeps ONE temporary project per project, and this one is held by "
+        + holder.folderPath + (holder.branch ? ` on branch ${holder.branch}` : "")
+        + ". Run `niro discard-temp-project` in that folder first, then re-run this here.");
+    }
+    if (!(await prompt.confirm("  Move the temporary project to this folder?", false))) {
+      throw new Error("Cancelled — the temporary project stays where it is.");
+    }
+  }
+
   console.log(`\n  Creating a temporary private project of ${color.bold(source.alias || source.project_id)}...`);
   console.log(color.dim("  Your original project is not changed."));