Latest in AI
Kimi Code Permission Rules Not Working? Check Scope, Trust and Precedence
Kimi Code CLI 2.6 adds persistent rules, but the file you edit and the session you start determine whether they apply.
Kimi Code CLI 2.6.0 loads persistent user and project permission rules when a session starts. If a rule appears ineffective, check its scope, workspace trust and competing rules before adding a broader permission. A configuration that is not loaded cannot be fixed by making its allow pattern more permissive.
The feature is documented in the November 12 changelog. This guide concerns CLI permission rules, not model access, subscription limits or a claim that the agent has been tested against every possible command.
Start with the file and session
The configuration reference distinguishes user rules in config.toml from project rules in .kimi-code/local.toml. The latter apply only to a trusted workspace in the local environment. Remote project rules are unsupported, and project rule edits require a new session rather than hot reload.
Matching decisions follow deny, then ask, then allow. Legacy turn-override and session-runtime rules in user configuration are silently ignored. MCP and custom tools support matching by tool name, not argument patterns.
Those boundaries suggest a short diagnostic sequence. First establish which environment is executing the tools. Then identify the configuration file actually used, check that its scope is supported and start a new evaluation session. Only after those checks should you investigate the match itself.
Do this in a disposable project without production credentials. Keep a copy of the original configuration and change one rule at a time. If you modify several scopes and patterns together, a successful result will not tell you which change mattered.
An allow rule does not cancel an ask or deny
Suppose you intended to allow one familiar command but a broader matching rule still asks for approval. The prompt may be the correct outcome, not a parsing failure. An applicable ask rule outranks an allow, while a matching deny outranks both.
The mistake is to keep adding permissions until the prompt disappears. That can obscure the original conflict and leave you with a policy much wider than intended. Instead, write down the expected outcome for one harmless operation, list the rules that could match it and resolve the conflict deliberately.
A small verification worksheet is more useful than an ambitious configuration copied from another project:
| Question | What to record |
|---|---|
| Which tool is involved? | Its actual name, rather than the task's natural-language description |
| Where should the rule apply? | User or this specific local project |
| What should happen? | Reject, ask or allow |
| What happened in a new session? | The observed decision and any diagnostic text |
Do not use a destructive operation to verify a rejection rule. An unexpected allow would turn a configuration test into a real incident. Prefer a harmless operation with a temporary restrictive rule, then remove the test rule when you finish.
Project trust is a security decision, not a troubleshooting shortcut
A project can contain configuration as well as source code. Before trusting an unfamiliar checkout, inspect what it asks the agent to load. The configuration reference warns that project allow rules can suppress approval prompts, including some built-in guards.
That is a reason to review the repository, not to disable trust checks globally because one local rule is missing. A persistent permission should describe an action you intentionally allow, in a workspace you understand. It should not be a convenient way to make an installation tutorial stop asking questions.
For an MCP integration, start with the documented tool identity. Do not assume a narrowly written argument pattern is enforced when that tool category supports only name matching. If name-level approval is too broad for the job, retain confirmation and use controls provided by the integration itself rather than treating an unsupported matcher as a security boundary.
The useful outcome is a policy you can explain and reproduce in a new session. Fewer prompts are a benefit only when they represent decisions you meant to make.
I’m Paras. I work at the intersection of AI, engineering and distribution.
I help technical teams explain agent behavior and developer workflows without turning important limits into footnotes.