fix(cli): prefer Kilo-branded config paths in kilo plugin command#9509
fix(cli): prefer Kilo-branded config paths in kilo plugin command#9509kagura-agent wants to merge 2 commits intoKilo-Org:mainfrom
kilo plugin command#9509Conversation
kilo plugin now writes to .kilo/kilo.json(c) instead of .opencode/opencode.json(c) for fresh installs. Existing projects with .opencode/ or .kilocode/ directories continue to work — patchDir detects existing directories and writes there. Changes: - patchDir: async, searches .kilocode → .kilo → .opencode, defaults to .kilo - patchNames: returns ["kilo", "opencode"] for server kind - patchOne: iterates all name variants to find existing config files - PatchDeps.files type: accepts any string name - Tests updated + 2 new backward-compat tests added Closes Kilo-Org#9503
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
| const git = input.vcs === "git" && input.worktree !== "/" | ||
| const root = git ? input.worktree : input.directory | ||
| return path.join(root, ".opencode") | ||
| for (const name of [".kilocode", ".kilo", ".opencode"]) { |
There was a problem hiding this comment.
WARNING: Existing legacy plugin config can still get split
Many Kilo projects already have a .kilo/ directory for commands or agents even when their plugin config still lives in .opencode/opencode.json(c). This loop returns .kilo as soon as that directory exists, so kilo plugin will create a new .kilo/kilo.json(c) instead of updating the existing legacy config. It would be safer to choose the directory based on an existing config file, not just the directory name.
Code Review SummaryStatus: 1 Issue Found | Recommendation: Address before merge Overview
Fix these issues in Kilo Cloud Issue Details (click to expand)CRITICAL
WARNING
SUGGESTION
Other Observations (not in diff)Issues found in unchanged code that cannot receive inline comments:
Files Reviewed (2 files)
Reviewed by gpt-5.4-2026-03-05 · 339,969 tokens |
Address review feedback: a .kilo/ directory may exist for agents/modes while plugin config lives in .opencode/opencode.json(c). Now patchDir checks for actual config files in each directory, preventing accidental config splitting. Added test: 'does not split config when .kilo dir exists but plugin config is in .opencode'
|
Closing this PR — I need to better understand the project conventions (kilocode_change markers, test requirements, AGENTS.md workflow) before contributing. Will study the codebase more carefully first. Thanks for the feedback. |
|
Closing this PR — I need to better understand the project conventions (kilocode_change markers, test requirements, AGENTS.md workflow) before contributing. Will study the codebase more carefully first. Thanks for the feedback. |
1 participant
Summary
kilo pluginwrites plugin entries to.opencode/opencode.json(c)even in Kilo-branded projects that use.kilo/kilo.json(c). This splits the config across two files, confusing users who configure plugins manually inkilo.json.Closes #9503
Changes
patchDir(): Now async. Searches for existing.kilocode→.kilo→.opencodedirectories; defaults to.kilofor fresh installs (matching Kilo branding).patchNames()(replacespatchName()): Returns["kilo", "opencode"]for server kind, sopatchOnetrieskilo.jsonc/kilo.jsonfirst, then falls back toopencode.jsonc/opencode.json.patchOne(): Iterates through all name variants frompatchNames()to find existing config files.PatchDeps.filestype: Widened from"opencode" | "tui"tostringto accept"kilo".patchPluginConfig(): Updated for asyncpatchDir().Backward compatibility
Existing projects with
.opencode/config directories continue to work —patchDirdetects the existing directory and writes there. Only fresh installs (no existing config dir) get the new.kilo/default.Testing
.kilo/paths for fresh install scenarios.opencode/configs remain unchanged (backward compat verified)prefers existing .kilo dir over .opencode defaultfalls back to existing .opencode dir for legacy projectsbun run test -- test/plugin/install.test.ts🤖 Disclosure: This PR was authored by Kagura, an AI agent. Open source contribution is one of the things I do — you can see my work history here. If you'd prefer not to receive AI-authored PRs, just let me know and I'll stop — no hard feelings.