Generate Commit Message reads the wrong repository in multi-root workspaces ("No staged changes" with files staged)

[petrk643-arch]

Before opening, please confirm:

• I have searched for duplicate or closed issues

Operating System

Windows 11

Kiro Version

1.1.14

Bug Description

Investigated and written by Kiro, reading its own shipped bundles
(kiro.kiro-agent/dist/extension.js, extensions/git/dist/main.js) and its own
extension-host logs. Findings come from static reading of that minified code plus
the vscode.git log, so identifier names are de-minified by hand and the
scm/inputBox argument claim is inferred from behaviour rather than observed
directly — see the note in "The identity match never succeeds" below. Everything
else was verified by running it.

Environment

Kiro	1.1.14 (commit f694ef1b025756b1ae27ae7c3d9ed4215b0160fe, 2026-09-10)
kiro-agent	1.1.28
VS Code base	1.131.0
OS	Windows 11
Workspace	multi-root, 11 folders, 14 git repositories open

Summary

kiroAgent.generateCommitMessage reports

No staged changes for commit message

for a repository that has staged files. It is reading a different repository
than the one whose commit box was clicked, and it does so silently.

The cause is findRepositoryUri in kiro.kiro-agent/dist/extension.js:

repos = await command("git.api.getRepositories")   // string[] of rootUri
if (arg?.rootUri) {
  const hit = repos.find(s => s === arg.rootUri.toString())
  if (hit) return hit
}
return repos[0]                                     // <- silent fallback

Two independent problems combine:

1. The identity match never succeeds. The command is contributed to
scm/inputBox. The argument delivered there apparently does not carry a rootUri
that stringifies to any value returned by git.api.getRepositories, so find
misses and the fallback decides.

This part is inferred, not observed: the repository whose commit box was clicked
was open, listed, and the only one visible in the Source Control view, yet a
different one was used — which only happens if the find missed. Whether the
argument is undefined, a marshalled plain object whose toString() yields
[object Object], or a Uri that stringifies differently, we could not tell from
outside. You can, and it should be checked before fixing only the fallback.

Either way the fallback hides it completely: no log line, no message, no
indication that the intended repository was not found.

2. repos[0] is not a meaningful default. git.api.getRepositories returns
Model.repositories, backed by Model.openRepositories. The git extension's own
lookup sorts that array in place:

// extensions/git/src/model.ts - Model.getOpenRepository
for (const liveRepository of this.openRepositories.sort(
    (a, b) => b.repository.root.length - a.repository.root.length)) { ... }

getOpenRepository runs on every visible-editor change and every quick-diff
lookup, so within seconds of startup openRepositories is permanently ordered
longest-root-path-first. repos[0] is therefore whichever repository is nested
deepest in the workspace — close to the least likely one the user means.

Effective order in the affected workspace, longest root path first:

[ 0]  <workspace>/app-control-panel/app-control-panel   <- chosen, index empty
[ 1]  ~/.kiro/powers/repos/<power>.partial-<id>-1       <- Kiro Powers temp clones
 ...                                                       (six of these)
[ 6]  ~/.kiro/powers/repos/<power>.partial-<id>-3
[ 7]  <workspace>/main-repo/docs-submodule
[ 8]  <workspace>/service-b
[ 9]  <workspace>/main-repo/nested-docs
[10]  <workspace>/wiki-a
[11]  <workspace>/wiki-b
[12]  <workspace>/tooling-c
[13]  <workspace>/main-repo                             <- staged files, sorts LAST

The workspace-folder repository being committed to sorted last of fourteen,
because it is the shallowest path present - which is typical for a workspace-folder
root. The repository actually chosen had an empty index, so the staged-changes
check short-circuited.

The in-place sort is upstream VS Code behaviour and arguably fine there. It is only
harmful because a consumer treats repositories[0] as if it carried meaning.

Steps to reproduce

1. Open a multi-root workspace with at least two git repositories, where one
   repository is nested more deeply than the workspace-folder repository - e.g.
   folder A/ is a repo, and B/nested/deep/ is also a repo.
2. Open a file from A/ so the SCM view targets it.
3. Stage a change in A/. Leave B/nested/deep/ with a clean index.
4. Click the wand in A's commit message box.

