.kilocodeignore
Overview
.kilocodeignore is a root-level file that tells Kilo Code which files and folders it should not access. It uses standard .gitignore pattern syntax, but it only affects Kilo Code's file access, not Git.
If no .kilocodeignore file exists, Kilo Code can access all files in the workspace.
Quick Start
The primary mechanism for controlling file access is the permission system in kilo.jsonc. You define tool-level permissions with glob patterns:
{
"permission": {
"read": { "*.env": "deny", "*": "allow" },
"edit": { "dist/**": "deny", "*": "allow" }
}
}
If you have an existing .kilocodeignore file, it is still supported. The IgnoreMigrator automatically converts .kilocodeignore patterns into permission deny rules on read and edit tools, so your existing rules continue to work without manual changes.
You can also exclude paths from the file watcher separately using watcher.ignore:
{
"watcher": {
"ignore": ["tmp/**", "logs/**"]
}
}
Pattern Rules
.kilocodeignore follows the same rules as .gitignore:
#starts a comment*and**match wildcards- Trailing
/matches directories only !negates a previous rule
Patterns are evaluated relative to the workspace root.
What It Affects
File access is controlled through permission-based access control. Each tool (read, edit, glob, grep, write, bash, etc.) has its own permission rules evaluated against glob patterns.
In addition to your explicit permission rules:
- Hardcoded directory ignores — 27 directories are always skipped (e.g.
node_modules,.git,dist,build,.cache,__pycache__,vendor, and others). - Hardcoded file pattern ignores — 11 file patterns are always skipped (e.g. lock files, binary artifacts).
.gitignoreand.ignorefiles are also respected when listing and searching files.
If a file is denied by a permission rule, the tool will report that access was blocked.
Configuration Details
Permission Rules
Permission rules are defined per-tool in kilo.jsonc. Patterns are evaluated in order — the last matching rule wins:
{
"permission": {
"read": {
"*.env": "deny",
"secrets/**": "deny",
"*": "allow"
},
"edit": {
"dist/**": "deny",
"*.lock": "deny",
"*": "allow"
}
}
}
Migrating from .kilocodeignore
If you already have a .kilocodeignore file, you don't need to do anything — the IgnoreMigrator reads your existing patterns and applies them as deny rules on read and edit tools automatically. You can optionally move your rules into kilo.jsonc for more granular control (e.g. denying edits but allowing reads).
File Watcher Exclusions
The watcher.ignore setting controls which paths the file watcher skips. This is separate from tool permissions and only affects change detection:
{
"watcher": {
"ignore": ["tmp/**", "logs/**", ".build/**"]
}
}
Checkpoints vs .kilocodeignore
Checkpoint tracking is separate from file access rules. Files blocked by .kilocodeignore or permission rules can still be checkpointed if they are not excluded by .gitignore. See the Checkpoints documentation for details.
Troubleshooting
- Kilo can't access a file you want: Remove or narrow the matching rule in
.kilocodeignore(legacy) or adjust the permission rules inkilo.jsonc(VSCode extension & CLI). - A file still appears in lists: In the legacy extension, check the setting that shows ignored files in lists and searches. In the extension & CLI, verify your permission and watcher ignore configuration.
.kilocodeignorepatterns not working in the new platform: Ensure the file is at the workspace root. The IgnoreMigrator reads it automatically — check that your patterns use valid.gitignoresyntax.