Feature Request
What feature would you like to see?
Make the Git status polling intervals (_GIT_BRANCH_TTL and _GIT_STATUS_TTL) configurable via environment variables or the global ~/.kimi/config.toml configuration file.
Current behavior:
In src/kimi_cli/ui/shell/prompt.py, these values are hard-coded constants:
_GIT_BRANCH_TTL = 5.0 # queries git branch every 5 seconds
_GIT_STATUS_TTL = 15.0 # queries git status every 15 seconds
Each Kimi CLI instance independently spawns git branch --show-current and git status --porcelain -b subprocesses on its own schedule. When multiple instances are running simultaneously in the same repository, they compete for .git/index.lock.
My use case & the problem:
I work in a large monorepo (~111,000 tracked files). I typically keep multiple Kimi CLI instances open at once—one per sub-project—via tmux sessions/windows/panes. This leads to:
- Performance degradation:
git status in this repo takes ~2–8 seconds. With 10–15 Kimi CLI instances, that's a sustained background load of repeated filesystem scans.
index.lock conflicts: When I run git commit or other git operations, I occasionally hit:
fatal: Unable to create '.git/index.lock': File exists.
Another git process seems to be running in this repository...
git status --porcelain -b subprocesses spawned by Kimi CLI's prompt refresh.
Proposed solution:
Expose these two TTL values through one of (or both):
- Environment variables: e.g.
KIMI_GIT_BRANCH_TTL, KIMI_GIT_STATUS_TTL
- Global config (
~/.kimi/config.toml): e.g. a new [shell.git] or [ui] section:
[shell.git]
branch_ttl = 30.0
status_ttl = 60.0
For monorepo users, being able to tune these from 5s / 15s up to 30s / 60s (or longer) would eliminate most of the lock contention and wasted CPU/IO without affecting users in smaller repos who are happy with the defaults.
Workarounds considered:
- Reducing the number of Kimi CLI instances — not practical; I need one per active project.
- Enabling
core.fsmonitor — helpful for git status speed, but doesn't reduce the frequency of subprocess spawning from multiple independent Kimi CLI instances.
- Patching the source locally — works, but breaks on every update.
Additional information:
- The
Config class in src/kimi_cli/config.py already supports nested Pydantic models, so adding a shell or ui section with these two float fields should be straightforward.
- For reference, the relevant code is in
src/kimi_cli/ui/shell/prompt.py around lines 877–878 and 932–987.
Feature Request
What feature would you like to see?
Make the Git status polling intervals (
_GIT_BRANCH_TTLand_GIT_STATUS_TTL) configurable via environment variables or the global~/.kimi/config.tomlconfiguration file.Current behavior:
In
src/kimi_cli/ui/shell/prompt.py, these values are hard-coded constants:Each Kimi CLI instance independently spawns
git branch --show-currentandgit status --porcelain -bsubprocesses on its own schedule. When multiple instances are running simultaneously in the same repository, they compete for.git/index.lock.My use case & the problem:
I work in a large monorepo (~111,000 tracked files). I typically keep multiple Kimi CLI instances open at once—one per sub-project—via tmux sessions/windows/panes. This leads to:
git statusin this repo takes ~2–8 seconds. With 10–15 Kimi CLI instances, that's a sustained background load of repeated filesystem scans.index.lockconflicts: When I rungit commitor other git operations, I occasionally hit:git status --porcelain -bsubprocesses spawned by Kimi CLI's prompt refresh.Proposed solution:
Expose these two TTL values through one of (or both):
KIMI_GIT_BRANCH_TTL,KIMI_GIT_STATUS_TTL~/.kimi/config.toml): e.g. a new[shell.git]or[ui]section:For monorepo users, being able to tune these from
5s / 15sup to30s / 60s(or longer) would eliminate most of the lock contention and wasted CPU/IO without affecting users in smaller repos who are happy with the defaults.Workarounds considered:
core.fsmonitor— helpful forgit statusspeed, but doesn't reduce the frequency of subprocess spawning from multiple independent Kimi CLI instances.Additional information:
Configclass insrc/kimi_cli/config.pyalready supports nested Pydantic models, so adding ashelloruisection with these two float fields should be straightforward.src/kimi_cli/ui/shell/prompt.pyaround lines 877–878 and 932–987.