Kilo CLI

Orchestrate agents from your terminal. Plan, debug, and code fast with keyboard-first navigation on the command line.

The Kilo Code CLI uses the same underlying technology that powers the IDE extensions, so you can expect the same workflow to handle agentic coding tasks from start to finish.

Getting Started

Install

Use Kilo Code directly from your terminal for maximum flexibility.

Install via npm

npm install -g @kilocode/cli

Verify Installation

kilo --version

Change directory to where you want to work and run kilo:

# Start the TUI
kilo

# Check the version
kilo --version

# Get help
kilo --help

First-Time Setup with /connect

After installation, run kilo and use the /connect command to add your first provider credentials. This is the interactive way to configure API keys for model providers.

Update

Upgrade the Kilo CLI:

kilo upgrade

Or use npm:

npm update -g @kilocode/cli

What you can do with Kilo Code CLI

• Plan and execute code changes without leaving your terminal. Use your command line to make edits to your project without opening your IDE.
• Switch between hundreds of LLMs without constraints. Other CLI tools only work with one model or curate opinionated lists. With Kilo, you can switch models without booting up another tool.
• Choose the right mode for the task in your workflow. Select between Architect, Ask, Debug, Orchestrator, or custom agent modes.
• Automate tasks. Get AI assistance writing shell scripts for tasks like renaming all of the files in a folder or transforming sizes for a set of images.
• Extend capabilities with skills. Add domain expertise and repeatable workflows through Agent Skills.

CLI Reference

Top-Level CLI Commands

Global Options

Interactive Slash Commands

Session Commands

Agent & Model Commands

Provider Commands

System Commands

Kilo Gateway Commands (when connected)

Built-in Commands

Local Code Reviews

Review your code locally before pushing — catch issues early without waiting for PR reviews. Local code reviews give you AI-powered feedback on your changes without creating a public pull request.

Commands

Config Reference

Configuration is managed through:

• /connect command for provider setup (interactive)
• Config files directly at ~/.config/kilo/config.json
• kilo auth for credential management

Permissions

Kilo Code uses the permission config to decide whether a given action should run automatically, prompt you, or be blocked.

Actions

Each permission rule resolves to one of:

• "allow" — run without approval
• "ask" — prompt for approval
• "deny" — block the action

Configuration

You can set permissions globally (with *), and override specific tools.

{
	"$schema": "https://kilo.ai/config.json",
	"permission": {
		"*": "ask",
		"bash": "allow",
		"edit": "deny"
	}
}

You can also set all permissions at once:

{
	"$schema": "https://kilo.ai/config.json",
	"permission": "allow"
}

Granular Rules (Object Syntax)

For most permissions, you can use an object to apply different actions based on the tool input.

{
	"$schema": "https://opencode.ai/config.json",
	"permission": {
		"bash": {
			"*": "ask",
			"git *": "allow",
			"npm *": "allow",
			"rm *": "deny",
			"grep *": "allow"
		},
		"edit": {
			"*": "deny",
			"packages/web/src/content/docs/*.mdx": "allow"
		}
	}
}

Rules are evaluated by pattern match, with the last matching rule winning. A common pattern is to put the catch-all "*" rule first, and more specific rules after it.

Wildcards

Permission patterns use simple wildcard matching:

• * matches zero or more of any character
• ? matches exactly one character
• All other characters match literally

Home Directory Expansion

You can use ~ or $HOME at the start of a pattern to reference your home directory. This is particularly useful for external_directory rules.

