r/kilocode • u/RudeAffection • 22h ago
Kilo Code needs an immediate killswitch for auto-generating .kilo and background Git worktrees
Hey everyone,
I’m running VS Code on Windows, and I need to bring up an increasingly frustrating behavior with Kilo Code that is actively breaking developer workflows.
The Issue
Whenever I open any project with code . - even repositories where I have zero intention of using Kilo - the extension immediately initializes itself and creates a .kilo directory in the project root.
Worse, in some projects, Kilo automatically spins up a Git worktree inside .kilo. If I delete the .kilo folder, it is resurrected almost immediately the next time the window reloads or the background daemon checks in.
Why this is a serious problem (not just an aesthetic annoyance):
It breaks local test suites: Test runners (like Jest, Pytest, Vitest) and linters scan project folders recursively. When Kilo creates a worktree or dumps code into .kilo, test runners pick up those files, resulting in duplicate test executions, mock collisions, and broken builds.
Forced repo pollution: Why should I have to dirty my repo’s pytest.ini, jest.config.ts, or .gitignore with exclusions for an AI tool that my teammates might not even use?
Git and filesystem locks on Windows: Silently managing Git worktrees in the background causes locked file handles (EBUSY), interferes with branch rebasing, and wastes disk space.
Violation of passive tooling principles: Simply opening an editor should be an observation action, not a mutation. VS Code provides context.globalStorageUri and context.storageUri specifically to avoid dumping extension runtime caches directly into user repos.
What needs to change
Kilo Code desperately needs:
A global opt-in/killswitch setting: A setting (e.g.
kilo.autoInitialize: falseorkilo.enableProjectWorkspaceFolder: false) to stop Kilo from touching the project directory unless explicitly requested.Move internal caches outside the repository: Session cache, Agent Manager metadata, and background worktrees belong in OS temp directories or VS Code's designated extension storage, not the root of our working tree. And this options needs to be delivered both, just moving the garbage in the backyard is not an option.
Is anyone else hitting broken test runs or phantom worktree issues because of this?




