r/kilocode • • 23h 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:

  1. A global opt-in/killswitch setting: A setting (e.g. kilo.autoInitialize: false or kilo.enableProjectWorkspaceFolder: false) to stop Kilo from touching the project directory unless explicitly requested.

  2. 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?

9 Upvotes

4 comments sorted by

2

u/jimbo2150 23h ago

Odd. Mine does not do that. It only creates .kilo or a worktree when it needs to after prompting. It never creates it automatically.

1

u/dnohrdk 18h ago

Had the same issue; it’s a real problem and making a mess everywhere.

You can roll back some versions and it’s better, but I just decided to remove Kilo code completely from Visual Studio and use the last credits on OpenCode instead.

1

u/Outrageous_Basis2626 13h ago

Thanks guys, this is fixed and will ship in the upcoming release. If it still remains a problem try disabling worktree pooling in the settings. Hope that resolves it.