• ~/projects/* → /Users/username/projects/*
• $HOME/projects/* → /Users/username/projects/*
• ~ → /Users/username

External Directories

Use external_directory to allow tool calls that touch paths outside the working directory where Kilo was started. This applies to any tool that takes a path as input (for example read, edit, list, glob, grep, and many bash commands).

{
	"$schema": "https://kilo.ai/config.json",
	"permission": {
		"external_directory": {
			"~/projects/personal/**": "allow"
		}
	}
}

Any directory allowed here inherits the same defaults as the current workspace. Since read defaults to "allow", reads are also allowed for entries under external_directory unless overridden. Add explicit rules when a tool should be restricted in these paths, such as blocking edits while keeping reads:

{
	"$schema": "https://kilo.ai/config.json",
	"permission": {
		"external_directory": {
			"~/projects/personal/**": "allow"
		},
		"edit": {
			"~/projects/personal/**": "deny"
		}
	}
}

Available Permissions

Permissions are keyed by tool name, plus a couple of safety guards:

• read — reading a file (matches the file path)
• edit — all file modifications (covers edit, write, patch, multiedit)
• glob — file globbing (matches the glob pattern)
• grep — content search (matches the regex pattern)
• list — listing files in a directory (matches the directory path)
• bash — running shell commands (matches parsed commands like git status --porcelain)
• task — launching subagents (matches the subagent type)
• skill — loading a skill (matches the skill name)
• lsp — running LSP queries (currently non-granular)
• todoread, todowrite — reading/updating the todo list
• webfetch — fetching a URL (matches the URL)
• websearch, codesearch — web/code search (matches the query)
• external_directory — triggered when a tool touches paths outside the project working directory
• doom_loop — triggered when the same tool call repeats 3 times with identical input

Defaults

If you don't specify anything, Kilo starts from permissive defaults:

• Most permissions default to "allow".
• doom_loop and external_directory default to "ask".
• read is "allow", but .env files are denied by default:

{
	"permission": {
		"read": {
			"*": "allow",
			"*.env": "deny",
			"*.env.*": "deny",
			"*.env.example": "allow"
		}
	}
}

What "Ask" Does

When Kilo prompts for approval, the UI offers three outcomes:

• once — approve just this request
• always — approve future requests matching the suggested patterns (for the rest of the current session)
• reject — deny the request

The set of patterns that "always" would approve is provided by the tool (for example, bash approvals typically whitelist a safe command prefix like git status*).

Agent Permissions

You can override permissions per agent. Agent permissions are merged with the global config, and agent rules take precedence.

{
	"$schema": "https://kilo.ai/config.json",
	"permission": {
		"bash": {
			"*": "ask",
			"git *": "allow",
			"git commit *": "deny",
			"git push *": "deny",
			"grep *": "allow"
		}
	},
	"agent": {
		"build": {
			"permission": {
				"bash": {
					"*": "ask",
					"git *": "allow",
					"git commit *": "ask",
					"git push *": "deny",
					"grep *": "allow"
				}
			}
		}
	}
}

You can also configure agent permissions in Markdown:

---
description: Code review without edits
mode: subagent
permission:
    edit: deny
    bash: ask
    webfetch: deny
---

Only analyze code and suggest changes.

Interactive Mode

Interactive mode is the default mode when running Kilo Code without the --auto flag, designed to work interactively with a user through the console.

In interactive mode Kilo Code will request approval for operations which have not been auto-approved, allowing the user to review and approve operations before they are executed, and optionally add them to the auto-approval list.

Interactive Command Approval

When running in interactive mode, command approval requests show hierarchical options:

[!] Action Required:
> ✓ Run Command (y)
  ✓ Always run git (1)
  ✓ Always run git status (2)
  ✓ Always run git status --short --branch (3)
  ✗ Reject (n)

Selecting an "Always run" option will:

1. Approve and execute the current command
2. Add the pattern to your execute.allowed list in the config
3. Auto-approve matching commands in the future

This allows you to progressively build your auto-approval rules without manually editing the config file.

Autonomous Mode (Non-Interactive)

Autonomous mode allows Kilo Code to run in automated environments like CI/CD pipelines without requiring user interaction.

# Run in autonomous mode with a message
kilo run --auto "Implement feature X"

Autonomous Mode Behavior

When running in autonomous mode:

1. No User Interaction: All approval requests are handled automatically based on configuration
2. Auto-Approval/Rejection: Operations are approved or rejected based on your auto-approval settings
3. Follow-up Questions: Automatically responded with a message instructing the AI to make autonomous decisions
4. Automatic Exit: The CLI exits automatically when the task completes or times out

Auto-Approval in Autonomous Mode

Autonomous mode respects your auto-approval configuration. Operations which are not auto-approved will not be allowed.

Autonomous Mode Follow-up Questions

In autonomous mode, when the AI asks a follow-up question, it receives this response:

"This process is running in non-interactive autonomous mode. The user cannot make decisions, so you should make the decision autonomously."

This instructs the AI to proceed without user input.

Exit Codes

• 0: Success (task completed)
• 124: Timeout (task exceeded time limit)
• 1: Error (initialization or execution failure)

Example CI/CD Integration

# GitHub Actions example
- name: Run Kilo Code
  run: |
      kilo run "Implement the new feature" --auto

Session Continuation

Resume your last conversation from the current workspace using the --continue (or -c) flag:

# Resume the most recent session from this workspace
kilo --continue
kilo -c

This feature:

• Automatically finds the most recent session from the current workspace
• Loads the full conversation history
• Allows you to continue where you left off
• Cannot be used with autonomous mode or with a prompt argument
• Exits with an error if no previous sessions are found

Example workflow:

# Start a session
kilo
# > "Create a REST API"
# ... work on the task ...
# Exit with /exit

# Later, resume the same session
kilo --continue
# Conversation history is restored, ready to continue

Limitations:

• Cannot be combined with autonomous mode
• Cannot be used with a prompt argument
• Only works when there's at least one previous session in the workspace

Environment Variable Overrides

The CLI supports overriding config values with environment variables. The supported environment variables are:

• KILO_PROVIDER: Override the active provider ID
• For kilocode provider: KILOCODE_<FIELD_NAME> (e.g., KILOCODE_MODEL → kilocodeModel)
• For other providers: KILO_<FIELD_NAME> (e.g., KILO_API_KEY → apiKey)

Switching into an Organization from the CLI

Use the /teams command to see a list of all organizations you can switch into.

Use /teams and select a team to switch teams.

The process is the same when switching into a Team or Enterprise organization.