Stuck forever on "Considering next steps"

[lambertjosh]

Description

Right now when I try version 7.2.1 pre-release or off main on Windows, any bash command that triggers that calls git hangs indefinitely, and shows "Considering next steps". No bash tool output is shown.

If I downgrade to 7.1.21 or below this works fine.

To reproduce

1. Run 7.2.1 or above
2. Ask the model to run git status
3. It hangs on "Considering next steps" with no tool calls shown.

Plugins

No response

Kilo version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

[lambertjosh]

I now seem to be out of this state but not sure how I got into it. I rebooted with the same problem.

[lambertjosh]

Closing for now, will re-open if I repro.

[kilo-code-bot]

Note: This investigation was requested by @markijbema.

Looking at PRs merged between v7.1.22 (released 2026-04-06T16:10) and v7.1.23 (released 2026-04-07T16:19), the two most suspicious candidates for causing git commands to hang indefinitely on Windows are:

---

🚨 #8464 — fix(cli): update simple-git to fix critical RCE

This updates simple-git from 3.31.1 → 3.35.2 (a jump of 4 minor versions) in both packages/opencode/ and packages/kilo-vscode/. Simple-git is the library used to spawn and manage git processes. A major version bump here could change how git processes are spawned, how stdio is piped, or how timeouts/retries are handled — all of which could manifest as indefinite hangs on Windows.

---

🔍 #8190 — fix(agent-manager): suppress interactive prompts during background git fetch

This PR modifies GitOps.ts, GitStatsPoller.ts, and WorktreeManager.ts — all related to how background git operations are managed. It removes background git fetch and adjusts how nonInteractiveEnv is applied. Any change to environment variables passed to git processes (e.g. missing GIT_TERMINAL_PROMPT=0 or GIT_ASKPASS) could cause git to block waiting for user input on Windows.

---

Both PRs touch git process management and were merged in the window between .22 (working) and .23 (broken). #8464 is the stronger candidate given the significant version bump to the core git library.

[kilo-code-bot]

Note: This is a follow-up investigation update requested by @markijbema.

Re-examining the full range after v7.1.21. Correcting the earlier analysis which only looked at the .22→.23 window.

---

v7.1.21 → v7.1.22 (Apr 5 15:48 → Apr 6 16:10) — most suspicious window

🚨 #8400 — fix(cli): prevent excessive git process spawning by caching diffFull

This modifies packages/opencode/src/snapshot/index.ts and packages/opencode/src/file/ignore.ts.

The caching mechanism stores a Promise in a Map keyed by from:to git hashes. If the underlying diffFull call spawns a git process that hangs indefinitely on Windows (a known issue with git on Windows when stdio is not properly handled), the hanging Promise gets cached. All subsequent callers then await that same never-resolving Promise — the whole operation stalls forever with no way to recover. This maps directly to the symptom: "stuck forever on 'Considering next steps'" with no tool output shown.

This is the strongest candidate for the regression.

---

v7.1.22 → v7.1.23 (Apr 6 16:10 → Apr 7 16:19) — previously flagged

🔍 #8464 — fix(cli): update simple-git to fix critical RCE

Updates simple-git from 3.31.1 → 3.35.2 (4 minor versions). Could change Windows git process spawning/stdio behavior.

🔍 #8190 — fix(agent-manager): suppress interactive prompts during background git fetch

Changes to git process environment variable handling in agent-manager git ops.

---

v7.1.20 → v7.1.21 (Apr 2 17:33 → Apr 5 15:48)

No PRs in this window appear to touch git process management. #8367 (session migration improvements) and #8230 (Claude Code compatibility toggle) are the main changes — neither appears related to git process execution.

---

Summary: #8400 in the .21→.22 window is the most likely culprit due to the Promise-caching pattern that can permanently deadlock if any git process hangs on Windows. The reporter may have been wrong about .22 being the breaking version — worth confirming with a user whether .22 also exhibits the issue.

[lambertjosh]

Video: https://youtu.be/L5UihiX-1BI

[johnny-smitherson]

saw this on linux too, pre-release happens, standard release not happening

[lambertjosh]

PR: #8628 in validation

[kilo-code-bot]

Note: Extended investigation across all versions after v7.1.21, requested by @markijbema.

Extending the search to v7.2.0 and v7.2.1 as well.

---

v7.1.23 → v7.2.0 (Apr 7 16:19 → Apr 7 19:11)

🚨 #8445 — perf(snapshot): add mutex lock, incremental add, and batched revert

Directly modifies packages/opencode/src/snapshot/index.ts to add a per-gitdir mutex lock (withLock) that serializes all concurrent snapshot operations. The PR itself explicitly notes "PENDING: Windows testing" and was motivated by Windows users reporting excessive git processes.

A mutex that does not release on Windows (e.g. due to a git subprocess hanging and never resolving its Promise) would cause every subsequent snapshot operation to queue up and wait indefinitely — matching the "stuck forever on Considering next steps" symptom exactly. This is a very strong candidate.

---

v7.2.0 → v7.2.1 (Apr 7 19:11 → Apr 8 16:32)

🚨 #8572 — fix(vscode): dispose git processes on panel close to prevent orphans on Windows

This is arguably the smoking gun. The PR description explicitly states:

"On Windows this is particularly problematic because orphaned git.exe processes hold exclusive file locks on .git/index and packfiles, blocking subsequent git operations."

It was introduced specifically to fix orphaned git processes on Windows that were introduced by earlier PRs (GitOps in AgentManagerProvider, DiffViewerProvider, KiloProvider). The fact that this fix was needed and was merged into v7.2.1 strongly implies that Windows users on v7.2.0 (and possibly earlier) were experiencing exactly this kind of git hang.

---

Updated summary across all windows

Window	PR	Why suspicious
.21 → .22	#8400	diffFull Promise cache — a hanging git process gets permanently cached, all callers deadlock
.22 → .23	#8464	simple-git 3.31.1 → 3.35.2 bump, could change Windows process behavior
.22 → .23	#8190	Changes to git process env vars in GitOps
.23 → 7.2.0	#8445	Mutex lock on snapshot ops with explicitly pending Windows testing
7.2.0 → 7.2.1	#8572	Fix for orphaned git.exe locks blocking all subsequent git on Windows — the fix itself is evidence of the bug

#8445 and #8572 are now the strongest candidates. #8572 is a direct acknowledgment of a Windows git-blocking bug introduced by the GitOps changes. #8445 adds a mutex that could deadlock if any git operation hangs on Windows, compounding the problem.

[lambertjosh]

Long session that can help repro (internal only): https://drive.google.com/file/d/1gq0ykChWUJ1V7uccqDnqpnELTXCRpEyB/view?usp=sharing