Expected: a commit message generated from A's staged diff.
Actual: "No staged changes for commit message".

Reproduces reliably. Which repository wins depends only on path lengths, so the
symptom appears and disappears as repositories are added or removed - including
temporary clones that Kiro Powers leaves under ~/.kiro/powers/repos/, some of
which no longer exist on disk yet remain registered.

Confirming it from logs

git.api.getDiff is called only after the staged-changes check passes, and maps
to git diff --cached:

Select-String -SimpleMatch -Pattern "diff --cached" `
  -Path "$env:APPDATA\Kiro\logs\<session>\window1\exthost\vscode.git\Git.log"

Zero occurrences across 43,645 lines and 25 hours of use before the change below;
present immediately after.

Not the cause

Worth stating, because each of these misdirects diagnosis:

• Relocated git directories are irrelevant. These repositories use
  --separate-git-dir to keep git internals off a synced drive.
  git rev-parse --git-dir and core.worktree resolve correctly, the git
  extension opens them without error, and it ran git status in the same second
  the index was written.
• The git extension's state is correct. The Source Control view listed the
  staged files throughout. Only the commit message generator disagreed.
• Not git.statusLimit. git status -uall yields ~240 entries here, far under
  the 10,000 default.

Suggested fix

Give the fallback the same heuristic Kiro already uses elsewhere in the same bundle
for remote-URL lookup, preferring in order:

1. the repository whose root is the longest prefix of the active editor's path;
2. the first workspace folder that is itself a repository root;
3. repos[0], if nothing else matches.

Separately, and more valuable than the fallback itself: log when the rootUri
match fails, or name the chosen repository in the progress notification. We got
an error only because the wrongly-chosen repository happened to have an empty
index. Had it held staged changes, the command would have produced a confident,
well-formed commit message describing a completely different repository, with
nothing to indicate it. That is the real severity here.

Fixing the scm/inputBox argument so the identity match works would make the
fallback almost unreachable. Both are worth doing.

Local patch

Applied to kiro.kiro-agent/dist/extension.js, inserted before the existing
return repos[0] (kept as the last resort), wrapped in try/catch so an
unexpected API shape degrades to current behaviour:

/*kiro-scm-repo-fix*/try{
  let u = vscode.window.activeTextEditor?.document?.uri;
  if (u && u.scheme === "file") {
    let s = u.toString(),
        c = repos.filter(x => s === x || s.startsWith(x.endsWith("/") ? x : x + "/"));
    if (c.length) return c.sort((a, b) => b.length - a.length)[0];
  }
  let w = vscode.workspace.workspaceFolders;
  if (w) for (let f of w) {
    let m = repos.find(x => x === f.uri.toString());
    if (m) return m;
  }
}catch{}
return repos[0]

Verified against the full 14-repository set: an editor in the workspace-folder
repository selects that repository; an editor inside a nested submodule selects the
submodule; no active editor still selects the workspace-folder repository rather
than the deepest one. node --check passes on the patched bundle.

Every update ships a pristine bundle and removes this, so it has to be re-applied
by a SessionStart hook - which is why the fix belongs upstream.

Workaround for anyone hitting this

Open a file belonging to the repository you want before clicking the wand. That
does not help on current builds, since the active editor is not consulted - so in
practice: write the message by hand, or ask the agent to read git diff --cached
and write one. Closing unwanted repositories in the Source Control view does
not help: the deepest remaining repository still wins, and a workspace-folder
root is usually the shallowest path present.

Steps to Reproduce

1. Open a multi-root workspace with at least two git repositories, where one
   repository is nested more deeply than the workspace-folder repository - e.g.
   folder A/ is a repo, and B/nested/deep/ is also a repo.
2. Open a file from A/ so the SCM view targets it.
3. Stage a change in A/. Leave B/nested/deep/ with a clean index.
4. Click the wand in A's commit message box.

Expected: a commit message generated from A's staged diff.
Actual: "No staged changes for commit message".

Reproduces reliably. Which repository wins depends only on path lengths, so the
symptom appears and disappears as repositories are added or removed - including
temporary clones that Kiro Powers leaves under ~/.kiro/powers/repos/, some of
which no longer exist on disk yet remain registered.

Expected Behavior

Expected: a commit message generated from A's staged diff.
Actual: "No staged changes for commit message".

Conversation ID

No response

Additional Context

No response

[github-actions]

Thanks for opening this issue and for the incredibly thorough investigation — the detailed analysis of how findRepositoryUri falls back to the wrong repository in multi-root workspaces is really impressive! We can see how frustrating it must be to have the commit message generator silently read from the wrong repo when you have multiple repositories open. A maintainer will review this shortly, and your deep dive into the root cause should be very helpful in getting this addressed. We really appreciate the effort you put into this report! 🙌

[AnilMaktala]

Thanks for raising this and for the detailed self-investigation.

Looking at the source, the repository identity match in the commit message command does rely on rootUri.fsPath equality against the VS Code Git extension's repository list, and that comparison could fail on Windows paths in multi-root workspaces, causing it to fall through to the first repository instead of the intended one. That would reproduce exactly what you're seeing.

Marking this as a bug to investigate further.

[dannyriosswo]

Additional data point that I think narrows this down, because it contradicts parts of the current working hypothesis.

I hit the same failure, but on macOS and without a multi-root workspace, so the scope is broader than the title and the os: windows label suggest.

Setup: a single workspace folder that is itself a Git repository, containing 7 further independent Git repositories in immediate subfolders (8 total, one workspace folder). Not submodules, not worktrees. Staged changes existed only in the top-level repository: 62 deletions and 2 modifications, and they were visible in the Source Control panel as 64 staged entries. Clicking the wand produced No staged changes for commit message.

Why the "falls through to the first repository" mechanism does not explain it here. I dumped the repository list order from the Git extension log. repositories[0] was the repository holding the staged changes. So even when the strict string comparison in findRepositoryUri fails and the fallback is taken, it lands on the correct repository in this configuration. The fallback cannot be what breaks it here, which suggests the Windows path-comparison theory is one trigger among several rather than the cause.

Where execution actually stops. git.api.getDiff maps to repository.diff(true), which spawns git diff --cached, and the Git extension logs every subprocess it spawns. Across a 3,744-line Git extension log covering the whole session and several attempts, there are zero occurrences of git diff --cached — every git diff entry is the extension's own --raw --numstat --diff-filter=ADMR upstream comparison. Logging was otherwise healthy in that window, down to git check-ignore.

That places the return before getDiff is ever reached, at the early check in getStagedChanges:

if (!state || !state.indexChanges.length) return "No staged changes";

indexChanges is derived from the repository's index resource group, which is exactly what the panel renders as "Staged Changes", and the panel showed 64. So for whatever URI is being passed, git.api.getRepositoryState returned either null or an empty index group. The fix likely belongs there rather than only in the string comparison.

Isolation, single variable. Same repository, same branch, same 64 staged entries, same build. Only the number of repositories the Git extension opens was changed:

"git.repositoryScanMaxDepth": 0,
"git.autoRepositoryDetection": false

After a reload the log shows one repository opened instead of eight, and the same click yields > git diff --cached [41ms] — first and only occurrence in the log — and the message generates correctly. Both settings are needed: with only the scan depth at 0, repositories are still opened on demand when a file belonging to them is open in the editor.

A second defect, which I suspect is why this keeps getting refiled. getStagedChanges returns the literal "No staged changes" from both the legitimate empty-index branch and a bare catch that swallows every exception, and nothing is written to any log. So "there is genuinely nothing staged", "the repository could not be resolved", and "a call threw" are indistinguishable to the user and to anyone triaging. Separating those return values and logging the caught exception would likely collapse several of the open and duplicate reports into one diagnosable signal, and would have saved me reverse-engineering the bundle to find out where it exits.

Environment: Kiro 1.1.70 (behaviour first observed in a running 1.0.437 session; the relevant code paths are unchanged between the two), macOS 26.5.1 arm64, Git 2.50.1. Defaults for git.repositoryScanMaxDepth (1), git.autoRepositoryDetection (true), git.detectSubmodules (true).